← Thinking

Evidence That Can Say No

A transcript is not a verdict. Unattended work needs a binding control that consumes evidence at the right boundary and can refuse the next action.

Why logs and self-reported success are not enough for unattended work

A coding agent opens a pull request. The tests pass, the review says the change meets the specification, and the run reports success. Is the change now safe to merge without a person watching?

The answer depends on more than the contents of those records. The builder may have selected the tests, interpreted the specification, and produced the success report. Even an accurate report may arrive only after the consequential action has already happened.

Unattended work needs a binding control that consumes evidence at the right boundary and can refuse the next action. The evidence record must also carry an honest account of who authored it, who could alter it, and what its limits are.

A binding connection between evidence and control lets routine work continue without continuous approval.

A transcript is not a verdict

A transcript explains what a process says happened and can support diagnosis or audit after the event. Diagnosis is not permission to merge.

Evidence supports or challenges a claim about the work. A control consumes that evidence at a decision boundary and permits, refuses, or escalates the next action. Governance determines which evidence is required, which controls bind, and which decisions remain with people.

The preceding paper, Review the Work Without Watching the Worker, described checkpoints that preserve intermediate outcomes. Checkpoints make work inspectable; controls determine whether an outcome may become consequential.

The difference is functional, not a file format. The same test report is a paper trail when merely stored and binding evidence when a required control consumes it before merge.

flowchart LR
    C["Claim<br/>the change meets the specification"] --> E[("Evidence<br/>tests, review and provenance")]
    E -->|retained but not consumed| P["Paper trail<br/>diagnose or audit"]
    E -->|consumed before action| G{"Control"}
    G -->|supported| A["Permit the transition"]
    G -->|failed or uncertain| H["Refuse or request human review"]
    V["Governance<br/>sets evidence, control and authority"] -.-> E
    V -.-> G

The title is deliberate shorthand. Evidence does not act by itself. Evidence can say no only when a binding control consumes it and can stop the transition.

The same distinction applies outside software. A checked refund calculation stored with a case is a useful paper trail. The same calculation becomes binding evidence when the payment control consumes it before money moves and refuses an unsupported amount.

Put machines around judgement

Some checks are objective. Deterministic code can validate a schema and verdict vocabulary, require named records, enforce a budget, and reject a transition whose inputs are missing or unknown.

Whether a design is coherent or a change satisfies an interpretive requirement still needs engineering judgement from an evaluator, whether agent or person. A useful boundary makes that judgement structured, then lets deterministic controls enforce how each outcome is routed.

flowchart LR
    S["One acceptance language"] --> V["Builder-visible criteria"]
    S --> F["Full criteria<br/>including withheld cases"]
    V --> B["Builder"]
    B --> W["Completed change"]
    W --> J["Evaluator"]
    F --> J
    J --> R[("Structured verdict")]
    R --> D{"Deterministic control"}
    D -->|supported| N["Next transition"]
    D -->|failed or uncertain| H["Stop or human review"]

Builder-visible and withheld cases can use the same acceptance language and parser while remaining visible to different actors. The builder receives enough information to do the work. The evaluator receives the full criteria so the evaluation can cover behaviour the builder could not target directly.

When an evaluator cannot resolve an interpretive criterion, the verdict should be needs-human, not an invented pass. A mechanical checker can reject a malformed verdict and ensure that needs-human routes to review rather than becoming a pass. Mechanical validation cannot prove that the evaluator understood the requirement or made a sound judgement.

Evidence has provenance and custody

Well-formed evidence is not necessarily independent evidence. Trust depends on the path by which the record was produced and used.

QuestionTrust property
Who made the judgement?Authorship and provenance
Who was permitted to persist it?Writer identity and write authority
Who could alter it afterwards?Custody and integrity
Which control consumed it before action?Operational consequence

The author and writer may be different actors. A worker may return a verdict that a trusted dispatcher persists. Trusted persistence changes the writer, not the author. Custody improves only when the worker cannot alter the record afterwards or a later alteration can be detected. A trusted digest comparison can detect change after a snapshot, but cannot make the record's contents true.

Write abstention can also preserve human authority. If a consequential transition requires an approval record that automation cannot author, a missing human decision blocks the transition. Product objectives, exceptional risk, and wider delegated scope can remain behind that boundary. A required human-authored record is stronger than an advisory instruction telling the worker not to exceed its authority.

Conservative controls still have a cost

An evaluation and control chain can misclassify work in two consequential ways.

ErrorImmediate consequence
False passDefective work is permitted to continue
False failAcceptable work is stopped for review

When failure routes to human review rather than executing the action, the errors become asymmetric. A false fail costs time and attention. A false pass can make incomplete work consequential without anyone noticing.

I have been testing this idea while building SuperDomestique, a system for increasingly independent software delivery. In one 450-case offline sweep, its holdout judge produced no false passes across 360 recorded defective cases. With no observed false passes, the rule-of-three gives an approximate 95% upper bound of 0.83%. Across 90 recorded clean cases, the judge produced 65 false fails, a rate of 72.2%.

The measurement is deliberately narrow. The judge evaluated fixed recordings from a corpus labelled by its builders rather than independently audited, using one pinned model and one pass over each case. The result measures reasoning over that recorded surface, not live end-to-end sensitivity. Zero observed false passes is not zero risk. The high false-fail rate exposes the tradeoff: parking most correct work may reduce immediate risk without delivering useful autonomy.

Trust claims must survive refutation

A trust claim should be specific enough to disprove and carry a status that matches its evidence. Useful statuses include enforced, attested, demonstrated, planned, and unsupported. A mechanism existing in code does not make its public claim enforced; the control must also be wired into the path it is meant to govern.

flowchart LR
    C["State a bounded claim"] --> T["Try to refute it"]
    T --> R[("Record the result")]
    R --> D{"Claim still supported?"}
    D -->|yes| K["Keep its status and scope"]
    D -->|no| N["Narrow the claim<br/>or strengthen the control"]
    K --> C
    N --> C

SuperDomestique's Sentry mechanism provides a useful example. Its original architecture record described a kill switch as un-subvertable by construction. Adversarial tests later showed that a worker running as the same system user could rewrite shared run records and suppress a stop. The architecture record was materially amended, the claim became conditional, and the required content-integrity boundary became explicit.

Downgrading the claim strengthened the engineering record. The narrower claim is defensible, and the required integrity boundary gives future work a testable target.

What the current implementation establishes

Commissaire is the governance system inside SuperDomestique. In the current faff distribution, Commissaire is a logical code region, not a separate package, process, service, or security boundary.

Commissaire records evidence, checks objective rules, and controls whether work may cross a boundary. Agents and people still provide engineering judgement.

The strongest current enforcement point sits outside the agent's process. When governance-check is configured as a required branch-protection check, a cooperating agent cannot omit it and merge through the normal path. The repository owns that live binding; shipping the validator alone does not make the check mandatory.

governance-check validates the records it receives. The check does not yet prove that every record was authored honestly. The public evidence therefore does not support an unqualified claim that complete L4 operation has been independently verified.

The opening paper, When Nobody Is Watching, asked who takes responsibility for the supervising person's functions when they leave. At a consequential boundary, a binding control supplies one part of the answer: adequate evidence lets routine work proceed without scheduled approval, while uncertainty produces a visible refusal or a request for human judgement.

Before granting a system a consequential action, ask which claim justifies the action, who produced and could alter the evidence, and which control can refuse when the evidence is missing or uncertain. If no control can refuse, the evidence remains only a paper trail at that boundary.

Which evidence in your current workflow can actually stop the action it is supposed to justify?

Implementation and evidence