Why human approval is a system boundary, not a button
Human approval in a sales AI system is not the presence of a Confirm button. It separates proposed work from authorized discretionary action. The system must preserve the exact recipient, content, cost, and state a person reviewed, refuse stale or changed work, execute once, and record what happened.
A button can be decorative
An approval button looks reassuring. It tells the buyer that a person remains in control. But the button proves very little on its own.
Suppose a seller reviews a message, clicks approve, and the system rewrites the message before sending. Or the seller approves one recipient and the action applies to an entire audience. Or a retry runs the action twice. Or the AI can approve the proposal it created. The interface contained a button, but the person did not control the act that followed.
Meaningful approval is not a visual component. It is a system rule. On one side sits proposed work that can still be changed or refused. On the other sits an authorized operation with a named target and effect. Only a person can move the work across that line, and the work cannot change while crossing it.
Five properties of meaningful approval
A real approval boundary is specific, informed, bound, exclusive, and auditable.
| Property | What the person should be able to trust |
|---|---|
| Specific | The approval names the action and target. It does not authorize a vague class of future behavior. |
| Informed | The person can see the content, changed fields, audience, cost, or other consequence that matters. |
| Bound | The work that executes is the work that was reviewed. If it changes, approval expires. |
| Exclusive | The system that proposed the action cannot approve it. Authority belongs to an authenticated person. |
| Auditable | The system records what was proposed, what was approved, who approved it, and what actually happened. |
The properties reinforce each other. A detailed review is useless if the work can change afterward, if the model can approve it, or if a retry repeats the action. Approval therefore belongs in the operating contract, not just the interface. Every part of the system must enforce the person's decision.
The reviewed work must be the executed work
The plainest approval promise is also the most important: what the person saw is what the system uses.
For an email, that means the recipient, subject, and body remain the same from review to send. If the draft changes, the prior approval no longer applies. For enrollment, it means the approved audience and message version are fixed before contacts enter the Play. For a CRM change, it means the fields and record shown in review are the fields and record changed.
Without this rule, a person can approve an understandable object while the system executes a later object assembled from new context. The difference may be subtle in software and enormous to the seller whose name is on the action.
In Cordanis, approved Play messaging is locked to a version, the audience is fixed at launch, and each email remains reviewable before sending. If reviewed email content changes, sending is refused until the seller sees the current version. The Assistant cannot approve its own proposal or perform the send.
Approval should carry the smallest useful scope
Materiality decides whether approval is needed at all. Not every action deserves a separate ceremony. A team may configure a trusted sync to copy verified fields or apply a deterministic rule inside known bounds. That is different from giving a model standing permission to decide which records to change as context evolves.
For discretionary action, scope should be no broader than the decision the person can reasonably understand. Approval of one message should cover that message. Approval of a Play launch can cover a reviewed version and a fixed audience. It should not cover later rewrites, newly added contacts, or an unknown action chosen after the review.
The smallest useful scope is not always the smallest possible click. Asking for approval on every harmless formatting change wastes attention and trains people to click without reading. A review earns its interruption only when the seller is taking responsibility for something material. The goal is not maximum confirmation.
The person needs a real decision
Good approval design makes the consequence clear before asking for a choice. The review should answer simple questions:
- What will happen?
- Who or what will it affect?
- What content or fields will be used?
- What will it cost or commit?
- Can it be reversed?
The person also needs a meaningful alternative. They should be able to edit, reject, defer, or ask for a different option. A bright button beside a dense summary is not much of a decision if refusing it means abandoning the entire workflow.
This is part of the trust contract. The seller is not supervising a machine for its own sake. The seller owns the customer relationship, the forecast, and the operating judgment. Approval gives that responsibility a place to act. The system remains responsible for presenting truthful evidence, enforcing the approved scope, executing reliably, and reporting what happened.
Approval is necessary and insufficient
People make mistakes. They skim. They trust polished drafts too quickly. A human gate does not guarantee that a message is good, a contact is right, or a CRM update is wise.
Approval still matters because it assigns authority and creates a point where the action can be examined. Evidence should be visible, changes should be clear, and warnings should be reserved for decisions that deserve attention. Approval is one part of a trustworthy system, not a substitute for constrained tools, reliable execution, or honest reporting.
How to test an approval boundary
When evaluating a sales AI system, ask for more than a screenshot of its review screen. Ask what happens when:
- the content changes after review;
- the target changes before execution;
- the user clicks twice;
- the network fails after the external action succeeds;
- the AI proposes an action outside its permission;
- a second user tries to approve work they do not own;
- the provider reports a different outcome than the application expected.
The answers reveal whether approval is a button or a system boundary. A button asks a question. A boundary makes the answer authoritative.
Cordanis separates proposed work from consequential action. The seller sees and approves the specific operation; validated services execute it and record the result. Read What AI should prepare and what it should never execute alone, What is an AI sales harness?, and How Cordanis is secured.
