AI Safety: The Celeste Enforcement Pipeline | IMCeleste
IMCeleste
Live Admin Demo Start free
AI Safety

How Celeste decides what to do, and whether to hit send.

Two pipelines sit between Celeste and your customers. One decides whether each proposed action gets executed, held for a person, or refused. The other decides whether the drafted reply sends itself or waits for review. Both are plain code that gives the same answer every time, out of the model's reach. A customer's message can shape what Celeste proposes, never what the platform permits.

The one rule that spans everything

Each setting can only subtract autonomy. No setting can override another's refusal, and the strongest applicable restriction always wins.

Sent Held for a person Refused Filed, no reply
One message, end to end

Every gate between a customer message and Celeste's reply.

A message has to pass every gate before a reply is sent. If it fails any gate, the conversation takes the safer path instead.

  1. Admission control

    Throttled

    Flood protection and per-sender caps run before anything else. When a cap is hit the sender is throttled politely, web chat degrades to message-taking, and nothing bills.

  2. Billing gates

    Routed to your team

    No live subscription, a lapsed period, or a reached spend cap means Celeste doesn't answer. The message is recorded and routed to your team, and nothing bills.

  3. Risk screen

    Escalated

    Threats, legal exposure, and vulnerable senders go straight to a person. Every write that turn is suppressed; reads and a draft are still prepared for the reviewer.

  4. Triage

    Filed

    Newsletters, receipts, and notifications are filed. No reply, no bill.

  5. Turn cap

    Escalated

    A conversation that has gone on too long is handed to a person instead of looping forever.

  6. Topic classification

    Stricter topic wins

    Follow-ups keep their topic. When a turn could plausibly span two topics, the stricter topic's settings govern the whole turn.

  7. Context

    Retrieve and rank your knowledge, load the topic's procedures, and load customer memory only when identity allows it.

  8. Draft and tool loop

    Every action checked

    Celeste drafts the reply, and every action it proposes along the way goes through the full set of action checks below. If the agent can't help at all, a person takes over. The customer is never left hanging.

  9. The autosend gate

    Fifteen brakes

    Topic mode is checked first, then fifteen brakes in order. If all are clear, the reply sends. If any brake fires, the draft waits in the Support Inbox with its hold reason and a link to the setting that fired.

  10. A person decides

    Support Inbox

    Approve or edit the draft, approve a held action (the action checks run again first), or mark it handled so nothing sends at all.

The action checks

Every proposed action passes these checks, in this order.

Reads always run, so Celeste can look things up freely. Everything past the read check applies to writes only. Bookings, refunds, account changes, the things that matter.

Identity guards

Refused

An unverified sender can't be used to look anyone up, and account data can't be touched before verification or by a tool that can't be scoped to one account.

Facts are read, or the rule fires

Treated as fired

Rules read live facts before they're checked. A fact that can't be read counts as its limit having fired.

Enabled, on-topic, in bounds

Refused

Is the tool enabled at all? Is it allowed on this topic? Are the details well-formed and within bounds? These basic checks run before everything else.

Changed tool

Held

A tool whose definition changed since the owner risk-classified it is held until it's re-classified. This hold applies even after an approval.

Practice never writes

Draft only

On a practice topic, safe reads run for real. Writes are only drafted, never run.

Limits and facts

Refused or held

Every rule you've written is checked, and the strongest effect wins. For example, never book outside these hours, ask me first over two hundred dollars, never refund past thirty days. A Block is a wall nobody can approve past. An ask-first rule holds the action for a person.

Procedure scope guard

Held

A write governed by one of your procedures only runs when that procedure actually loaded for this turn.

The autonomy gate

Held

Three things are all required. The topic is in Autonomous mode, the tool's risk classification is current, and the action sits within the topic's action ceiling. The hold reason names which one failed.

Account scope injected

Refused

The verified customer's account scope is written into the action itself. If that step fails, the action is refused rather than run without limits.

Run once, then check

Once, verified

A saved record stops the same write from running twice, even if a message is delivered again. Then the action runs with a time limit, the output is cleaned, and the result is tagged with how trustworthy it is for the reply gate.

