Part of the AI Security Architecture series, following Forensic Readiness for Agentic AI, The Agent Registry Problem, Output Assurance and AI Supply Chain Integrity

The Decision Gap in AI Architecture

Every AI system is the accumulation of its decisions. Not just the decisions the model makes at runtime, but the architectural decisions that shaped what the model can do, what data it can access, what actions it can take and what boundaries constrain its behaviour.

The problem is when organisations cannot tell you why those decisions were made.

• “Your architecture is the accumulation of its decisions so the ADR is effectively a record of how and why the system came to be its current shape.” Source: Microsoft Azure Well-Architected Framework

Traditional software architecture has solved this problem. Michael Nygard proposed Architecture Decision Records in 2011, short, dated documents that capture a single architecturally significant decision, including:

• Decision
• Context
• Options considered
• Choice made
• Consequences

They live alongside the code in version control, are lightweight, durable and searchable.

AI systems need them more urgently than anything we have built before. And yet, in most organisations deploying agentic AI, the decision trail is either absent, scattered across Slack threads and meeting notes, or locked in someone’s memory.

Why AI Systems Demand Structured Decision Records

Traditional ADRs capture decisions about database selection, API design, or deployment topology. AI systems introduce an entirely different category of architecturally significant decisions. Decisions that carry regulatory, ethical and safety implications that traditional software rarely encounters.

Consider what must be decided when deploying an agentic AI system:

• Authority boundaries:
  • What can this agent do autonomously?
  • What requires human approval?
  • At what threshold does escalation trigger?
• Data access scope:
  • Which data sources can the agent query?
  • What personally identifiable information can it process?#
  • Under what legal basis?
• Model selection rationale:
  • Why this model and not another?
  • What were the trade-offs between capability, cost, latency and explainability?
• Guardrail architecture:
  • What output filters are applied?
  • What content policies are enforced?
  • How were thresholds calibrated?
• Orchestration topology:
  • How do agents communicate?
  • What happens when an agent fails?
  • Who owns the fallback?
• Retention and deletion:
  • How long are interaction logs kept?
  • What triggers deletion?
  • How does this align with data protection obligations?

“A decision record is a written record of a meaningful decision, structured to answer four basic questions: what did we decide, why did we decide it, what alternatives did we consider, and what consequences did we accept?”, Source: Decision Records for AI-Driven Software Development, Rost Glukhov

Each of these decisions is architecturally significant and are difficult to reverse. Each has consequences that compound over time. Under the EU AI Act and similar regulatory frameworks, each of the decisions may need to be demonstrated to an auditor.

The Regulatory Imperative

The EU AI Act’s transparency obligations, which came into force on 2 August 2026, require providers of high risk AI systems to maintain technical documentation that demonstrates how and why the system was designed as it was. Article 11 mandates documentation that covers design specifications, development methodology and the decisions that shaped system behaviour.

This is not optional. Non-compliance carries fines of up to €15 million or 3% of global annual turnover.

“AI accountability in compliance means regulators can now require organisations to explain, justify, and evidence every AI-assisted decision that affects employees, third parties, or business outcomes.” Source: Compliance in 2026, EQS Group (2026)

The NIST AI Risk Management Framework reinforces this through its Govern function, requiring that risk management processes and their outcomes are “established through transparent policies, procedures and other controls based on organisational risk priorities.”

ISO/IEC 42001 adds a certifiable management system wrapper that expects documented evidence of AI governance decisions.

ADRs are not the only way to satisfy these requirements, however they are the most practical, lightweight and developer friendly mechanism available. An ADR can create the decision provenance that regulators expect without imposing the bureaucratic overhead that kills adoption.

The AI-ADR Template

The classic Nygard template (Title, Status, Context, Decision, Consequences) works for traditional software. AI systems need additional fields that capture:

• Unique characteristics of autonomous
• Datadependent
• Details of potentially harmful systems

Here is an example of the extended fields in a template for AI Architecture Decision Records:

AI-ADR-[NUMBER]: [Title]

• Date: [ISO 8601] 
• Status: [Proposed | Accepted | Deprecated | Superseded by AI-ADR-XXX] 
• Deciders: [Names and roles] 
• AI System: [System identifier from Agent Registry]

• Context:
  • What is the situation that requires a decision?
  • What constraints exist?
  • What regulatory requirements apply?
  • What is the risk profile of the system?

• Decision:
  • What is the architectural decision being made?
  • State it clearly and unambiguously.

• Alternatives Considered:
  • What other options were evaluated?
  • Why were they rejected?
  • What trade-offs did each present?

• Consequences: 
  • What are the positive and negative outcomes of this decision
  • What technical debt does it introduce?
  • What capabilities does it enable or constrain?

AI-Specific Fields:

