A team can preserve a decision history by maintaining a versioned decision record for every model or vendor change. A revised decision should create a linked new entry, while the earlier entry remains readable and is marked as superseded rather than silently overwritten.
The record should show not only the final choice, but also the evidence, risks, alternatives, and unresolved questions that shaped it at the time.
What each decision record should preserve
The following structure is a practical implementation, not a template prescribed by the cited sources.
| Record element | Question it should answer |
|---|---|
| Change request | What change is being considered, and what prompted the review? |
| Scope | Which use case, workflow, or dependency is affected? |
| Options | Which candidate models or vendors were considered, and which were excluded? |
| Evidence | What performance data, limitations, and relevant artifacts informed the review? |
| Metric definitions | What does each metric mean, and what data shows performance against it? |
| Risk record | Which risks were identified, including existing, unanticipated, and emergent AI risks? |
| Rationale | Why were the options accepted, rejected, or deferred? |
| Decision | What was decided, who exercised the decision authority, and what conditions remain? |
| Unresolved questions | What missing evidence or approvals still affect the decision? |
| Revision link | Which earlier record does this entry replace, amend, or supersede? |
A later change should identify what changed in the evidence, risk assessment, constraints, or rationale. Replacing only the conclusion would break the chain of accountability.
How to check that the history is usable
A later reviewer should be able to answer the following from the records alone:
- What was being considered? The entry should identify the proposed model or vendor change and its scope without relying on team memory.
- Why was the review initiated? The record should distinguish a new evaluation from a change triggered by new evidence, an identified risk, or another documented cause.
- What alternatives were examined? The record should preserve the options considered and the reasons for excluding or deferring them.
- What did the metrics mean? GOV.UK’s Service Manual says service metrics need a clear meaning and data showing how a service performs against them. Each metric used in the record should therefore have a definition, an identified data source, the result, and any material limitations.
- Which risks were tracked? NIST’s AI Risk Management Framework says risk tracking should regularly identify and track existing, unanticipated, and emergent AI risks. Risk entries should preserve their status and subsequent follow-up rather than compressing the entire assessment into the final decision.
- Why did the decision follow from the evidence? The rationale should connect the recorded metrics, risks, and constraints to the outcome without rewriting what was known at the time.
- What happened next? A revised decision should add a new linked entry explaining the change. The earlier record should remain available for comparison.
The review is working when the record can be reconstructed without assuming that the newest entry explains every earlier judgment.
What the team must still confirm
The team must separately establish several details that the cited sources do not supply:
- Decision authority: Who can approve, reject, or reopen a model or vendor decision.
- Metric criteria: Which metrics apply, how they are defined, and what limitations affect their interpretation.
- Thresholds and targets: Any required threshold, target, or minimum result must come from an approved team standard or other applicable source; neither cited source provides a universal value.
- Review cadence: NIST calls for regular risk tracking, but the cited material does not establish a specific review interval. The team must set and document its own applicable cadence.
- Evidence quality: Whether the available data is sufficiently current, complete, and relevant for the proposed change.
- Change-specific requirements: Any applicable contractual, security, privacy, legal, or regulatory requirements must be verified separately. The two cited sources do not establish those conditions for a particular vendor or model.
- Record authority: Which system holds the official history, who may amend it, and how superseded records are retained.
The resulting history should be a chain of decisions rather than a collection of final choices. Each entry must preserve the options, evidence, risks, rationale, and open questions current at that point. Where a requirement or fact remains unverified, the record should state that gap instead of filling it with an assumption.