Approval does not skip the checks.

When a person approves a held action, the platform re-checks that the decision is still open, re-reads the facts fresh, and runs all the action checks again before anything runs. A Block added after the hold still refuses. A limit tightened after the hold still applies.

Three common cases, traced

A booking, an opt-out and a refund, through the same gates.

A booking

Confirmed, then written once

The customer asks for Thursday after 5. Celeste proposes one exact slot and the slot is held. Nothing is written until the customer confirms. Then the booking passes the action checks, a saved record makes sure it runs once even if the message is delivered again, and the reference is read back. Two customers cannot land in the same slot, and Celeste never tells a customer a booking exists before it does.

An opt-out

Honored

A customer replies STOP to a text, or clicks the opt-out link in an email. From then on no reminder, confirmation, review request or win-back note goes to them, whatever switch is on. Separately, texts and review requests wait for your sending window. A booking confirmation or reminder email goes right away. Review requests and win-back notes have a per-customer cap. None of this is a setting the model can reason around. It is checked before anything sends.

A refund over the limit

Held for a person

Celeste proposes a refund of $240 against an ask-first rule at $200. The limits check holds the action, the reply that depends on it is held too, and the draft waits in the Inbox with the reason. When a person approves, the action checks run again with fresh facts before anything runs.

The autosend gate

Fifteen ordered brakes between a draft and your customer.

The topic's mode sets the baseline. Then the brakes are checked in order, and the first one that fires becomes the hold reason a reviewer sees.

Practice

Recorded as a practice draft. Never sent, never billed.

Co-pilot

Always queued for a person. Nothing sends on its own.

Autonomous

May send itself, if confidence clears the topic's bar and none of the fifteen brakes fires.

  1. The sender isn't verified
  2. A procedure issue or clash was reported
  3. The reply would reveal an internal procedure
  4. An escalation trigger matched, like an always-escalate topic, a workspace escalation phrase, or an upset customer
  5. The topic classification is uncertain
  6. The fact-check couldn't run
  7. A claim is unsourced or contradicted
  8. Celeste hit a capability gap
  9. An action is held for approval
  10. An action was refused
  11. A write failed with an error
  12. The reply has no supporting sources
  13. The reply only echoes the customer back
  14. The evidence came from an untrusted tool
  15. It failed the agent's own pre-send review

Anything held lands in the Support Inbox with its reason. Approving and sending a held draft runs one last check that no internal procedure leaks.

Which rule wins

Four rules of thumb the pipeline always obeys.

Billing checks come first

A lapsed workspace never auto-answers; messages route to your team instead, and nothing bills.

Safety before topic settings

A threatening sender suppresses writes no matter how autonomous the topic.

Actions before the reply

A held or refused action brakes the reply that depends on it.

Approval clears one hold only

A person's approval satisfies exactly one hold, never the walls behind it.

Which setting controls what

Six settings pages, all yours. Each can only take autonomy away.

Every gate above is fed by a setting you own. None of them can grant autonomy another setting took away.

What Celeste can do

Which tools exist, on which topics, and the owner's risk classification of each one, pinned to the tool's current definition.

Topic Autonomy

Per-topic mode, the confidence bar, the autonomous action ceiling, and always-escalate flags.

Limits and facts

Amount, fact, and time-window rules, each either ask-first or a hard Block. An unreadable fact counts as fired.

Escalation phrases

A workspace-wide keyword list, matched against the customer's last message on every topic.

Procedures

Private playbooks, the write tools they govern, and the send-time check that none of them leaks.

Customer Identity

Per-channel identity posture, the verification method, and per-tool account scoping.

This page describes the shipped enforcement code, traced step by step from the source code. When the pipeline changes, this page changes with it.

See it running

See the brakes for yourself.

Start free and every gate here runs on your own data, under limits you set. Prefer to look first? Open the read-only demo and check the Support Inbox: each held draft names the brake that fired and links the setting that owns it. For the data-handling side, read Security and Trust.

Start free Live Admin Demo