Field	Description
Autonomy Impact	How does this decision affect the agent’s autonomous capabilities?
Data Sensitivity	What data classification levels are affected?
Regulatory Alignment	Which regulatory requirements does this decision address? (EU AI Act Article, NIST AI RMF subcategory, ISO 42001 control)
Reversibility	How difficult is this decision to reverse? What is the blast radius?
Human Oversight	What human-in-the-loop requirements does this decision create or modify?
Ethical Considerations	What fairness, bias, or harm implications were evaluated?
Expiry/Review Trigger	When must this decision be revisited? What conditions trigger review?

Decision Categories for AI Systems

Not all AI decisions carry equal weight. A useful taxonomy helps teams identify which decisions warrant formal ADRs and which can be captured through lighter mechanisms.

Tier 1: Foundational (Always document)

• Agent authority boundaries and escalation thresholds
• Model selection for production deployment
• Data access permissions and legal basis
• Human oversight architecture
• Safety and content filtering design

Tier 2: Structural (Document when non-obvious)

• Orchestration patterns between agents
• Prompt engineering strategies that affect behaviour
• Monitoring and observability architecture
• Retention and deletion policies
• Integration patterns with enterprise systems

Tier 3: Tactical (Document when contested or surprising)

• Specific threshold values for guardrails
• Caching and performance optimisation choices
• Testing strategy and coverage decisions
• Deployment topology and scaling approach

“Decision provenance is a semantically rich record of why, not just what. When a multi-agent pipeline hallucinates and cascades that error through three downstream agents before someone notices, your span traces will show you every service call in perfect order.”, Source: Decision Provenance in Agentic Systems, Tian Pan

The distinction matters. Tier 1 decisions are the ones that regulators will ask about. They are the ones that forensic investigators will need when something goes wrong. They are the ones that new team members will search for when they inherit a system and need to understand why it behaves as it does.

ADRs as Governance Infrastructure

Architecture Decision Records are not documentation for documentation’s sake. When implemented correctly, they become active governance infrastructure. ADRs provide the connective tissue between policy intent and technical reality.

Consider how ADRs connect to the other elements in this series:

• Agent Registry: Each registered agent should reference the ADRs that define its authority boundaries, data access and operational constraints. The registry becomes navigable through its decision history.
• Output Assurance:The decision to implement specific output filters, the thresholds chosen and the rationale for those thresholds should all be captured in ADRs. When an output assurance control is questioned, the ADR provides the justification.
• Forensic Readiness: ADRs create the “design intent” baseline against which forensic investigators can assess whether a system operated within its intended parameters. Without them, investigators cannot distinguish between a system malfunction and a system operating exactly as designed.
• Supply Chain Integrity:Decisions about which third-party models, libraries and services to incorporate (and the due diligence performed) should be captured as ADRs with explicit supply chain risk assessments.

“If your documentation cannot answer those questions with verifiable evidence, you do not have an accountable AI system. You have a system that is well documented. That is not the same thing.” Source: Architecture and Governance Magazine

An ADR provides the critial insight and transform documentation from a compliance artefact into an operational tool. They answer the question that every regulator, auditor and incident responder will eventually ask, why does this system work this way?

Implementation Patterns

Pattern 1: Decision-as-Code

Store ADRs in the same repository as the AI system code. Use a consistent directory structure:

• /docs/decisions/
• AI-ADR-001-agent-authority-boundaries.md
• AI-ADR-002-model-selection-customer-service.md
• AI-ADR-003-pii-handling-approach.md
• AI-ADR-004-escalation-threshold-calibration.md

This ensures decisions are versioned alongside the code they govern. Pull requests that change system behaviour should reference or create ADRs. Code review becomes decision review.

Pattern 2: Decision Lifecycle Management

ADRs are not write once documents and must be checked and amended appropriately with each change as AI systems can evolve rapidly.

Decisions that were appropriate six months ago may be inappropriate today because the model improved, the regulatory landscape shifted or the risk profile changed.

Implement review triggers:

• Time-based: All Tier 1 ADRs reviewed quarterly
• Event based: Model upgrade triggers review of all ADRs referencing that model
• Threshold based: Monitoring alerts that indicate boundary conditions trigger ADR review
• Regulatory based: New regulatory guidance triggers review of affected ADRs

Pattern 3: Decision Provenance Chain

For multi-agent systems the decisions cascade. An ADR about orchestration topology affects every agent in the pipeline.

A decision about data access in one agent constrains what downstream agents can process.

Implement explicit cross-references:

• Supersedes: AI-ADR-XXX
• Depends on: AI-ADR-YYY
• Constrains: AI-ADR-ZZZ
• Informed by: [Incident report, audit finding, regulatory update]

This creates a navigable decision path. Essential for understanding how a complex multi-agent system arrived at its current architecture.

Pattern 4: Automated Decision Validation

