A design of record is the authoritative, versioned description of an AI system’s models, tools, data sources, and identities. It gives auditors and operators a single reference point for verifying what the system is supposed to be and whether it has drifted.
What a design of record establishes
A design of record is the system’s authoritative reference for what exists, how it is assembled, and what should be present at runtime. For AI systems, that matters because model choice, tool inventory, data sources, and identity relationships can all change system behaviour without an obvious code change.
The core value is governance through versioned truth. When operators, auditors, and developers all work from the same baseline, they can distinguish intended evolution from undocumented drift, shadow changes, or emergency exceptions that were never folded back into the system description.
Why the design of record matters for AI governance
AI systems are often composed of multiple moving parts, so the design of record becomes the control point that ties architecture, ownership, and review together. It helps answer whether the deployed system still matches approved intent, and whether the security posture has changed because a tool, dataset, or identity was added quietly.
This is especially important when the system relies on external services or delegated access. If the design of record is incomplete, reviewers may miss inherited trust relationships, overbroad permissions, or undocumented dependencies that never appear in a model card or a deployment note.
For organisations building or operating agentic or tool-using systems, the authoritative description should make ownership and boundaries obvious. A useful reference point is NIST AI Risk Management Framework, which is often used to anchor AI governance and accountability discussions.
What belongs in the record and how it is used
A strong design of record usually captures the minimum facts needed to reconstruct the intended system: which model or models are approved, which tools the system may call, what data sources it may use, and which identities or service relationships it depends on. It should also record the versioning, approval state, and ownership needed to interpret change over time.
That record is not just documentation for its own sake. It is the evidence base for architecture review, change approval, audit validation, and drift investigations. If something behaves unexpectedly, the first question is often whether the live system still conforms to the recorded design.
Because the concept is versioned and authoritative, it also supports comparison. Teams can diff the current deployment against the recorded baseline to find unauthorised tools, stale integrations, missing controls, or identity paths that were introduced after approval.
How design of record supports drift detection and accountability
The term is most useful when the organisation treats the design as a control object rather than a static document. In practice, that means the record should be current enough to expose divergence between approved architecture and running reality, including changes to dependencies that affect security or reliability.
It also creates accountability. When each approved system element has an owner, reviewers can trace why a model, dataset, tool, or identity is present and who accepted the associated risk. Without that line of sight, drift becomes easy to normalise and hard to reverse.
In maturity terms, the design of record is the place where architecture, operations, and governance meet. It reduces ambiguity by making the intended system legible to both humans and control processes, which is what makes later assurance work possible.
Risk and Threat Considerations
When the design of record falls out of date, the main risk is silent drift: the live system no longer matches the approved one, but the discrepancy is not visible to reviewers. That creates exposure around unauthorised tools, stale data sources, inherited trust, and identity relationships that were never formally assessed.
Failure mechanism: A system changes through fast iteration, emergency fixes, or third-party integration, while the recorded baseline is not updated. The gap hides privilege creep, undisclosed dependencies, and control assumptions that no longer hold.
Impact: Auditors may certify the wrong system, operators may trust an unsafe baseline, and attackers may exploit undocumented paths, especially where tool access, service identities, or data connections were added without review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — Govern | Design of record supports AI governance, accountability, and documented system oversight. |
| Recommendation — Maintain an approved, versioned system baseline and review changes through governance controls. | ||
| ISO/IEC 42001:2023 | 8.1 — Operational planning and control | A design of record helps control AI system operation against approved specifications and changes. |
| Recommendation — Keep AI system operations aligned to documented and approved configurations. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The term is fundamentally about an authoritative configuration baseline for the system. |
| CM-3 — Configuration Change Control | Versioned record and drift control depend on managing changes to the baseline. | |
| CA-7 — Continuous Monitoring | A design of record enables ongoing comparison between intended and actual system state. | |
| Recommendation — Establish and maintain a current baseline for approved system components and settings. Review, approve, and document changes before they alter the recorded system design. Continuously compare live system state to the approved baseline and investigate drift. | ||
Practitioner Guidance
Why practitioners should care: The design of record should be treated as a living assurance artifact, not a one-time architecture diagram. If it is not maintained with the same discipline as deployment state, it becomes a false source of truth.
What to watch for: Untracked model swaps, newly added tools, data source substitutions, and identity changes are the most common signs that the recorded design no longer matches production reality. Those changes should trigger a baseline review, not just a documentation update.
Practitioner takeaway: Keep the record authoritative enough that a reviewer can use it to answer, without guesswork, what the system is supposed to be and what changed since the last approved version.
Related resources from NHI Mgmt Group
- How should security teams design AI investigation streams so reconnects do not corrupt the record?
- How should security teams design zero touch provisioning so onboarding can start from an authoritative system of record without manual intervention in the access platform?
- How should organisations design audit logging for delegated agent actions so the record survives multiple hops?
- How should healthcare organisations design patient data platforms so clinicians can access a fuller longitudinal record without rebuilding everything around one monolithic EPR?