Record the decision, not just the AI conversation

A transcript explains a conversation; a record governs a decision

Teams already have more AI history than they can use: chats, prompts, tool logs, meeting notes, generated reports, tickets, and dashboards. The missing artifact is smaller and more demanding. It must show what decision was open, which evidence mattered, which options were considered, who had authority, what was decided, what happened, and which later record replaced it.

The distinction became unusually visible in late October 2026. ADRs4AI published a Git-versioned method for preserving human-AI deliberation, supported by an Apache-2.0 template, a VS Code extension, and MCP/CLI tools. Its Show HN discussion reached 66 points and 59 comments. Supporters valued continuity across sessions and explicit rationale. Critics described the familiar failure of architecture records: stale and conflicting constraints can confuse models faster than they confuse people, because an agent may obey old text as if it were current policy.

That debate is useful outside software engineering. Operations teams make consequential decisions about vendors, process changes, exceptions, staffing models, controls, incidents, service recovery, procurement, and AI deployment. They often ask AI to summarize evidence or compare options, but the resulting chat is not a stable governance object. It lacks an accountable owner, authority source, status, effective period, action receipt, outcome review, and supersession chain.

NIST's AI Risk Management Framework makes the operational need clear. It calls for documented roles, impacts, human oversight, limits, risk treatment, monitoring, incident response, and mechanisms to supersede or deactivate systems that no longer fit their intended use. The framework does not prescribe this page's template. It establishes why a reconstructable decision process matters.

This guide adapts the record idea into a cross-functional Operations control. It does not copy the ADRs4AI template. The open project is a source and implementation reference under Apache 2.0. The workflow below adds operational authority, evidence classification, action receipts, specialist gates, outcome review, and lifecycle controls for teams whose decisions extend beyond code.

Do not record everything

A decision-record program fails when every AI interaction becomes paperwork. Use a full record when the decision is consequential, contested, cross-functional, reusable, exception-based, policy-setting, hard to reverse, or likely to be questioned later. Use a lightweight execution log for routine work that is pre-authorized, objectively checked, reversible, and governed by an existing current record.

Write the trigger in business language. “AI recommended a change” is not enough. A useful trigger says, “The supplier onboarding backlog exceeded the service threshold for three weeks, and Operations must decide whether to allow an AI agent to draft risk classifications from approved documents.” This identifies the process, problem, proposed authority, and decision boundary.

Record the no-action option. Teams often compare two vendor or automation proposals while silently assuming that automation must proceed. NIST's Generative AI Profile and the broader AI RMF encourage examination of alternatives, costs, benefits, limitations, and human-AI configurations. A record that cannot represent “continue the manual process while we collect evidence” is advocacy, not deliberation.

Bind nine things into one reviewable object

1. Question and trigger: one decision, one stable ID, one business reason, one deadline.
2. Scope and consequence: processes, systems, data, populations, jurisdictions, exclusions, and failure severity.
3. Evidence manifest: source identifier, version, owner, date, hash or stable link, relevance, limitation, and confidentiality class.
4. Options: benefits, costs, risks, reversibility, dependencies, affected stakeholders, and evidence strength for each viable path.
5. AI contribution: model/product, version, prompt or workflow version, tools, retrieved sources, output, and known limitations.
6. Human authority: accountable owner, specialist reviewers, conflict checks, decisions, dissent, conditions, and explicit non-authorizations.
7. Action receipt: what was actually executed, by whom or what service, under which permission, with which checks and rollback.
8. Outcome review: measures, incidents, stakeholder feedback, corrections, and whether assumptions held.
9. Lifecycle: status, effective date, review date, expiry, related records, supersedes, and superseded-by links.

The evidence manifest is load-bearing. A link alone does not prove what the decision maker saw. Record a version, access date, and content hash when practical. For mutable operational data, preserve an approved snapshot or query receipt. For sensitive evidence, store a stable identifier and access-controlled location rather than copying the contents into the record.

record_id: OPS-AI-2026-014
status: PROPOSED
question: "May the onboarding agent draft supplier risk tiers?"
owner: "Director, Procurement Operations"
authority_source: "PROC-POL-07 section 4"
scope:
  allowed: [draft_tier, cite_source_fields]
  prohibited: [approve_supplier, change_bank_data, send_external_message]
evidence:
  - id: vendor-validation-v3
    version: "2026-10-18"
    class: FIRST_PARTY_CLAIM
    hash: "sha256:..."
    limitation: "No evaluation on our supplier mix"
decision:
  state: PENDING_HUMAN_GATE
  recommendation: "Shadow mode for 200 completed cases"
  falsifier: "Critical-field miss rate exceeds 1%"
lifecycle:
  review_on: "2026-12-15"
  supersedes: null

Keep the stated rationale concise. Governance does not require hidden chain-of-thought, and an AI tool should not be asked to reveal it. Record the evidence, assumptions, uncertainty, alternatives, and human reasons that are appropriate for review. This is more useful and safer than storing an opaque narrative of internal model reasoning.

Separate recommendation, approval, execution, and verification

