Sub-objective Decision Record¶
Decision record — instantiates Objective Boundary Governance
Captures each proposed addition as a standardized record — rationale, fit, displacement, owner, and removal condition — turning the objective's history into an inspectable ledger.
The Sub-objective Decision Record is a standardized per-decision artifact that documents one change to the objective — usually an addition — as it happens: what it is, why it was accepted, what it displaces, who owns it, how it will be measured, and, critically, the condition under which it will later be removed or sunset. Its defining trait is that it is the atomic unit of the objective's history. A single record is unremarkable; a stack of them, appended over time, is the boundary ledger — so decisions that were once made in a hallway and forgotten become an inspectable trail, and the cumulative pattern of "small reasonable additions" finally becomes visible as a pattern.
Example¶
A payments team maintains a product with a tight charter: reduce checkout failure rates. Its product manager institutes a one-page record for every new "must-have" that gets added to the roadmap. When a stakeholder pushes for multi-currency support, it doesn't just go on the board — it gets a record: rationale (EU launch depends on it), fit-to-charter (adjacent, defensible), displacement (delays the refunds-v2 work by a sprint), owner (the payments lead), measure (currencies live in production), and a removal condition (sunset the feature flag if the EU launch is cancelled).
Six months later, when the team can no longer state its core objective in a stable sentence, the records answer the question a meeting never could: eleven additions, each individually reasonable, four of them displacing the original failure-rate work, and only one carrying a removal condition anyone remembered. The stack of records is the evidence that the boundary has ratcheted — and the removal conditions are the pre-agreed handles for pruning it back.
How it works¶
- A fixed field set — every record captures the same slots (what, why, fit, displacement, owner, measure, removal condition), so records are comparable and the ledger is queryable.
- The removal-condition field is mandatory — a record cannot be filed without stating how the addition ends, which forces subtraction thinking at the moment of addition, when it is cheapest.
- Append-only and timestamped — records are never silently deleted; a superseded record is closed, not erased, preserving the trajectory's memory.
- Each carries a revisit date — so additions surface for review rather than living forever by default.
Tuning parameters¶
- Field weight — a heavy template captures more but deters recording; a light one gets filed but may skip displacement or removal. Match to how contested additions are.
- Removal-condition strictness — whether the sunset field must be concrete ("cut if EU launch slips") or may be aspirational. Concrete conditions actually fire; vague ones don't.
- Recording threshold — which additions warrant a record. Too low a bar buries signal in trivia; too high and the meaningful creep goes unlogged.
- Visibility — private log vs. team-visible ledger. Visibility deters casual additions but can chill legitimate ones.
- Default revisit horizon — how soon an unreviewed addition resurfaces.
When it helps, and when it misleads¶
Its strength is that it makes the cumulative pattern legible and forces the removal question at add-time, when resistance is lowest. It is the raw material every downstream mechanism reads — dashboards, audits, and reviews all consume the ledger these records compose. The form is borrowed directly from the Architecture Decision Record[n1], which earned its keep in software precisely by capturing the why of a choice so a later reader isn't left guessing.
Its failure mode is bureaucratic theater: records that are written but never read, or removal conditions filled in pro forma and never enforced. The classic misuse is writing the record after the decision to manufacture a justification rather than to test one. The guarding discipline is to make the records earn their existence — route the dashboard and the periodic audit through them, and treat an unread ledger as a signal the mechanism has decayed.
How it implements the components¶
objective_boundary_ledger— the accumulated records are the ledger of accepted, rejected, deferred, and removed sub-objectives.sub_objective_admission_rule— each record captures the admission-rule answers (fit, displacement, owner, measure, reversibility) for one decision.removal_and_sunset_path— the mandatory removal-condition field attaches a subtraction path to every addition at the moment it is made.
It does not implement objective_dilution_signal or baseline_comparison_cadence — those belong to the Objective Drift Dashboard, which reads this ledger for trends — nor exception_budget (the Objective Change-Control Board). The record is the passive artifact a decision leaves behind; the change-control board is the active forum that makes the decision.
Related¶
- Instantiates: Objective Boundary Governance — the records are the ledger that turns the objective's trajectory into an inspectable object.
- Consumes: Objective Charter supplies the baseline each record judges fit against.
- Sibling mechanisms: Objective Charter · Objective Change-Control Board · Objective Drift Dashboard · Mission-Creep Audit · Opportunity-Cost Review · Plus/Minus Boundary Review · Re-charter Workshop · Deferred Objectives Backlog
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Sub-objective Decision Record operates as a persistent ledger, log, register, or case record that preserves history and traceability because it captures each proposed addition as a standardized record — rationale, fit, displacement, owner, and removal condition — turning the objective's history into an inspectable ledger.
Independent corroboration: The frozen evidence defines Sub-objective Decision Record as 'Captures each proposed addition as a standardized record — rationale, fit, displacement, owner, and removal condition — turning the objective's history into an inspectable ledger', so its operative form is Record, Log & Register.
Nearest alternative: Analysis, Modeling & Optimization — Sub-objective Decision Record includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, but its defining operation is a persistent ledger, log, register, or case record that preserves history and traceability.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Standard records of additions and removal conditions govern scope.
Related originating lineages:
- Accounting & Auditing — Rationale and ownership are traceable.
- Library & Information Science — History is preserved.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: captures each proposed addition as a standardized record — rationale, fit, displacement, owner, and removal condition — turning the objective's history into an inspectable ledger.
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement, origin mode disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] An Architecture Decision Record (ADR), popularized by Michael Nygard, is a short, append-only document capturing one significant decision — its context, the choice, and its consequences — so future readers understand why a system is the way it is. The Sub-objective Decision Record borrows the form and points it at objective additions rather than technical choices. ↩