“Event Modelling, OpenAPI, Architectural Decision Records, and Spec Driven Development all produce content that can be enforced through automated or agentic means.”, Source: Architectural Governance at AI Speed, InfoQ

ADRs that specify quantitative constraints (thresholds, permissions, retention periods) can be validated automatically.

Build CI/CD checks that verify the deployed system configuration matches the decisions recorded in ADRs. When drift occurs, flag it.

This transforms ADRs from passive documentation into active governance controls.

The Organisational Challenge

The technical implementation of ADRs is straightforward. The organisational challenge is harder.

AI systems are built by cross-functional teams, data scientists, ML engineers, platform engineers, product managers, legal counsel and ethics reviewers. Decisions are made in different forums, at different times by different people. The architect’s job is to ensure that architecturally significant decisions are captured regardless of where they originate.

Three practices help:

• 1. Decision identification discipline: Train teams to recognise architecturally significant decisions as they happen. Not every choice is an ADR. But every choice that affects authority, data access, safety or regulatory compliance is.
• 2. Lightweight capture, rich context: The ADR should take less than 30 minutes to write. If it takes longer, the scope is too broad, split it. The goal is a decision record that a new team member can read in five minutes and understand why the system works as it does.

3. Decision authority clarity: Who can make which decisions? A junior engineer should not be making Tier 1 decisions about agent authority boundaries without appropriate review. Define decision authority alongside the ADR process.

What Good Looks Like

An organisation with mature AI-ADR practices can:

• Answer the regulator: When asked “why does your AI system handle personal data this way?”, point to a specific, dated, signed ADR that explains the context, alternatives considered and rationale
• Onboard new engineers: A new team member reads the decision log and understands not just what the system does, but why it was built that way
• Investigate incidents: When an agent behaves unexpectedly, compare its behaviour against the design intent captured in ADRs to determine whether the issue is a bug, a drift or a design flaw
• Evolve safely: When changing the system, understand which prior decisions are affected and what constraints must be preserved
• Demonstrate governance: Show auditors a complete, versioned, cross-referenced decision trail that connects policy to implementation

Conclusion

Architecture Decision Records are not new. They have been a proven practice in software engineering for fifteen years. What is new is the urgency with which AI systems demand them.

When an AI agent makes a decision that affects a person’s employment, credit, healthcare or legal standing, someone will ask why the system was designed to make that decision.

When a multi-agent pipeline produces an unexpected outcome, someone will need to trace the chain of architectural choices that enabled it. When a regulator asks for evidence of governance, someone will need to produce more than a policy document. They will need to show the decisions that translated policy into technical reality.

ADRs are the bridge between intent and implementation. They are lightweight enough to actually get written, structured enough to be useful under pressure and durable enough to survive the team turnover that every enterprise experiences.

The question is not whether your AI systems need decision records. The question is whether you will create them deliberately now, or reconstruct them painfully later under regulatory scrutiny, during an incident investigation or in response to a legal discovery request.

Start writing them today.

References

• “Documenting Architecture Decisions.”, Nygard, M. (2011)
• “Maintain an Architecture Decision Record (ADR).”, Microsoft Azure Well-Architected Framework
• “Architecture Decision Record.”, Fowler, M. (2026)
• “Decision Records for AI-Driven Software Development.”, Glukhov, R. (2026)
• “Decision Provenance in Agentic Systems.”, Pan, T. (2026)
• “Architectural Governance at AI Speed.”, InfoQ. (2026)
• “Architectural Accountability for AI: What Documentation Alone Cannot Fix.”, Architecture and Governance Magazine. (2026)
• “Build Foundational Enterprise AI Using Spec-Driven Development and Architecture Decision Records.”, WeBuild-AI. (2026)
• “AI Risk Management Framework.”, NIST. (2026)
• NIST AI RMF to ISO/IEC 42001 Crosswalk.
• “Compliance in 2026: AI Governance, Risk & Compliance Trends.”, EQS Group. (2026)
• “Agentic AI Governance Playbook.”, IBM. (2026)
• “AI Governance Framework, Agent Decision Audit and Explainability.”, FINOS
• “Architecture Decision Records (ADRs): The 2026 Guide.”, Catio.tech. (2026)
• “Architecture Decision Record (GitHub Repository).”, Joel Parker Henderson
• EU AI Act – Article 11: Technical Documentation
• “A Transparency Framework for Agentic AI.”, OneReach.ai. (2026)
• “AI Governance Framework for Production Agents.”, Galileo.ai. (2026)
• “Architecture Decision Records: Templates and Operational Patterns.”, Konishi, H. (2026)

AI Supply Chain Integrity

Output Assurance

AI Forensic Readiness: Evidence Architecture for the Agentic Enterprise

The Agent Registry Problem: Why You Cannot Govern What You Cannot See

You’re Right: A Registry Isn’t Enough