The Decision Register Methodology

AI-assisted projects accumulate decisions faster than memory can retain them. By session 5, the project has made 30 decisions about architecture, naming, scope, and behavior. By session 20, it has made 100+. By session 47, the operator cannot remember which decisions are locked, which are open, and which were silently reversed when the model "helped" with something adjacent.

The result is drift. A decision made in session 3 gets quietly undone in session 18 because the model didn't know it was locked, and the operator didn't catch the regression until session 25 when downstream behavior broke.

The decision register prevents drift not by relying on memory, but by making every locked decision a queryable artifact that the model can reference at the start of every session.

## Decision Register

| # | Decision | Rationale | Session Locked |
|---|----------|-----------|----------------|
| D01-01 | [What is locked] | [Why this, not alternatives] | 01 |
| D02-01 | [What is locked] | [Why this, not alternatives] | 02 |
| D02-02 | [What is locked] | [Why this, not alternatives] | 02 |
| D03-01 | [Supersedes D01-01] [What is now locked] | [Why the supersession] | 03 |

At session close, the operator produces a deep-context document that captures: what was done, what was decided, what was deferred, and what the next session should resume from. This document is loaded at the start of the next session and the operator confirms it represents the current state.

The deep-context document is structured:

1. Identity — date, session number, prior session reference, theme
2. What happened this session — narrative by phase, not transcript
3. Decisions made this session — new entries to append to the decision register
4. Infrastructure state — snapshot of live services touched
5. Issues — resolved, new, carry-forward
6. Patterns learned — observations about approach worth keeping
7. Pending actions — tiered by priority for next session

The next session reads only the most recent deep-context document plus the CLAUDE.md. It does not need to re-read the entire conversation history.

Some decisions are project-specific. Others transcend the project — they are operator-wide principles that should apply across every project the operator runs. Those decisions are canon.

Canon elevation criteria:

• The principle was articulated in the context of one project, but the operator recognized it as transcending that context.
• The operator explicitly stated the elevation ("this should be canon," "cross-project," "for everything").
• The principle becomes a constraint in a master CLAUDE.md file that all projects inherit.
• Project-level decisions may extend canon (narrower scope, stricter constraint), but may not weaken or override it.

• Decisions without rationale. "We use X" without "because Y" produces a register that can't be revisited. Reverse-engineering rationale months later doesn't work.
• Silent reversal. A decision is reversed by a new decision with explicit supersession, not by quietly doing something different.
• Trying to remember instead of querying. The decision register is the memory. Operating from memory while the register exists wastes the register.
• Decision IDs without session anchors. "D17" without session context becomes meaningless when there are 200 decisions.

## Decision Register

| # | Decision | Rationale | Session Locked |
|---|----------|-----------|----------------|
| D01-01 | | | 01 |

## Canon Register

| ID | Principle | One-line | Session Locked |
|----|-----------|----------|----------------|
| — | (No canon established yet) | — | — |

## Issue Register

| ID | Summary | Severity | Status |
|----|---------|---------|--------|
| — | (No issues logged yet) | — | — |

Drop into your CLAUDE.md. Lock the first decision at session 01.