Chest: evidence-based completion checks for AI agents
- My contribution
- Design and implementation.
- Scope
- Project criteria, validation verdicts and persisted evidence reports.
- Evidence
- Implementation inspected at 4958af4; reconstructed examples are labelled.
Page by Julian Ramirez ·
An agent says the work is done. The tests ran, the files changed, and the summary sounds convincing. You still have to reconstruct what “done” was supposed to mean before you can decide whether to trust it.
That is the problem Chest addresses. It gives a project a place to record objectives, readiness criteria, completion criteria and the evidence used to evaluate work. The useful shift is from asking for another confident summary to inspecting a report against an agreement made earlier.
For me, that distinction matters more than the verdict itself. A check becomes useful when someone else can understand what it checked, what evidence it saw and what remains unresolved.
My contribution and design scope
I built Chest around explicit criteria and inspectable validation reports. The important design boundary is between recording a verdict and establishing what that verdict actually means. This case examines both the report workflow and the different fallback behavior in alignment and completion checks.
Define completion before asking an agent to deliver it
A task description names the work. Acceptance criteria explain how to recognize a satisfactory result. Without that second part, the agent and the reviewer can both act reasonably while evaluating different things.
Chest separates readiness from completion. Readiness concerns the plan and the conditions needed to begin; completion concerns the work and its evidence. Keeping those questions distinct makes it easier to spot a plan that was never ready, even if the resulting implementation looks polished.
Sources & implementation notes
The definitions live in local YAML files under the default .chest/ directory. That makes the criteria inspectable alongside the project instead of leaving them scattered across a conversation. Objectives and checks can be reviewed together, although the project still has to decide what its criteria should contain.
okrs.yaml → objectives kpis.yaml → checks definition-of-ready.yaml → readiness definition-of-done.yaml → completion Sources & implementation notes
A useful verdict can admit uncertainty
A binary success flag is tempting because it is easy to automate. It also erases an important distinction: evidence can contradict a requirement, or it can simply be insufficient to judge it.
Chest’s alignment judge represents those cases with passed, failed and needs_review. Explore the alternatives below. The third state gives a workflow somewhere honest to stop when the evidence does not support a decision.
Sources & implementation notes
The report is the more durable part of the workflow. It can retain a rationale, evidence references and follow-up actions, so the next reviewer does not have to infer why a verdict was returned. The exposed validation tools also persist their reports. This is the connection between checking work and leaving a usable record of the check.
Sources & implementation notes
Read the fallback before trusting the automation
There is an important boundary in the inspected revision. Calling judgeAlign without a configured provider returns needs_review. Calling validateDone without one follows a different path: a non-empty evidence description can receive passed.
Those are materially different assurances. A recorded pass from that fallback is not proof that the implementation satisfies every completion criterion. If a workflow treats the two results as equivalent, it can turn a useful reporting mechanism into false confidence.
Sources & implementation notes
The broad “missing judgment never means success” claim would be false at this revision. judgeAlign with no configured provider returns needs_review; validateDone can pass non-empty evidence without a provider. A configured provider failure can throw. These reports do not guarantee correctness.
This is why I would evaluate the report-producing path before building consequential automation around its status. The criteria, the provider configuration and the fallback all affect what a result means. Human ownership of deployment, exceptions and irreversible decisions still needs to be explicit.
Leave evidence the next person can use
Chest is most interesting as a way to make completion inspectable. Start with one task, define its criteria, then examine the resulting report and its limitations. That exercise reveals more than adding another approval prompt to the conversation.
The same idea connects to Logbook’s durable task handoffs: a future session needs both the work record and the basis for decisions already made. The broader governance question is explored in the Intervention Penalty.