Templates: Runtime, Change and Retirement

The records produced after authorization: drift alerts, change classification with its delta assurance scope, the incident note, and the retirement record that keeps the evidence answerable after the system is gone.

Everything before deployment is a decision. Everything after it is a comparison: what is running against what was approved. These records carry that comparison, and the framework's central claim depends on them being cheap enough to produce that they actually get produced.

Routing is what makes drift detection survivable. Severity is a function of category and tier together, not category alone. Agent boundary divergence is the exception: it is an incident at any tier, because a boundary that has been exceeded once was never a boundary.

[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.

Drift / Alert Record

Purpose: A detected divergence between deployed state and approved state
Owner: System-generated; triaged by the owner the category routes to
Created at: On detection
Approval: Not approved — dispositioned
Update: Closed with a disposition; never deleted
Retention: 3 years, or the regulatory record period if longer
Related: Deployment Authorization Record (the baseline), Change Record, Risk Classification Record

Field	Required at	What good looks like
Detected state and approved state	All	Both, side by side. An alert that says something changed without saying from what is a notification, not a record.
Category	All	One of the eight. Mis-categorisation is what sends alerts to people who cannot act on them.
System and tier	All	Because severity is a function of both.
Detection source	All	Which comparison produced it, so false positives can be traced to a rule.
Severity and routing applied	All	From the triage table for this category and tier.
Disposition	All	Accepted (approved state updated), remediated (deployed state corrected), or escalated. Those are the only three honest outcomes.
Risk consequence	T2+	Whether it triggers a re-score, a delta assurance run, or a G4 entry.
Time to disposition	T2+	Measured against the tier's window; this is the metric that shows the process is real.
Recurrence	T3+	Whether this has fired before, and what was done then.

How to fill it. Two failure modes dominate. Alerts with no owner accumulate until the whole feed is ignored — so route on the category and tier before you turn a signal on. And “accepted” dispositions that never update the approved state mean the baseline is now fiction; if you accept the drift, change the record it drifted from.

Plain-text version to copy into your own tooling

DRIFT / ALERT RECORD
Alert id:        System:        Tier:        Detected at:
Approved state:        Detected state:
Category (1-8):        Detection source:
Severity and routing applied:        Owner:
Disposition: [accepted -> approved state updated / remediated / escalated]
Risk consequence: [none / re-score / delta assurance / G4]
Time to disposition:        Recurrence:

AI Change Record and Delta Assurance Scope

Purpose: What changed, how it was classified, and what assurance was re-run
Owner: System Owner
Created at: S9, before the change is applied
Approval: Routed to the authority for the post-change tier, not the pre-change tier
Update: Closed after the change with the actual scope run
Retention: Life of system plus 3 years
Related: Deployment Authorization Record, Assurance Summary, Risk Classification Record

Download AI Change RecordDOCX · 12 KB

Field	Required at	What good looks like
Change description	All	What is actually changing, in the terms the authorized configuration uses.
Classification	All	Cosmetic, Minor, Material or Major, against the change-type table. State the reasoning, not just the label.
Second-person confirmation	T3+ where cosmetic or minor is claimed	The cheapest control against the most common classification abuse.
Dimensions touched	All	Which of D1–D5 the change affects, and the re-scored values.
Post-change tier	All	Determined before routing. Approval goes to that tier's authority.
Delta assurance scope	T2+	What is being re-run and — the important half — what is not, with the reason. “Full re-run” and “no re-run” are both suspicious defaults.
Autonomy change	All	Explicitly yes or no. Any increase in what the system can do without a human is a change type in its own right and never cosmetic.
Rollback plan	T2+	How to get back, and how long it takes.
Supplier-initiated?	All	Whether this change originated outside your organization. Supplier changes are the most common uncontrolled change in every sector.
Post-change verification	T3+	What is checked after deployment, and by when.

How to fill it. Classify before you scope. Teams routinely decide what testing they can afford and then choose the classification that permits it. Recording the dimensions touched first makes that inversion visible.

Plain-text version to copy into your own tooling

AI CHANGE RECORD
System:        Change ref:        Date:        Requested by:
Change description (in authorized-configuration terms):
Classification: [cosmetic / minor / material / major]  Reasoning:
Second-person confirmation (T3+ if cosmetic/minor claimed):
Dimensions touched and re-scored values:
Post-change tier:        Routed to:
Delta assurance: what IS re-run / what is NOT and why:
Autonomy change? [Y/N]  Detail:
Rollback plan and duration:
Supplier-initiated? [Y/N]  Notification received:
Post-change verification and date:

AI Incident Note

Purpose: A short record of an AI-specific incident and what it changed
Owner: System Owner, feeding the existing incident process
Created at: On incident
Approval: Not approved — reviewed
Update: Closed with the actions taken
Retention: Per the incident policy, minimum 3 years
Related: Drift/Alert Record, Risk Classification Record, Assurance Summary

Field	Required at	What good looks like
What happened	All	In plain language, including what the system did and what a person did.
Detection	All	How it was noticed, and how long after it started. The second number is the one that improves the system.
Consequence	All	Who was affected and whether it can be undone. This is D1 and D3 meeting reality.
Contributing factors	T2+	Including the governance ones: a missing control, a stale record, an unowned source.
Classification consequence	T2+	Whether the incident invalidates a recorded score or an assurance result.
Actions and owners	All	With dates. An incident with no dated action is a story.
Calibration value	T3+	What this incident says about a threshold or anchor. These are the observations the framework most needs and most rarely gets.

How to fill it. Keep it short. The purpose is not investigation — your incident process already does that — but to connect what happened back to the governance records that were supposed to prevent it, and to capture anything that should recalibrate a default.

Plain-text version to copy into your own tooling

AI INCIDENT NOTE
System:        Date / duration:        Severity:
What happened (system behaviour and human behaviour):
How detected; time from onset to detection:
Consequence; who affected; reversible?
Contributing factors (including governance factors):
Does this invalidate a score or an assurance result?
Actions, owners, dates:
Calibration value (threshold or anchor this challenges):

Retirement and Decommissioning Record

Purpose: Evidence that the system was withdrawn safely and remains answerable afterwards
Owner: System Owner
Created at: S10; approved at G5
Approval: Gate G5
Update: Closed when the last dependency is cleared
Retention: The longest applicable record period; often outlives the system by years
Related: Data Lineage Record, Deployment Authorization Record, Evidence archive

Field	Required at	What good looks like
Reason for retirement	All	Replacement, obsolescence, risk, or value. Useful when the same question returns.
Downstream consumers identified	All	From telemetry, not only from documentation. The consumers nobody documented are the ones that break.
Data disposition	All	Retention or deletion against the schedule, including derived stores: indexes, embeddings, caches, evaluation sets.
Access revocation	All	Including machine identities, which are routinely missed.
Evidence archived and retrievable	All	Not merely stored — retrievable, in a readable form, after the platform is gone. Test one retrieval.
Ability to explain historical decisions	T3+	Whether you can still say what the system decided and why, for the duration of the liability window.
Knowledge preservation note	T2+	What was learned, including what would be done differently.
Model and artifact disposal	T2+	Where model weights, prompts and configurations went.
Residual obligations	T3+	Regulatory reporting or contractual duties that survive the system.

How to fill it. Retirement is the gate that gets skipped, and the cost appears years later when someone asks about a decision the system made. The two fields worth defending are retrievability of evidence and deletion of derived stores.

Plain-text version to copy into your own tooling

RETIREMENT AND DECOMMISSIONING RECORD (G5)
System:        Retired on:        Approved by:
Reason for retirement:
Downstream consumers (from telemetry):
Data disposition incl. derived stores (index, embeddings, cache, eval sets):
Access revoked incl. machine identities:
Evidence archived; retrieval tested on:
Ability to explain historical decisions; until when:
Knowledge preservation note:
Model / prompt / config disposal:
Residual obligations: