The governance kit
Most agents have no governing document.
The control plane assumes one exists. It versions it, scores it, gates its promotion and stamps it onto every run. That is the second half of the problem. The first half is that the document has to be written, and a compliance officer will not author a tool-use policy from scratch — neither will most engineers.
These four files are the first half. They are the same files a licensee receives, read from the repository rather than copied here, so the method described and the method shipped cannot drift.
The order it runs in
01
Extract
Read the agent's code. Its current prompt, every tool it can reach, every external write, what data it touches.
02
Interview
Derived facts first, as corrections rather than questions. Then the ones that cannot be derived, because they are policy and live in a person's head.
03
Draft
Fill the template. Anything unanswered is UNRESOLVED, never a plausible value.
04
Derive fixtures
Every clause produces at least one case. Every case names the clause it tests.
05
Review and score
A human edits. The suite runs. The gap between the document and the agent's actual behaviour is the work list.
06
Promote
A human promotes. The eval gate decides whether that is permitted.
The two rules
Never invent a policy judgement
Not what counts as irreversible, not who may approve, not the acceptable escalation rate, not the cost asymmetry. These are organisational decisions. An invented threshold reads exactly like a decided one on the page, and someone will follow it. A blank stops them. Unfilled means UNRESOLVED.
Every constraint gets a case
And every case names its clause. Traceability in both directions or it is not traceability. A constraint with no case is decoration that reads like governance in a review and constrains nothing at runtime. A case with no clause is an opinion someone encoded on a Tuesday, and when it goes red nobody can say whether the agent broke or the test was always wrong.
The files
Wiring it in
The code that reads the documents. The loop, the two integration paths, and the promotion gate.
integration.md
The governing document
Twelve sections, each carrying the reason it exists. The output shape everything else aims at.
governing-document.template.md
The interview
The questions that fill it, split into what can be derived from code and what can only be asked.
interview.md
From clauses to fixtures
How every constraint becomes an eval case, and the completeness check that blocks a baseline.
fixture-derivation.md
The builder's own document
The agent that runs the interview, governed by the template it writes with.
document-builder.governing-document.md
The templates and the question bank are complete and usable by hand today. The interview is not yet automated, and the completeness check described in the fixture rules is specified but not yet implemented in the harness. Both are stated here rather than implied: a kit that looks automated and is not costs more than one that says where it stands.