An override without a reason is a silent decision.

Override is a decision, or it is an erasure

An agent recommends a next step, or an automation is about to send, file, or advance a record. A person disagrees. They edit the field, hit approve on a different value, or rerun the job with a quiet tweak. The record now shows only the final value. The recommendation is gone. Later, nobody can tell judgment from a glitch.

An override is useful when it is an explicit decision: the original output remains, a reason code from a list you control is required, evidence is attached, and a named role reviews overrides on a cadence you set. It is not useful when “the operator fixed it” is the whole story.

This note is the TWIMCO Operator Override Audit Spec. It is not a permission matrix—that earlier question is whether a role may act at all. It is not an escalation ladder for work that is stuck. It is the trail after a human overturns a machine recommendation that was allowed to exist. There is no live builder for the spec. If you are deciding whether the workflow should be automated, start with the live AI workflow readiness check. Readiness does not substitute for the override trail once the agent is allowed to propose.

On Sutton|Place, a supplied claim stays distinct from a check, and a decision stays attached to an actor and a time. Issuer judgment connects back to the verification record without replacing it. That is the pattern an override should copy: the agent’s proposal is the claim, the human’s overturn is the decision, and neither one is allowed to eat the other. Do not cite the partnership as evidence that a particular override screen exists. Cite it as the standard for keeping judgment inspectable.

Write the spec for one decision type, not for “AI” in general. A pricing suggestion, a disclosure recommendation, and a support macro are different decisions. They do not share a reason list just because they share a model.

What the spec must force onto the record

One page per decision type. Fill these lines before operators are told they may override.

Decision type. What the agent or automation was proposing, in one sentence. What system of record holds it. What “overturn” means: changing the value, refusing to send, substituting a human draft, or halting a job.

When override is allowed. Not always. List the states where a human may overturn, and the states where they may not—where the only honest moves are to accept, to send back, or to stop. If every state allows override, say so on purpose. Accidental omnipotence is how silent fixes spread.

Reason codes. A closed list the team wrote. Free text may sit beside a code; it may not replace the code. Codes should be operational: source missing, source contradicted, policy exception, wrong party, stale input. “Other” is allowed only if it still demands a sentence and still enters the review queue. A blank reason is not a save.

Evidence attached. What must be on the record with the override: the source the human relied on, the conflicting field, or an explicit “no document; judgment only.” Judgment-only is allowed if the spec says so for that decision type. It is not the default you get by skipping the field.

Review. Who looks at overrides after the fact, and the cadence your team will actually keep. Do not copy a service-level number from this note. Write the cadence in your own words—“the next business day’s review,” “the weekly deal review”—and name the role. If nobody is named, overrides are unaudited by design.

Never silent. The save path rejects an overturn that lacks a code, an actor, and a time. A database edit, a script, or a “quick fix” in an admin tool that bypasses the path is a policy breach, not a shortcut. If operators must sometimes use a console, the spec names that path and the same fields it requires. A side door without fields is silent override with extra steps.

Original remains. The proposal, the model or rule version if you have it, and the inputs you are willing to store stay readable next to the human decision. You may redact secrets. You may not replace the proposal with the winner and call the history “clean.”

The spec is not in force until reason codes, evidence rule, reviewer, and the never-silent line are written, and until one real override has been saved and reread by someone who was not the operator.

Separate the proposal from the overturn

Walk a single case so the team can see what the record should contain. This is a framework, not a client transcript.

The agent proposes. The proposal is stored as a proposal: status proposed, not confirmed. Inputs you can keep are linked. If the human agrees, agreement is its own action. Agreement is not an override and does not need an override code. Do not make people invent a reason for saying yes. That trains them to click through codes.

The human disagrees. The product asks for a code and the evidence the spec demands. It shows the proposal above the new value so the person is editing a decision, not a blank field that happens to have been prefilled. On save, the proposal remains, marked overturned, with actor and time. The new value is the decision. Downstream steps key off the decision, not off a rewritten history.

Review looks at overturns, not at every acceptance. The reviewer’s job is pattern, not punishment: codes that dominate, evidence that is always “judgment only,” operators who override the same input every time, a code list that does not match the real reasons people type into the free-text box. When the free text and the code diverge all week, fix the list. Do not scold the operators for using the only honest field you gave them.

Escalation is a different object. If the human should not decide, the spec says so, and the product routes the case rather than offering an override button. A button that always works will be used when the person is tired. The never-silent rule does not make a bad authority good. It makes the authority visible so you can narrow it.

On Sutton|Place, pending and failed checks stay distinct from confirmation, and disclosure is an explicit action. Carry that into the override: proposed, overturned, and confirmed are different, and a person who discloses or decides can be named later. If your agent drafts a disclosure, the override spec belongs on that draft before the draft is allowed to become the sent thing.

Tie the spec to the agent’s job. An agent that may only recommend cannot silently gain a send tool because an operator clicked past a warning. The override is about the recommendation. The permission to send is a separate line. Mixing them is how “I fixed the draft” becomes “I sent a different promise.”

Overrides that leave no trail

Composites from operating arguments, not metrics.

The blank replace. The final field looks hand-authored. Nothing records that an agent proposed a different value five minutes earlier. Quality review concludes the human process is working, because the machine has been edited out of the evidence.

The code nobody believes. Every override is “Other.” The free text has the real reasons. The weekly count of codes is a chart of indifference. You still do not know whether people are correcting stale data or ignoring policy.

The console fix. The product requires a reason. The on-call updates the row in a console because the product was slower. The spec’s never-silent line was a form validation, not a rule about the data.

Judgment only, forever. Evidence is optional and therefore absent. When a decision is questioned, the team has a code and a mood. They do not have the source the operator claims to have seen.

Review as a dashboard star. Overrides are counted and never read. The count becomes a performance number you should not have invented. This spec does not ask you to hit a rate. It asks a person to read the trail.

The unreproducible asset is the filled TWIMCO Operator Override Audit Spec for one decision type: your states, your codes, your evidence rule, your reviewer, and one saved example you can open. A prompt that says “always let a human override” does not include your list or your sample. The sample is the part another model cannot honestly reconstruct, because it is your case.

Keep the spec next to the agent’s job description. When you change the prompt or the tools, reread the reason codes. New tools create new ways to be wrong, and the old list will miss them. AI applications and agents work includes this trail when the agent is allowed to propose something a person might need to refuse. Business process automation fits when the thing being overturned is a workflow step rather than a generated draft. Either way, the public standard on Sutton|Place is the same: the decision does not erase the record it judged.

Put this into practice

1. Pick one decision an agent or automation already proposes, where a human sometimes changes the outcome.
2. Write when override is allowed, the reason codes, the evidence rule, the reviewer, and the never-silent line.
3. Save one real override in a non-production record and have a second person read it cold. If they cannot see the proposal and the reason, the path is not done.
4. Close side doors or give them the same fields. A required form with a casual console is not a spec.
5. Review overturns on the cadence you named. Change the code list when free text is doing the real work. If you need help drawing the line between a proposal and an action, bring the half-filled spec to a conversation about AI applications and agents, and use Sutton|Place as the picture of judgment that stays attached to an actor without eating the underlying record.

A human in the loop is not a person who can quietly rewrite the loop. It is a person whose disagreement remains on the page.