Purpose-Clause Decision Record¶
Decision record — instantiates Purpose Alignment Design
Captures, at the moment of a consequential decision, which purpose it is meant to serve and what it is explicitly not for, so later reviewers can test for drift.
Purpose-Clause Decision Record is a lightweight artifact captured at the moment of a consequential decision that states which purpose the decision is meant to serve, what it is explicitly not for, and who is accountable for it — timestamped so a later reviewer has a baseline to test for drift. Its defining trait is decision-time documentation of intent: unlike every sibling that analyzes, designs, or redesigns, it produces a durable record. It does not monitor drift or diagnose it; it lays down the purpose baseline and the scope boundary that make later drift detection possible at all.
Example¶
A philanthropic foundation approves a $3M multi-year grant to a job-training nonprofit. Rather than filing only the amount and grantee, the program officer writes a purpose-clause record. Purpose served: "raise sustained-employment rates for returning citizens in the target county." Explicitly not for: "general workforce-development capacity, headcount growth, or the nonprofit's own fundraising." Accountable owner: the named program officer. Date: today. Two years later a new officer reviews the grant and finds the nonprofit has drifted toward serving easier-to-place clients and touting enrollment numbers in its reports. Because the original record drew the nonpurpose boundary ("not headcount growth") and named the intended outcome, the drift is legible in minutes — the review has a fixed baseline to compare against instead of reconstructing the original intent from memory and hallway lore.
How it works¶
- At decision time, write the purpose clause — what end this decision is meant to serve.
- Draw the nonpurpose boundary — what it is explicitly not meant to serve, guarding against later scope creep.
- Name the accountable owner — the person or role answerable for the decision's purpose.
- Timestamp and store it where future reviews will actually look.
- Keep it short — a record, not a strategy document; brevity is what makes it get written at all.
Tuning parameters¶
- Trigger threshold — which decisions get a record (all of them versus only consequential or irreversible ones). More records mean more baselines but more overhead.
- Clause specificity — how tightly the purpose is stated. Tight aids drift detection but can over-constrain later judgment.
- Boundary explicitness — how much effort goes into the "not for" list. The negative space is often exactly where drift hides.
- Owner granularity — a named person versus a role. A person is unambiguously accountable but rotates out; a role persists but diffuses responsibility.
- Retention and retrieval — how discoverable the records are at review time. An unfindable record prevents no drift.
When it helps, and when it misleads¶
Its strength is that it generalizes the Architecture Decision Record[n1] from software to purpose: it captures why at the moment the reasons are freshest, so that drift later has something concrete to be measured against. Its failure mode is records that are dutifully written and never read — a filing ritual that produces baselines nobody consults. The classic misuse is retrofitting a flattering purpose clause after the fact to launder a decision already made for other reasons. The guarding discipline is to write it at decision time rather than after, keep the nonpurpose boundary honest, and ensure a downstream review actually consumes it — because a baseline no one reads prevents no drift.
How it implements the components¶
purpose_statement— records, at decision time, the specific purpose the decision is meant to serve.nonpurpose_boundary— draws the explicit "not for" line that later exposes scope creep.purpose_owner— names who is accountable for the decision's purpose going forward.
It lays down the baseline but does not itself watch for or diagnose drift. The recurring audit that reads these records to catch drift is Mission Alignment Review, which carries the purpose_drift_monitor and misalignment_diagnosis this record lacks. It builds no means_purpose_map and pulls no redesign_lever — it documents intent; it does not analyze or rebuild the system.
Related¶
- Instantiates: Purpose Alignment Design — the memory arm that preserves decision intent so alignment can be checked later.
- Sibling mechanisms: Purpose-to-Metric Mapping · Mission Alignment Review · Outcome-Driven Design · Function Analysis Workshop · Backcasting from Purpose · Goal Alignment Workshop · Product Purpose Review
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Purpose-Clause Decision Record operates as a persistent ledger, log, register, or case record that preserves history and traceability because it captures, at the moment of a consequential decision, which purpose it is meant to serve and what it is explicitly not for, so later reviewers can test for drift.
Independent corroboration: The frozen evidence defines Purpose-Clause Decision Record as 'Captures, at the moment of a consequential decision, which purpose it is meant to serve and what it is explicitly not for, so later reviewers can test for drift', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Specifying an authorized purpose at the outset and testing later use for drift follows legal purpose-limitation doctrine; GDPR Article 5 states the specified-purpose and incompatible-reuse rule.
Related originating lineages:
- Organizational & Management Science — Decision records supplied ownership, timing, and later drift review.
- Philosophy — Teleological and practical-reason traditions supplied the distinction between ends and instrumental proxies.
Review resolution: The blind reviewers disagreed on primary lineage. Light authoritative research resolves the defining form in favor of law_governance: Specifying an authorized purpose at the outset and testing later use for drift follows legal purpose-limitation doctrine; GDPR Article 5 states the specified-purpose and incompatible-reuse rule. The other materially formative traditions are retained as alternates; current breadth of use remains separate as domain_reach=multi_domain.
Attribution caveat: The exact record is an encyclopedia synthesis. The named decision record is an encyclopedia synthesis of purpose limitation and decision logging.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
This is the only mechanism here that is normally consumed rather than run — it produces the decision-time baselines that Mission Alignment Review later audits against. Its value is entirely downstream: a record is worthless until a future review reads it, which is why the retrieval dial matters as much as the writing.
[n1] Architecture Decision Record (ADR) — a short, timestamped document capturing an architectural decision, its context, and its consequences, popularized by Michael Nygard. This mechanism generalizes the format from technical choices to purpose, adding an explicit "not for" boundary. ↩