Governance templates
Three templates and one description. All four are practice rather than mechanism, and all four are published in full.
AI agent charter
When agents write production code they need the governance a developer has, and a little more. The ladder is about how much an agent may do before a person looks. The list under it is about what nobody delegates, at any rung.
The autonomy ladder
L1 · Supervised
The agent proposes and a person reads every line before it merges. The default for every new agent.
L2 · Semi-autonomous
The agent implements inside a defined ticket scope and a person reviews the pull request. Reached after three L1 cycles with no fence violation.
L3 · Autonomous within guardrails
The agent implements, tests and opens the pull request; a person reads the test results and the guard output. Requires mature fence coverage and a track record. Rare, and it should stay rare.
Never autonomous
A person decides these, at every rung of the ladder.
- Database schema changes.
- Security configuration: authentication, secrets, network.
- External interface contracts, where the change breaks a caller.
- Changes to an output format that a regulation reads.
- Deletion of anything in the audit trail.
- Changes to the fence system itself.
The agent's source of truth
Architecture documentation first, then the key registry, then the fence system, then the ticket scope. Where two of them disagree, the higher one wins, and the disagreement is written down rather than resolved silently.
Audit trail schema
The record written at every step, published in full. A trail that cannot be read by somebody who did not build the system is not a trail, so the field names are part of the framework rather than an implementation detail.
| Field | Meaning |
|---|---|
| trace_id | The identifier of P-4, the same value on every entry that belongs to one transaction. |
| timestamp | When the step happened, as a timestamp with its offset. |
| event_type | Which kind of step: intake, extraction, validation, confidence assessment, human verification, publication, access. |
| actor | Who acted, and of what kind: the system, a person, or an agent. |
| input | What the step was about: the document, the attribute. |
| output | What the step produced: the value, its confidence, the extraction method. |
| decision | Where a person acted: what they did and the reason they gave. |
| source_hash | A digest of the source the step read, so the same input can be recognised later. |
| immutable | The entry is never edited. A correction is a new entry that supersedes it. |
Fence registry, a published subset
A published subset of the project's own registry, with the identifiers the project actually uses. Each entry carries an identifier, the rule, how the rule is enforced and its current status. The full registry is longer and stays internal: some of its entries name what they protect, and a list of what is watched is a map of what is guarded.
The identifiers are the operational ones. An earlier edition of the framework document printed an eight-row illustrative table under the same numbers with different rules; that template is retired, every one of its rules was carried across to the identifier that now holds it, and nothing was lost in the renumbering.
| Fence | Rule | Enforcement | Status |
|---|---|---|---|
| F-03 | Values derived by a language model always carry the method they were extracted by and never reach a published output without human verification. | Automated check, on every change | Enforced |
| F-04 | A required attribute with no evidence is never fabricated and never defaulted. | Automated check, on every change | Enforced |
| F-05 | No real personal or company documents in code, fixtures, tests or commits.Scope: The guard covers export-document access keys and issuer data. It does not cover every identifier shape, and the residue is carried internally as its own gap. | Automated check, on every change | Enforced |
| F-08 | A passport carrying a low-confidence or missing required attribute is never published; the publication gate is code, not a habit. | Automated check, on every change | Enforced |
| F-09 | No database schema change without a migration and a working downgrade. | Automated job, on every change | Enforced |
| F-13 | The tenant and trace identifiers travel with every request and every stored row.Scope: The request-path half is tested. The stored-row half is not asserted column by column, and is carried internally as its own gap. | Automated check, on every change | Enforced |
| F-14 | Code and identifiers in English; reader-facing copy in five locales, with every key present in every one. | Automated check, on every change | Enforced |
| F-16 | Interface copy never asserts legal conformity or an unverified fact; an attestation renders as an attestation and never as a verification. | Automated check, on every change | Enforced |
| F-18 | A trace identifier on every console interface response, errors included; an incoming one is honoured rather than reminted. | Automated check, on every change | Enforced |
| F-22 | Every factual claim on a public surface resolves to a primary source or to a named test. | Automated check, on every change | Enforced |
| F-23 | The running site loads only same-origin resources and sets exactly one cookie, for language. | Automated check, on every change | Enforced |
| F-37 | Every crawled public page meets WCAG 2.2 AA in a real browser. | Automated job, on every change | Enforced |
| F-02 | No new infrastructure service beyond the agreed set, and no new dependency without a named section in the change request. | Named person, at merge | Manual |
| F-10 | No merge with failing checks. | Named person, at merge | Manual |
| P-4-not-null-columns | Every stored row carries the tenant and trace identifiers as required columns. | Nothing today | Gap |
| P-5-disclosure-rendered | A published output whose attributes include a machine-extracted one always renders the disclosure line. | Nothing today | Gap |
The confidence engine, in words
The engine is given an attribute, a value, the method the value was extracted by, and the documents it came from. It returns the attribute, the value, a confidence level, the provenance and whether a person verified it. Three levels exist, the lowest never reaches a published output, and where evidence is absent the engine returns nothing at all rather than a level.
Not published
The table that maps an extraction method to a level, and the rules that combine several sources, stay in the internal edition. What is above is the description a reader needs in order to understand the architecture. It is deliberately not a specification anybody could build from.
Public feedback
Disagree with an assumption, found a source issue, or applied this in practice? Contributions are reviewed before publication and stay linked to this version.