Case study · Engineering
Engineering Review & Assurance System
Review surface implemented · 971 proof assertions executed across its 17 specified parts.
The problem
AI coding agents are fast but hard to trust. Overseeing agent-built software needs a screen that never confuses no data with nothing to do, never lets the system being reviewed supply its own approval, and shows where every claim came from.
Review-surface architecture
A standalone review application that any governed system is meant to plug into: it shows that system's lifecycle state, with provenance behind each claim, and lets the designated reviewer record the decisions that state shows to be due.
The code is organised as one responsibility directory per specified part, each implementation paired with its own executable proof.
Five areas
- Intake
- validating and containing incoming state
- Attention
- deriving what is due
- Authority
- establishing who may approve
- Recording
- gated decisions
- Presentation
- attributed claims, failure presentation, a goal-tree view
Routes are thin; the logic lives in the domain units.
Provenance-first approval
The authority matcher has no parameter through which an approver could be supplied: it reads the authoritative designation record and returns that record's hash as the binding, so a client-supplied approver is unreachable rather than merely rejected.
The actor is resolved at the server boundary, and refusals are typed. Claims whose origin cannot be established are refused at presentation.
Evidence and traceability
Each proof is bound by SHA-256 to the accepted specification revision, so a proof cannot silently drift from the text it proves.
Not due and undeterminable are separate types, so the screen cannot show an all-clear when it lacks data. Unreadable input at the trust boundary is contained, never absorbed.
- Evidence
Each claim carries its provenance; a proof is bound by SHA-256 to the specification revision it proves.
- Review
The surface derives what is due. "Not due" and "undeterminable" stay separate, so missing data never reads as all-clear.
- Authority
The approver comes from the designation record. A client-supplied approver is unreachable, not merely rejected.
- Decision
Only the designated reviewer records a decision, bound to that record; the system under review can never approve itself.
Governance boundaries
What it does
Shows state, provenance and due decisions; records decisions only from the designated reviewer.
What belongs elsewhere
Running and scheduling work belongs to the workflow authority, and every decision belongs to the designated reviewer.
Its interim role: a control-panel shell that frames the Lead engine's board, a UI framing rather than an API dependency.
Verified testing
17 of 17 proof files exit successfully, with 971 passing assertions and no failures, run against the completed implementation in October 2026.
Scope
These assertions prove the review surface: intake, attention, authority, recording and presentation.
Context
Each part is proved in isolation against its specified behaviour, and every proof is bound by SHA-256 to the specification revision it proves.
How it relates to the method
The homepage's Architect, Build, Verify, Deliver is an editorial summary. The actual governed lifecycle has eleven stages; each exits only on recorded evidence and a reviewer's decision.
- 01 Capabilities
- 02 Questionnaire
- 03 Operator review
- 04 Goals
- 05 Patterns
- 06 Structure
- 07 Design
- 08 Specification
- 09 Implementation
- 10 Integration
- 11 Stage 11
Editorial mapping
- Architect
- capabilities through structure
- Build
- design through implementation
- Verify
- the proofs and review
- Deliver
- integration and acceptance