Decision Record — Template¶
Purpose: make the leadership decisions that come out of a workshop durable and reusable. A Decision Record (DR) is a 1–2 page artifact that survives the person who signed it, the tool that prompted it, and the quarter in which it was made.
Every worksheet in this section produces at least one Decision Record.
Why Decision Records¶
AI-assisted development moves fast. Tools are renamed, vendors merge, regulations change, and the people who made the call move on. Without a DR, every six months you have the same meeting again because no one can find the answer to "why did we decide X?"
The format below is a deliberately minimal adaptation of the ADR (Architecture Decision Record) pattern1, used by software teams for over a decade, applied to governance and adoption decisions instead of architecture.
The template¶
Copy the block below into a new file (recommended location:
decisions/NNNN-short-title.md in a durable, version-controlled
repository, the same place your AUP lives). Fill it in during or
immediately after the meeting.
Decision Record template
id: DR-0001 title: short imperative title — e.g., "Approve GitHub Copilot as primary assistant for pilot" status: proposed | accepted | superseded | deprecated date: 2026-04-24 owner: role, not person — e.g., "CoE Lead"; the role persists, people change sponsor: role — exec sponsor accountable for the outcome supersedes: DR-ID or "none" superseded_by: DR-ID or "none" tags: [phase-0 | phase-1 | phase-2 | phase-3 | phase-4, governance | tooling | security | training]
Context. 3–8 sentences. What was the situation that forced a decision? What facts, incidents, metrics, or regulations made it urgent? Include links to supporting evidence.
Options considered.
| Option | Summary | Pros | Cons |
|---|---|---|---|
| A | chosen option | ||
| B | alternative | ||
| C | do nothing |
Every DR must list at least one alternative and the "do nothing" option. Decisions that present only one choice are not decisions.
Decision. One paragraph. What was chosen, and by whom. Use active voice. "The Center of Excellence, sponsored by the CTO, approves Option A: adopt GitHub Copilot Enterprise as the primary AI assistant for the pilot team, contingent on Legal review of the 2026 MSA revision."
If sign-off requires multiple parties, list them: Security, Legal, Privacy, Procurement, Exec Sponsor.
Consequences. What becomes true now that this decision is made? Both the good and the bad — including what this decision forecloses.
- Positive: ...
- Negative / costs: ...
- Risks accepted: ...
- Things we will no longer do: ...
Review triggers. Conditions that would cause us to revisit this decision. Not a date alone — a date plus specific events. Examples:
- 2026-10-24 (6-month review) OR
- A production incident attributable to the tool OR
- A vendor contract change OR
- A significant regulatory update (EU AI Act staging, new sector rule)
Evidence referenced. Bullet list of links: incident logs, metrics snapshots, vendor scorecards, prior DRs, regulatory texts. If the evidence was a conversation, note who and when.
Sign-off.
| Role | Name (optional for internal; omit for public) | Date |
|---|---|---|
| Exec sponsor | ||
| CISO or delegate | ||
| Legal or delegate | ||
| Privacy or delegate | ||
| CoE Lead |
---
id: DR-0001
title: <short imperative title — e.g., "Approve GitHub Copilot as primary assistant for pilot">
status: proposed | accepted | superseded | deprecated
date: 2026-04-24
owner: <role, not person — e.g., "CoE Lead"; the role persists, people change>
sponsor: <role — exec sponsor accountable for the outcome>
supersedes: <DR-ID or "none">
superseded_by: <DR-ID or "none">
tags: [phase-0 | phase-1 | phase-2 | phase-3 | phase-4, governance | tooling | security | training]
---
## Context
<3–8 sentences. What was the situation that forced a decision? What
facts, incidents, metrics, or regulations made it urgent? Include links
to supporting evidence.>
## Options considered
| Option | Summary | Pros | Cons |
|---|---|---|---|
| A | <chosen option> | | |
| B | <alternative> | | |
| C | <do nothing> | | |
Every DR must list at least one alternative and the "do nothing" option.
Decisions that present only one choice are not decisions.
## Decision
<One paragraph. What was chosen, and by whom. Use active voice.
"The Center of Excellence, sponsored by the CTO, approves Option A:
adopt GitHub Copilot Enterprise as the primary AI assistant for the
pilot team, contingent on Legal review of the 2026 MSA revision."
If sign-off requires multiple parties, list them: Security, Legal,
Privacy, Procurement, Exec Sponsor.>
## Consequences
<What becomes true now that this decision is made? Both the good and
the bad — including what this decision *forecloses*.
- Positive: <...>
- Negative / costs: <...>
- Risks accepted: <...>
- Things we will no longer do: <...>>
## Review triggers
<Conditions that would cause us to revisit this decision. Not a date
alone — a date *plus* specific events. Examples:
- 2026-10-24 (6-month review) OR
- A production incident attributable to the tool OR
- A vendor contract change OR
- A significant regulatory update (EU AI Act staging, new sector rule)>
## Evidence referenced
<Bullet list of links: incident logs, metrics snapshots, vendor
scorecards, prior DRs, regulatory texts. If the evidence was a
conversation, note who and when.>
## Sign-off
| Role | Name (optional for internal; omit for public) | Date |
|---|---|---|
| Exec sponsor | | |
| CISO or delegate | | |
| Legal or delegate | | |
| Privacy or delegate | | |
| CoE Lead | | |
How to use it¶
In a workshop¶
- Appoint a scribe, not the chair. The scribe drafts the DR live on a shared screen during the meeting.
- At the end of the meeting, the DR is at ~80%. Do not leave the room without at least the Context, Options, and Decision filled in.
- The scribe completes Consequences, Review triggers, and Evidence within 48 hours.
- The DR goes to sign-off parties for async approval, typically 3–5 business days.
- Once signed, the DR status moves from
proposedtoacceptedand it is merged into the decisions repository.
Between workshops¶
- Reference DRs by ID in AUPs, training materials, and runbooks. For example: "per DR-0007, agents do not have production write access."
- When a DR is superseded, do not delete it. Set its status to
superseded, add thesuperseded_byID, and leave it in the repository. The historical decision is part of the audit trail.
In an audit¶
A DR is the answer to "why did you do X?" Auditors, regulators, and new joiners will all ask that question. The DR answers it with the exact context, alternatives, and sign-offs as they stood at the time of the decision.
Anti-patterns¶
Don't
- Don't use DRs as meeting minutes. A DR is a decision, not a transcript. If nothing was decided, no DR is created.
- Don't write DRs retroactively to rationalise a choice already made. The "Options considered" section becomes theatrical. If a decision was made informally, the DR should say so under Context.
- Don't make DRs so long they go unread. Two pages maximum. Supporting evidence lives in the linked documents.
- Don't sign a DR you don't understand. The DR is asking you to accept Consequences. If those are unclear, send it back.
- Don't let DRs live only in a wiki page that can be edited without trace. Keep them in version control so history is preserved.
Worked example — what a filled-in DR looks like¶
Worked example — DR-0003
id: DR-0003 title: Approve GitHub Copilot Enterprise as primary assistant for Phase 1 pilot status: accepted date: 2026-05-02 owner: CoE Lead sponsor: CTO supersedes: none superseded_by: none tags: [phase-1, tooling]
Context. Phase 0 completed 2026-04-30; charter signed; interim AUP published. Engineering survey (N=142) indicates 68% of engineers are already using some form of AI coding assistant, with 41% using tools outside the interim approved list. We need a primary tool for the Phase 1 pilot to concentrate signal and finish Legal + Security review before usage grows further.
Options considered.
| Option | Summary | Pros | Cons |
|---|---|---|---|
| A (chosen) | GitHub Copilot Enterprise, SSO + audit logs | Existing GH enterprise agreement; IP indemnification; known integration | Per-seat cost; vendor consolidation risk |
| B | Cursor for all pilot participants | Developer preference in 2025 benchmarks; competitive edit experience | Newer enterprise controls; separate contract |
| C | Two-tool bake-off (A + B, split 50/50) | Comparative data | Doubles training, halves signal per tool; extends Phase 1 by ~4 weeks |
| D | Do nothing — continue shadow-IT use | Zero procurement cost | Continued policy breach; no audit trail; IP risk |
Decision. The CoE, sponsored by the CTO and with sign-off from CISO, Legal, and Privacy, approves Option A for the 90-day Phase 1 pilot. The decision is contingent on executing the 2026 MSA revision (Legal to confirm by 2026-05-09). Option B (Cursor) is held for a parallel evaluation in Phase 2.
Consequences.
- Positive: single tool for pilot concentrates metrics and training; IP indemnification resolved; audit logging is native.
- Negative: ~$X per seat per month; single-vendor exposure.
- Risks accepted: vendor pricing changes mid-pilot; we will not switch mid-pilot unless Option D conditions are met.
- Forecloses: individual tool choice during pilot (shadow use is now a policy violation, tracked under AUP §4).
Review triggers.
- 2026-07-31 — mid-pilot checkpoint.
- 2026-08-15 — Phase 1 retrospective.
- Any security incident Category 2+ attributable to Copilot.
- Any material vendor contract change.
Evidence referenced.
- Engineering survey 2026-04-22 (link).
- Incident log Q1 2026 (link).
- Phase 0 Risk Classification workshop output 2026-04-18 (link).
- GitHub Copilot Enterprise contract v2026-03 (Legal repo, link).
Sign-off.
| Role | Name | Date |
|---|---|---|
| Exec sponsor | CTO | 2026-05-02 |
| CISO | name | 2026-05-02 |
| Legal | name | 2026-05-02 |
| Privacy | name | 2026-05-02 |
| CoE Lead | name | 2026-05-02 |
---
id: DR-0003
title: Approve GitHub Copilot Enterprise as primary assistant for Phase 1 pilot
status: accepted
date: 2026-05-02
owner: CoE Lead
sponsor: CTO
supersedes: none
superseded_by: none
tags: [phase-1, tooling]
---
## Context
Phase 0 completed 2026-04-30; charter signed; interim AUP published.
Engineering survey (N=142) indicates 68% of engineers are already using
some form of AI coding assistant, with 41% using tools outside the
interim approved list. We need a primary tool for the Phase 1 pilot to
concentrate signal and finish Legal + Security review before usage
grows further.
## Options considered
| Option | Summary | Pros | Cons |
|---|---|---|---|
| A (chosen) | GitHub Copilot Enterprise, SSO + audit logs | Existing GH enterprise agreement; IP indemnification; known integration | Per-seat cost; vendor consolidation risk |
| B | Cursor for all pilot participants | Developer preference in 2025 benchmarks; competitive edit experience | Newer enterprise controls; separate contract |
| C | Two-tool bake-off (A + B, split 50/50) | Comparative data | Doubles training, halves signal per tool; extends Phase 1 by ~4 weeks |
| D | Do nothing — continue shadow-IT use | Zero procurement cost | Continued policy breach; no audit trail; IP risk |
## Decision
The CoE, sponsored by the CTO and with sign-off from CISO, Legal, and
Privacy, approves Option A for the 90-day Phase 1 pilot. The
decision is contingent on executing the 2026 MSA revision (Legal to
confirm by 2026-05-09). Option B (Cursor) is held for a parallel
evaluation in Phase 2.
## Consequences
- Positive: single tool for pilot concentrates metrics and training; IP
indemnification resolved; audit logging is native.
- Negative: ~$X per seat per month; single-vendor exposure.
- Risks accepted: vendor pricing changes mid-pilot; we will not switch
mid-pilot unless Option D conditions are met.
- Forecloses: individual tool choice during pilot (shadow use is now a
policy violation, tracked under AUP §4).
## Review triggers
- 2026-07-31 — mid-pilot checkpoint.
- 2026-08-15 — Phase 1 retrospective.
- Any security incident Category 2+ attributable to Copilot.
- Any material vendor contract change.
## Evidence referenced
- Engineering survey 2026-04-22 (link).
- Incident log Q1 2026 (link).
- Phase 0 Risk Classification workshop output 2026-04-18 (link).
- GitHub Copilot Enterprise contract v2026-03 (Legal repo, link).
## Sign-off
| Role | Name | Date |
|---|---|---|
| Exec sponsor | CTO | 2026-05-02 |
| CISO | <name> | 2026-05-02 |
| Legal | <name> | 2026-05-02 |
| Privacy | <name> | 2026-05-02 |
| CoE Lead | <name> | 2026-05-02 |
Next¶
- Back to Worksheets index.
- See this template referenced in every worksheet under the "Decision Record" section.
-
Michael Nygard's original 2011 post, "Documenting Architecture Decisions", still holds up as a reference. ↩