DoneState docs / Concepts
A control plane for bounded repository outcomes
The product is easier to use when you separate six ideas: desired state, authority, durable execution, external effects, reviewable publication, and independent proof.
High-level architecture
Operator / MCP client / CLI
│
▼
Bounded objective + authority
│
▼
Durable DoneState run ──► isolated implementation + validation
│
├──► branch / pull request (when authorised)
│
▼
sealed verification handoff
│
▼
independent verifier (for example OpsTruth)
│
▼
VERIFIED / failed / uncertain evidenceDesired state
A goal is not a shell script. It states what should become true. Acceptance criteria make that desired state observable enough for deterministic checks and independent review.
Durability and recovery
- 01
Intent is recorded before consequence
Consequential work is represented in durable state instead of relying on an ephemeral model conversation as the only memory. - 02
Interruption does not imply safe repetition
If an external mutation may already have occurred, DoneState reconciles what can be observed instead of blindly issuing the same effect again. - 03
Ambiguity is a first-class state
When DoneState cannot prove whether a consequential remote effect occurred, AMBIGUOUS_EFFECT preserves that uncertainty.
Publication is not completion
A branch or pull request is a reviewable remote effect. It is not proof that the objective is correct, and a pull request is not permission for DoneState to merge itself.
Independent verification
The verifier observes the sealed subject. DoneState can validate the verifier's identity, signature, nonce, report shape, and subject binding, but the execution system does not become independent by signing its own result.