Templates: Intake and Classification
The three records that decide whether work starts, and at what tier it runs: the use-case canvas, the risk classification record, and the portfolio qualification record.
These are the cheapest records in the set and the ones with the most leverage. A canvas that hides the autonomy the team intends, or a classification that reaches Tier 2 by scoring reversibility on the mechanism, sets everything downstream to the wrong depth — and nothing later in the lifecycle corrects it.
[Practice recommendation] Fields are marked All, T2+, T3+ or T4. A Tier 1 record that fills every Tier 4 field is not more rigorous, it is less honest: the fields stop being answered and start being completed. Delete what your tier does not require and keep the record short enough that people read it.
AI Use-Case Canvas
- Purpose
- Business justification, intended use, and the provisional risk signal
- Owner
- Business Sponsor — named individual, not a function
- Created at
- S1, before any architecture or vendor conversation
- Approval
- Gate G1
- Update
- On any change of purpose, population or intended autonomy
- Retention
- Life of system plus 3 years
- Related
- Risk Classification Record (output), Capability Record (input), ADR (downstream)
| Field | Required at | What good looks like |
|---|---|---|
| Use-case name and reference | All | A name a non-specialist recognises. References are for systems; names are for conversations. |
| Business sponsor | All | A named person with the authority to stop the work. If nobody can stop it, nobody owns it. |
| Capability supported | All | The enterprise capability from the capability map, not a project or a department. |
| Problem statement | All | The current measure and the target measure. “Improve efficiency” is not a problem statement. |
| Expected outcome and baseline | All | A measure with a number you can read today, so the Benefit Record has something to compare against. |
| Why AI, and the alternative rejected | All | The non-AI option considered, and why it was rejected. This field is the one that ages best. |
| Decision or action the output supports | All | The sentence that determines D1. Write what happens after the output appears. |
| Affected parties | All | Everyone the output lands on, including people who never use the system. This sets D4. |
| Intended autonomy at launch | All | One of the four D2 anchors, in the anchor's words. Vagueness here becomes tier gaming later. |
| Intended autonomy trajectory | T2+ | Where the team expects autonomy to go in two years. Naming it early makes the later increase a planned change rather than a surprise. |
| Data expected | All | Categories and likely sources, with a sensitivity signal. Precision comes at S4; direction is needed now. |
| Provisional D1–D5 | All | Scored and marked provisional. Provisional scores that are never revisited are the most common classification defect. |
| Known regulatory or contractual constraints | T2+ | From the overlay for your sector, plus any client or supplier terms that prohibit the processing. |
| Stop criteria | T2+ | What would make you abandon this. A use case with no stop criteria has no honest evaluation. |
| Cost band and funding source | T2+ | Enough to route the portfolio decision, not a business case. |
| Human oversight intent | T3+ | Where a person will be in the path, what they will see, and what they can do. Not “human in the loop”. |
How to fill it. Write it in one sitting with the sponsor present. If a field cannot be answered, record that it cannot — an empty field with a reason is evidence; an invented one is noise. The canvas should fit on two pages: it is the document a G1 decision is taken on, and long canvases stop being read.
Filled example
Claims triage assistant. Sponsor: Head of Claims Operations. Capability: Claims Intake and Assessment. Problem: median time from notification to adjuster assignment is 4.2 days; target 1 day. Why AI: rules-based routing was trialled in 2024 and reached 61% correct routing against a 90% requirement. Decision supported: which adjuster queue a claim enters. Affected parties: all claimants, 340 adjusters, downstream reserving. Intended autonomy: recommendation with review — the system proposes a routing category and an adjuster approves each. Trajectory: no increase intended before the first assurance cycle. Data: claim notification text, policy record, prior claims history — restricted personal data. Provisional D1–D5: 3, 2, 2, 3, 3 (provisional). Stop criteria: routing accuracy below 85% on the held-out set, or adjuster override rate below 5% after three months.
Plain-text version to copy into your own tooling
AI USE-CASE CANVAS
Use case / reference:
Business sponsor (named):
Capability supported:
Problem statement (current measure -> target measure):
Expected outcome and baseline:
Why AI; alternative considered and rejected:
Decision or action the output supports:
Affected parties (including non-users):
Intended autonomy at launch (D2 anchor wording):
Intended autonomy trajectory:
Data expected (categories, sources, sensitivity signal):
Provisional D1-D5 [mark PROVISIONAL]:
Regulatory / contractual constraints:
Stop criteria:
Cost band and funding source:
Human oversight intent (T3+):
Risk Classification Record
- Purpose
- D1–D5 scores, the computed tier, and the reasoning behind both
- Owner
- Risk and Compliance Lead
- Created at
- S2; re-scored on every Material or Major change
- Approval
- Self-service for downward or lateral change at Tier 1–2; AI Governance Body for any upward change at Tier 3–4
- Update
- History preserved, never overwritten
- Retention
- Life of system plus 3 years
- Related
- Use-Case Canvas (input), Change Record (trigger), Control Matrix (downstream)
| Field | Required at | What good looks like |
|---|---|---|
| D1 Decision Consequence, 1–4 | All | Scored on the consequence of being wrong, assuming the output is acted on. One line of justification naming who is harmed and how. |
| D2 Autonomy, 1–4 | All | The anchor that matches the highest-autonomy path the system has, including the path used for the routine majority. |
| D3 Reversibility Deficit, 1–4 | All | Scored against consequence reversibility, never mechanism reversibility. State what cannot be undone. |
| D4 Exposure and Scale, 1–4 | All | The reach of the records the system writes into and the people affected, not the count of users. |
| D5a Data Sensitivity, D5b Model Uncertainty | All | Both sub-scores recorded. D5 is the higher of the two, not the average. |
| Computed Impact and Control Deficit | All | Impact = average(D1, D4, D5) rounded up. Control Deficit = average(D2, D3) rounded up. Show the arithmetic. |
| Resulting tier | All | From the matrix. Record the matrix cell, not just the answer. |
| Safety-override flag | All | Whether D1 = 4, or D2 = 4 with D3 = 4, forced a Tier 3 floor. |
| Effective-autonomy evidence and threshold | T2+ where D2 ≤ 2 and D1 ≥ 3 | The override-rate floor agreed before deployment, and the measurement method. |
| Countersignature | T2+ | An independent person, with any adjustments they made and why. This is the control against tier gaming; a countersignature that never changes a score is not operating. |
| Re-score triggers active | All | Which of the six triggers apply, and the date of the next scheduled review. |
| Score history | All | Every previous score set with its date and reason for change. Never overwrite. |
| Sector overlay applied | T2+ | Which overlay informed the anchors, if any. |
How to fill it. Score in a session, not in a document. Two people minimum, one of whom does not carry the delivery date. Work through the dimensions in order and write the justification before the number — the sentence usually corrects the score. Where a score is disputed, record both positions and who decided; a record that hides the disagreement loses the most useful information it had.
Filled example
Claims triage assistant. D1 = 3 (misrouting delays a claim and may disadvantage a claimant). D2 = 2 (proposes routing, adjuster approves each). D3 = 2 (routing reversible; elapsed delay is not). D4 = 3 (all claims; feeds the claims system of record). D5a = 3 restricted personal data, D5b = 3 generative, composite 3. Impact = avg(3, 3, 3) = 3. Control Deficit = avg(2, 2) = 2. Matrix cell Impact 3 / CD 2 → Tier 2. Override flag: none. Effective-autonomy threshold: adjuster override rate below 5% over 500 claims triggers a re-score of D2. Countersigned by Risk Lead; D3 raised from 1 to 2 — original score reasoned from mechanism reversibility.
Plain-text version to copy into your own tooling
RISK CLASSIFICATION RECORD
System / reference: Date: Scored by:
D1 Decision consequence [1-4] Justification:
D2 Autonomy [1-4] Justification (highest-autonomy path):
D3 Reversibility deficit [1-4] Justification (what cannot be undone):
D4 Exposure and scale [1-4] Justification (reach of records, people affected):
D5a Data sensitivity [1-4] D5b Model uncertainty [1-4] D5 = higher of the two
Impact = avg(D1,D4,D5) rounded up =
Control Deficit = avg(D2,D3) rounded up =
Matrix cell: Resulting tier:
Safety-override floor applied? [Y/N] Reason:
Effective-autonomy threshold (if D2<=2 and D1>=3):
Countersigned by: Adjustments made:
Re-score triggers active: Next scheduled review:
Previous scores (date, tier, reason for change):
Initiative Qualification Record (TG0)
- Purpose
- Evidence for the transformation qualification questions, before funding
- Owner
- PMO, with mandatory architecture input
- Created at
- T2, at portfolio intake
- Approval
- Portfolio governance, with architecture concurrence recorded
- Update
- On material change of scope or funding
- Retention
- Life of initiative plus 3 years
- Related
- Capability Record, AI Use-Case Canvas, Architecture Input Package
| Field | Required at | What good looks like |
|---|---|---|
| Initiative name and sponsor | All | As it appears in the portfolio, so the two records can be joined. |
| Capability and target maturity | All | The capability being moved, and from what to what. |
| AI content flag | All | Whether the initiative includes, procures or enables AI — including AI arriving as a feature of a platform. This flag is what routes the work into the AI lifecycle at all. |
| Architecture concurrence | All | Recorded, with the architect named. Where concurrence is withheld, the reason is recorded and the initiative may still proceed — but the withholding is visible. |
| Funding concurrence | T2+ | The funding-side check that stops an initiative bypassing architecture by being small. |
| Dependencies and sequencing | T2+ | Other initiatives this one assumes have already landed. |
| Known constraints | T2+ | Regulatory, contractual and data constraints identified at intake. |
| Bypass finding | T3+ | Where an initiative proceeded without qualification, the finding, its owner and the remediation date. |
How to fill it. The only field that matters on day one is the AI content flag, and the only way to get it right is to ask about content rather than contract value. Most ungoverned AI in a large organization arrived inside a purchase that was too small to trigger review.
Plain-text version to copy into your own tooling
INITIATIVE QUALIFICATION RECORD (TG0)
Initiative: Sponsor: Date:
Capability and target maturity:
AI content? [none / builds / procures / enables] Detail:
Architecture concurrence: [given / withheld] Architect: Reason if withheld:
Funding concurrence: [given / withheld] Reason:
Dependencies:
Known constraints:
Bypass finding (if any), owner, remediation date: