Decision Record with Residue¶

Decision record — instantiates Incompatible Requirement Set Resolution

Captures the chosen resolution as a durable record that also ledgers what survived and what was given up — the guarantees that still hold, the losses accepted, and everything the decision now touches downstream.

When an incompatible requirement set is resolved, something was relaxed — and the great failure of these decisions is that the relaxation is forgotten while the original all-at-once promise lives on in everyone's memory. Decision Record with Residue exists to prevent that. It is the durable artifact that captures the resolution — what was decided, which commitment yielded, and on what grounds — but its defining feature is the residue ledger bolted alongside: an explicit accounting of the guarantees that still hold after the relaxation and, just as important, the ones that no longer do. A plain decision record says "we chose X"; this one says "we chose X, here is exactly what X still promises, here is what it stopped promising, and here is everything downstream that now depends on that." It turns a quiet compromise into a stated, inheritable fact.

Example¶

A municipal water utility is caught between three commitments its council made in public: replace all lead service lines by a fixed deadline, hold the household water rate below a promised cap, and stay within the covenants on its outstanding bonds. Analysis shows the three cannot jointly hold — the replacement pace the deadline demands cannot be financed under both the rate cap and the covenants. The council resolves it: extend the lead-line deadline by an estimated eighteen months for the lowest-risk service areas, hold the rate cap, and protect the bond covenants.

The Decision Record with Residue writes this down so it cannot quietly revert. It records the decision and the reasoning it rests on. Then the residue ledger does the load-bearing work: it states the guarantees that still hold — every high-risk school and daycare line is still replaced on the original schedule, and the rate cap is intact — and the guarantee that was lost — the blanket "all lines by the deadline" promise is now "all high-risk lines by the deadline, the remainder by the deadline plus ~18 months." Finally it traces the impact: which public commitments, contracts, and compliance filings must be updated to match. A year later, when a council member asks why a low-risk street is still on old pipe, the answer is not a scramble — it is a line in the ledger.

How it works¶

The record is built to outlive the meeting that produced it:

State the decision and its grounds. What was chosen, which commitment yielded, under whose authority, and the rationale — captured once, in durable form, not scattered across threads.
Ledger the residue. List the guarantees that survive the relaxation and the guarantees lost or weakened, each stated precisely enough that a reader years later can tell what is still promised and what is not.
Trace the impact. Enumerate the downstream commitments, contracts, documents, and systems that must change to stay consistent with the new promise — so the relaxation propagates instead of leaving stale claims behind.
Make it findable and inheritable. Keep it where the people who inherit the system will look, so the residue is discovered by reading, not by re-deriving the conflict.

Tuning parameters¶

Residue granularity — how finely surviving and lost guarantees are itemized. Fine granularity leaves no ambiguity about what was given up but takes real effort to write and maintain; coarse ledgers are quick and slippery.
Impact-trace depth — how far downstream the consequences are chased — direct dependents only, or the full transitive closure of affected commitments. Deeper traces catch stale promises but cost more to compile.
Formality and durability — a lightweight note versus a controlled, versioned record. Heavier process resists erosion and revision-by-forgetting but slows the cadence of decisions.
Audience framing — written for the deciding team, or for the outside parties who hold the weakened guarantee. The second demands plainer language about what they lost.
Supersession policy — whether records are immutable (new decisions add new records that reference the old) or edited in place; immutability preserves the history of what was promised when.

When it helps, and when it misleads¶

Its strength is memory: it stops the relaxation from being silently forgotten while the original promise lingers, and it gives everyone downstream a single honest statement of what the system now guarantees. The residue ledger in particular converts an accepted loss from tacit knowledge — which evaporates with staff turnover — into an inherited fact, and the impact trace keeps the rest of the requirement set from continuing to assert promises the decision already retired. It extends the familiar idea of an architecture decision record^[1] with the one thing a plain decision record usually omits: an explicit account of what was given up.

Its weakness is that a record is only as truthful as its author, and the pressure runs toward softening the residue — recording the decision fully but underplaying the lost guarantee, so the ledger reads as reassurance rather than accounting. A record can also rot: written once, never updated as the impact trace changes, it drifts into a confident but false statement of the current promise. And it is not itself a decision — writing an eloquent record does not make a bad relaxation good. The discipline is to state the lost guarantees in the same plain terms as the surviving ones, to keep the impact trace live rather than frozen at the moment of decision, and to treat the record as documentation of a choice made elsewhere, not as the choosing.

How it implements the components¶

Decision Record with Residue realizes the recording-and-residue machinery of the archetype — the parts that make a resolution durable and its losses explicit:

decision_record — its backbone: the durable capture of what was decided, by whom, and on what grounds.
residual_guarantee_ledger — its distinctive contribution: the explicit accounting of guarantees that survive the relaxation and those given up.
decision_impact_trace — the enumeration of downstream commitments and artifacts the decision touches, so the relaxation propagates consistently.

It records the resolution; it does not produce the trade-off analysis behind it (that is Pareto Frontier Analysis) or size the uncertainty it carries (that is Scenario Sensitivity Sweep), and it holds neither the authority to grant the exception nor the policy for handling future violations — those are Stakeholder Frontier Review's exception authority and violation policy.

Instantiates: Incompatible Requirement Set Resolution — it is the durable output that publishes the chosen resolution and the guarantees and losses that remain.
Consumes: Pareto Frontier Analysis and Constraint Relaxation Experiment supply the chosen trade-off and relaxation it records; Scenario Sensitivity Sweep supplies the uncertainty it notes alongside the residue.
Sibling mechanisms: Pareto Frontier Analysis · Stakeholder Frontier Review · Compatibility Matrix · Requirements Traceability Matrix · Proof Checking · Constraint-Satisfaction Solver Pass · Constraint Relaxation Experiment · Scenario Sensitivity Sweep · Scope-Boundary Stress Test · Impossibility-Theorem Instantiation Review · Minimal Unsatisfiable Core Extraction · SAT/SMT Satisfiability Check · Weighted MaxSAT or Soft-Constraint Optimization

References¶

[1] An Architecture Decision Record (ADR) — a short, durable document capturing a single decision, its context, and its consequences, popularized by Michael Nygard. Decision Record with Residue follows the same form but makes the "consequences" section do heavier duty: an explicit ledger of which guarantees survived the relaxation and which were surrendered. ↩