An AI-generated recommendation has no organizational authority by itself. The decision record should name four roles even when one person fills more than one: the drafter assembles the packet, the accountable owner decides, the executor acts within permission, and the verifier checks the result. High-consequence decisions also need independent specialist review.

NIST's current agent identity design tenets reinforce this separation. They recommend identities and credential lifecycles distinct from human principals, runtime verification of actions, signed mandates, risk thresholds that trigger human review, and auditability. A decision record can describe the mandate, but the runtime must still enforce it. Markdown is not an authorization system.

Record dissent without forcing consensus. A privacy reviewer can approve the data minimization plan while a security reviewer rejects the external integration. The owner cannot average those outcomes into approval. The record should show which domain is blocked, who can resolve it, and which condition would reopen review.

Supersession is the control that keeps records from becoming poison

The strongest objection in the Show HN discussion was not that records are useless. It was that old constraints accumulate, conflict, and become blindly obeyed. One commenter compared an incoherent ADR set to a bank account filled with monopoly money. Another described models citing flawed or outdated assumptions. The remedy is lifecycle discipline, not a larger context window.

Never silently rewrite an effective record when the decision changes. Create a new record, state why, and link both directions. The old record remains useful history but loses current authority. Every active record needs an owner, review date, expiry or event trigger, and scope. Agents should retrieve only current records whose scope matches the task.

Measure maintenance debt. Track overdue reviews, current records without owners, broken evidence references, unresolved contradictions, records with no outcome review, and agent runs that loaded a superseded record. A repository can be perfectly versioned and still be operationally untrustworthy.

Worked example: supplier-risk drafting agent

Assume Procurement Operations wants an agent to draft supplier risk tiers from questionnaires, security reports, and approved company data. The vendor demo is strong, but the tool could influence onboarding speed, due diligence, and commercial relationships.

The decision question is not “Should we buy the AI?” It is “May version X draft a risk tier and cited reasons for these supplier categories, using these fields, while a named reviewer retains approval?” That phrasing turns a product choice into a bounded operating decision.

The record might approve shadow mode for 200 completed cases. It would preserve the input snapshot, model and workflow version, cited source fields, human baseline, disagreement, critical-field misses, unsupported claims, subgroup of supplier types, and reviewer time. A one percent critical-field miss, any unsupported sanctions or ownership claim, data leaving the approved region, or a missing citation would stop the run.

The action receipt would prove that shadow mode remained shadow mode. It would record that outputs were withheld from live supplier decisions, which cases were evaluated, which reviewer checked them, and whether deletion and access controls worked. At the review date, the owner could reject, extend, narrow, or supersede the record. “Pilot completed” would not be enough.

Failure modes that a polished record can hide

Project-management practitioners provide a useful warning. In a 111-point r/projectmanagement discussion, one commenter described a repository of project-specific Claude plugins and context skills; another said AI-generated notes were “heaping hot garbage” for the people doing the work. Neither comment represents all PMs. The disagreement shows why record quality cannot be inferred from adoption. Check whether the artifact preserves the decision, stakeholder meaning, evidence, and responsibility rather than merely producing more text.

A four-week rollout for one decision class

1. Week 1: choose one recurring consequential decision; inventory current evidence, authority, approvals, logs, incidents, and review gaps.
2. Week 1: define materiality triggers, statuses, IDs, owners, specialist gates, sensitive-data rules, and repository permissions.
3. Week 2: create five records from historical decisions; test whether an independent reviewer can reconstruct what happened without the original meeting.
4. Week 2: test contradiction, expiry, broken-link, duplicate-ID, supersession, and unauthorized-edit checks.
5. Week 3: use the workflow prospectively in shadow mode; do not make the record the live authorization source yet.
6. Week 3: compare completion time, missing evidence, reviewer disagreement, correction, outcome linkage, and maintenance cost.
7. Week 4: integrate the approved record with ticketing, policy, or execution systems through stable IDs and signed or permissioned actions.
8. Week 4: approve only the exact decision class, owner group, repository, data boundary, and maintenance cadence that were tested.

Success is not the number of records created. It is faster reconstruction, fewer repeated debates, clearer authority, earlier detection of missing evidence, traceable dissent, safer execution, and fewer agents acting on stale decisions. If maintenance cost grows faster than retrieval value, narrow the trigger.

FAQ

Is an AI chat transcript a decision record?

No. It can be supporting evidence. A decision record identifies the question, evidence snapshot, options, accountable human, decision, rationale, action, outcome, status, and lifecycle.

Should we store the model's chain-of-thought?

No. Record concise reasons, evidence, assumptions, uncertainty, options, and human judgment. Hidden model reasoning is neither required nor an appropriate governance artifact.

Can the record authorize an agent action?

The record can describe the approved mandate and link to it. The execution system must enforce identity, permissions, current policy, risk thresholds, and human gates independently.

How do we keep records from confusing agents?

Use explicit status, scope, effective dates, supersession links, contradiction checks, review triggers, and retrieval filters. Do not load every historical record into every task.

Does using this workflow make us compliant with NIST or ISO standards?

No. The cited frameworks inform the control design. Conformance or certification requires a broader management system, evidence, competent review, and the applicable formal requirements.