§ Instrument · A8

AI system record

Twelve fields that say what an AI system is for, what it is allowed to do, how anyone would know whether it is behaving, and who answers for it. One record per system, kept with the system and revised when the system changes. A reviewer, an auditor or a buyer should be able to read it in ten minutes and know what questions remain. It is published as the instrument itself, not a description of one.

The record is deliberately short. A field that cannot be filled in is a finding, not a formatting problem.

↓ Download as Markdown
§ 01

How to use it

Three rules.

Write it before launch, and keep it with the code. The record lives in the system's repository, versioned with it, so that the version of the record always matches the version of the system it describes. A record kept in a document store drifts within a quarter.

Every claim points at an artifact. Each field names the evidence behind it: the evaluation report, the test that pins a guardrail, the log that shows oversight happened. A sentence with nothing behind it is written as an open question, in the last field.

Someone signs it. The owner named in the record has read it, agrees with it, and is the person a reviewer calls. A record without a name is a description, not a commitment.

§ 02

The twelve fields

In the order a reviewer reads them. Italic text shows what a complete entry contains.

01Purpose and boundaryWhat decision or task the system supports, for whom, and what it is explicitly not for. One paragraph; the non-goals are as important as the goals.
02Where it sitsThe systems it reads from, the systems it writes to, and the human step between its output and any consequence. A diagram with the write paths marked; the system of record named.
03PermissionsWhat the system may read, what it may write, what it may send, and what it may never do. A table of allowed actions; for an agent, the tools it holds and the approval each one needs.
04DataThe data it uses at run time and, if applicable, the data it was trained or tuned on; where each lives, who can see it, how long it is kept. Sources, retention, the personal data in it, and the lawful basis where one is needed.
05Models and componentsWhich models or services it depends on, at which versions, hosted where, and what happens when one is unavailable or changes. Vendor, version, region, fallback behaviour, the date last reviewed.
06EvaluationHow it was tested against the real task, on what set, with what result, and how often it is re-run. The evaluation set's origin and size, the metrics, the last result, the threshold that would stop a release.
07GuardrailsWhat prevents it from acting outside its purpose, and how each guardrail is verified. Validators, caps, filters and refusals, each with the test that pins it.
08Human oversightWho reviews its output, before or after it takes effect, with what capacity, and what they can override. The review step, the people, the approvals per day they can actually give, and what happens when output outruns them.
09Traceability and loggingWhat is recorded for each action so that it can be explained afterwards, and for how long. Fields logged, retention, who can read the log, the query that answers "why did it do that".
10Known limits and failure modesWhere it is known to be weak, what it does when uncertain, and the incidents so far. A plain list; an empty list on a system in production is itself a finding.
11Ownership and changeWho owns the system, who may change it, how a change is reviewed, and how this record is kept current. Names and roles, the review path, the trigger for revising the record.
12Open questionsWhat the authors could not answer when the record was written, and who is finding out. Each with an owner and a date.
§ 03

Reading one as a reviewer

What a complete record lets you do, and what an incomplete one tells you.

Read fields one, three and eight first. Together they say what the system is for, what it may do, and who stands between it and a consequence. If any of the three is vague, stop there: the rest of the record describes a system nobody has fully decided on.

Then read six and seven against each other. An evaluation without guardrails means the system behaves well on the test set and is trusted everywhere else; guardrails without an evaluation mean nobody knows how often they fire. A system ready for production has both, and the record names the test behind each.

The record maps onto the documentation regulators and standards ask for: the risk and oversight requirements for high-risk systems in the European Union, management-system standards for AI, and the common risk-management frameworks. It is shorter than any of them on purpose. It is the page you would want to have written before being asked for the rest.

§ 04 — Contact

A system in production, and no record for it?

The first record is scoped as a week's work. Say what the system does and who owns it.

Direct
Start a Conversation