Templates: Architecture and Data
The records created at S3 and S4: the AI-extended architecture decision, the lineage and sensitivity record behind every grounding source, and the pattern library entry that lets the next team skip the queue.
These are the records that make later comparison possible. Drift detection compares deployed state against approved state, and the approved state is whatever these records say it is. A vague ADR does not just produce a weak decision; it produces a system nothing can be compared against.
[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.
Architecture Decision Record, AI-extended
- Purpose
- The architecture decision and its rationale, extended for AI-specific choices
- Owner
- Architect
- Created at
- S3
- Approval
- Tier 1–2 architect self-certification against a pattern; Tier 3–4 Architecture Review Board
- Update
- Superseded rather than edited; the superseded decision is retained
- Retention
- Life of system plus 3 years
- Related
- Pattern Library entry, Data Lineage Record, Agent Card, Deployment Authorization
| Field | Required at | What good looks like |
|---|---|---|
| Decision statement | All | One sentence, in the present tense, that a reader can disagree with. |
| Context and constraints | All | What made this decision necessary, and what was fixed before it. |
| Options considered | All | At least two, with the reason each was rejected. A record with one option is a note, not a decision. |
| Model and sourcing | All | Which model or service, hosted where, under what commercial terms, with what version identity. |
| Grounding and retrieval design | All | Which sources, how retrieved, how refreshed, and what the system does when retrieval fails. |
| Boundary of the system | All | What is inside this decision and what is somebody else's. Most drift disputes are boundary disputes. |
| Autonomy and action surface | T2+ | What the system can do, not just compute. If it can act, the Agent Card is mandatory. |
| Pattern conformance | All | Conformant, modified with the modification stated, or novel. Novel is a legitimate answer that costs a review. |
| Failure behaviour | T2+ | What happens when the model is unavailable, slow, or wrong. Fail-closed or fail-open, stated explicitly. |
| Vendor due diligence | T2+ for procured | Model provenance, change notification commitment, data use terms, audit rights, exit path. Where these cannot be obtained, either cap the tier or record the acceptance. |
| Concentration note | T3+ | What else in the estate depends on this supplier. Concentration is invisible per system. |
| Environmental and cost envelope | T3+ | Expected cost and its trigger for review. |
| Machine-readable boundary reference | T3+ agentic | Where the enforceable version of the authority boundary lives. |
How to fill it. Write the decision statement first and the options second. If the options were never real, say so — a recorded “this was the only viable option because X” is more useful than a manufactured comparison. Supersede rather than edit: the value of an ADR set is that it shows how thinking changed.
Filled example
Decision. The claims triage assistant will use the enterprise-hosted general model at a pinned version, grounded on the claims handling manual and the policy wording repository through retrieval, with no write access to the claims system of record. Rejected: fine-tuning on historical claims (training data reproduces past routing errors and cannot be corrected per-case); vendor-hosted service (claims narrative is restricted personal data and the data-use terms permit retention). Failure behaviour: retrieval unavailable → no recommendation shown, adjuster works the unassisted path. Pattern: conformant with RP-04 grounded advisory.
Plain-text version to copy into your own tooling
ARCHITECTURE DECISION RECORD (AI-EXTENDED)
ADR reference: System: Architect: Date:
Decision (one sentence):
Context and constraints:
Options considered and why rejected:
Model / service, hosting, version identity:
Grounding sources, retrieval design, refresh, failure path:
System boundary (in scope / out of scope):
Autonomy and action surface:
Pattern conformance: [conformant / modified / novel] Detail:
Failure behaviour (unavailable, slow, wrong):
Vendor due diligence (provenance, change notice, data use, audit, exit):
Concentration note (T3+):
Cost envelope and review trigger (T3+):
Machine-readable boundary location (agentic):
Data Lineage and Sensitivity Record
- Purpose
- Where the data comes from, what it is, who owns it, and how stale it may become
- Owner
- Data Owner
- Created at
- S4; required for Gate G2
- Approval
- Gate G2
- Update
- On any source addition, schema change, classification change or cadence change
- Retention
- Life of system plus the longest applicable data retention obligation
- Related
- ADR, Risk Classification Record (D5), Control Matrix, Drift/Alert Record
| Field | Required at | What good looks like |
|---|---|---|
| Source name and system of record | All | Where it actually comes from, not the platform it arrives on. |
| Named data owner | All | A person. A source with no owner is a drift source nobody watches, and it will change. |
| Classification | All | The sensitivity class, and the class of the joined record where combination raises it. |
| Lawful or contractual basis for this use | T2+ | Purpose-specific. A basis for holding data is not a basis for this processing. |
| Refresh cadence | All | How often it updates, and by what mechanism. |
| Maximum staleness | All | How old this data may be before the output is untrustworthy, and what happens at that point. This field is the one most often left blank and most often needed. |
| Transformation and derivation | T2+ | What happens between source and use, including filtering. |
| Derived stores | T2+ | Indexes, embeddings, caches and evaluation sets built from this source — the places deletion has to reach. |
| Known quality issues | T2+ | Recorded rather than discovered later by a model. |
| Exclusions applied | T3+ | What is deliberately not in scope: restricted classes, populations, date ranges. |
| Onward flows | T3+ | Who consumes the output, and what that makes them responsible for. |
How to fill it. Build it source by source, and stop when a source has no owner — that is the finding, and it is more valuable than a completed form. The two fields that repay the effort are maximum staleness and derived stores: the first prevents confidently wrong output, the second is what makes deletion and retirement actually work.
Plain-text version to copy into your own tooling
DATA LINEAGE AND SENSITIVITY RECORD
System: Data owner: Date:
For each source:
Source name / system of record:
Owner (named person):
Classification (and joined-record class):
Basis for this use:
Refresh cadence:
Maximum staleness and action on breach:
Transformations applied:
Derived stores (index, embeddings, cache, eval sets):
Known quality issues:
Exclusions applied:
Onward flows:
Reference Pattern Library Entry
- Purpose
- A pre-approved architecture that lets conforming systems self-certify
- Owner
- Architect; ratified by the Architecture Review Board
- Created at
- On pattern proposal
- Approval
- Architecture Review Board
- Update
- Versioned; systems record which version they conformed to
- Retention
- Until retired, plus the life of the last system using it
- Related
- ADR, Control Matrix, Deployment Authorization Record
| Field | Required at | What good looks like |
|---|---|---|
| Pattern name and reference | All | Short enough to be cited in an ADR without looking it up. |
| Problem it solves | All | The recurring situation, in the words teams use to describe it. |
| Applicability and tier ceiling | All | The maximum tier at which conformance permits self-certification. Most patterns should stop at Tier 2. |
| Reference architecture | All | Components, data flow, and the enforced boundaries. |
| Mandatory controls | All | The controls a conforming system inherits — and must actually implement, not merely reference. |
| Conformance test | All | How a team demonstrates conformance without a review meeting. If this is vague, the pattern will not reduce load. |
| Known limitations | T2+ | Where the pattern does not fit, stated by the people who wrote it. |
| Coverage metric | T3+ | What proportion of new systems use this pattern — the best available proxy for whether the library is working. |
| Retirement trigger | T2+ | What would make this pattern wrong. |
How to fill it. Patterns are the main mechanism the framework offers for reducing governance load, and they only work if conformance is genuinely self-serviceable. Track coverage: a library nobody conforms to is a documentation set.
Plain-text version to copy into your own tooling
REFERENCE PATTERN LIBRARY ENTRY
Pattern reference / name / version:
Problem it solves:
Applicability and tier ceiling for self-certification:
Reference architecture (components, flows, boundaries):
Mandatory inherited controls:
Conformance test (self-service):
Known limitations:
Coverage metric:
Retirement trigger: