AI Engineering and Product: Templates
Four working templates: the model card, the eval report, the guardrail specification and the autonomy boundary record.
Markdown. No sign-up, no email.
Four documents. Between them they answer the questions asked after something goes wrong: what was running, how did we know it worked, what was it meant to refuse, and how much was it allowed to do on its own.
Fill them in before shipping. Reconstructed afterwards, they are fiction.
1. Model card#
One per feature, updated on every release.
| Field | Entry |
|---|---|
| Feature | |
| Purpose | [What it does, in a sentence a customer would recognise] |
| Model and version | |
| Prompt version | |
| Guardrail version | |
| Eval-set version | [All four are needed to reproduce a result. Any one alone is not enough] |
| Intended use | |
| Out of scope | [Be specific. Vague scope is what gets stretched] |
| Known weaknesses | [Where it degrades. Every model has some; a card with none is unfinished] |
| Escalation behaviour | [What it does when uncertain] |
| Fallback behaviour | [What happens when the model is unavailable] |
| Disclosure | [How the user is told this is AI. Required in the EU since 2 August 2026] |
| Accountable person | [A name, not a team] |
| Last reviewed |
2. Eval report#
Attached to every release. No report, no release.
| Category | Cases | Pass rate | Floor | Delta vs last | Verdict |
|---|---|---|---|---|---|
| Common | |||||
| Edge | |||||
| Refusals | |||||
| Adversarial | |||||
| Blended | [Recorded, never used alone as the decision] |
| Any category below floor? | [If yes, the release is blocked whatever the blended figure did] |
| Cases added since last release | [Including any from incidents] |
| Contamination check | [Has anything here entered training?] |
| Accepted by | [Name and date] |
3. Guardrail specification#
| Field | Entry |
|---|---|
| Guardrail | |
| What it refuses | [Stated as a testable rule, not an intention] |
| What it escalates | |
| What it never says | |
| Test that proves it fires | [Reference the adversarial case] |
| Test that proves it does not over-fire | [The one usually missing. An over-broad guardrail refuses legitimate requests and the complaints look like unrelated bugs] |
| Owner | |
| Version and date |
4. Autonomy boundary record#
The shortest document here and the one that matters most in an incident.
| Field | Entry |
|---|---|
| Feature | |
| May do without a person | |
| Must hand to a person | |
| Worst plausible mistake | [Describe it concretely] |
| Cost of that mistake | [Money, trust, or a regulatory duty] |
| Reversible within | [Minutes, days, or not at all] |
| Boundary set by | [Name] |
| Date and next review | [Quarterly] |
Decision rule: the boundary is set by the cost of the worst plausible mistake, not by what the model is capable of. Widening it is a decision a person makes and records. It is never a side effect of upgrading a model.
Using these together#
The charter says what this function owns, the SOPs say when each template is produced, the KPIs define what the eval report feeds, and the workflows name who receives each one. A model card written without the SOP that governs it is a tidy document that changes nothing.