evidence gates for AI work

Evidence gates for AI work are checkpoints where a claim has to be backed by something you can inspect before the work moves forward. The need is practical. An agent will report that it fixed the bug, added the tests and left everything else untouched, and it will say so with equal confidence whether or not that is true. Reading the diff helps but does not settle it: a diff shows what changed, not whether the change is correct or whether the right checks ran. A gate turns the claim into a procedure. Before execution, the gate asks whether the work is authorized. After execution, it asks whether the checks ran and what they returned, and it records the answer. The result is that acceptance becomes a decision made on recorded evidence by a person, not an inference from the agent's tone. This page explains the two kinds of gate and how Liquid Brain implements them.

Gate one: proposed versus approved

The first gate sits before the run and separates two things that are easy to blur. A proposal is what someone wrote down: this task should change these files. An approval is a decision that this execution may go ahead with this authority. Editing a task description is not approving it, and a system that treats the two as the same lets anyone with edit rights grant an agent permission by accident. Good practice keeps them distinct, makes approval revocable, and checks it again at the moment of execution rather than only when the task was created. It also pairs with boundary checks during the run: command guards that refuse obviously out of bounds actions and scope rules that compare touched files with the declared area. These are tripwires, not a sandbox, and they are most useful when you are honest about what they cannot catch.

Gate two: checks and recorded outcomes

The second gate sits after the run. It executes the verification you defined, such as tests, a linter or a targeted script, and records the result alongside the attempt: what ran, what it returned, which paths changed and what happened to the commit. Three cautions apply. First, a passing check proves only what the check covers, so state what it covers. Second, evidence goes stale. A recorded result is only meaningful if the files it speaks about have not changed since, and comparing hashes can tell you that, though unchanged bytes say nothing about whether the check was adequate. Third, absence is not zero. If usage numbers or results are missing, record them as unknown, since treating a gap as a clean result is how bad work gets accepted. The final step stays human: a person looks at the recorded evidence and accepts or rejects.

The gates in Liquid Brain

Liquid Brain keeps proposed card scope separate from approved execution authority [N09]. A card edit does not automatically grant execution permission, and authority can be revoked [N09]. Configured command guards and scope controls check work against declared boundaries [C5]. Work can run through verification gates, with recorded attempts, outcomes and reported usage kept with the work [C4]. Evidence freshness shows whether recorded evidence still matches its supporting files [C6], and missing usage stays unknown rather than becoming zero [N06]. Admitted operations get durable receipts, and stale edits are refused instead of overwriting newer work [N10]. By default, accepted managed harness work moves to a verify state, leaving final acceptance with a person, which keeps the agent saying it finished separate from you agreeing that it did [C4].

QUESTIONS

What is an evidence gate in AI-assisted development?

It is a checkpoint that requires inspectable evidence before work advances: authorization before execution, and recorded check results after it. The aim is to make acceptance depend on facts you can review rather than on the agent's own report that it succeeded.

Does a passing test suite prove the agent's change is correct?

Only for what the tests cover. A passing run is evidence, not proof, and it can be stale if files changed afterward. Liquid Brain shows whether recorded evidence still matches its files [C6], but unchanged bytes do not establish adequacy.

Can editing a task description authorize an agent to run?

It should not. In Liquid Brain, proposed card scope is kept separate from approved execution authority, and a card edit does not automatically grant execution permission [N09]. Approval is a distinct decision, checked when execution is requested, and it can be revoked. That separation stops an accidental edit from becoming an accidental run.

RELATED GUIDES

• What is a project management harness?
• How to read project progress in Liquid Brain Build
• How to read Liquid Brain reports and provenance

RELATED HARNESS PAGES

• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.
• scheduled agent tasks Scheduled agent tasks done carefully: explicit prompts, readiness and authority checks, and why a started run is not a finished one.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.