Decision Registry¶
Software or tool — instantiates Decision Rights Clarification
A searchable system of record for decision rights — look up any decision category and get its current owner, approval requirements, threshold, and escalation path on demand.
A rights map is only useful if someone facing a decision can find it in the moment they need it. Decision Registry is the standing, queryable system that makes authority retrievable: a database, wiki, or catalog keyed by decision category, where each entry names the current owner, the approval requirement and threshold, and where the case goes if it exceeds the boundary. Its defining property is that it is a live system of record[1] — always reflecting the current state, searchable at the point of need — not a snapshot artifact or a historical journal. The question it answers is forward-looking and operational: "I have to decide X right now — who owns it, do I need approval, and at what number does it escalate?" It resolves that in a lookup, so no one has to reconstruct authority from memory, chase down a manager, or guess.
Example¶
A fintech company with a few hundred employees keeps drowning in the same Slack question: "who approves this?" Refund over a customer's disputed charge, a marketing spend, a production database change, onboarding a new vendor, a security exception — each one sparks a thread that pings three managers before landing. They stand up a decision registry as a searchable internal app. Someone types "vendor onboarding" and gets the entry: owner is the procurement lead; approval required from Security if the vendor touches customer data; threshold is that contracts over $25,000/year also need Finance sign-off; escalation goes to the VP of Operations if Security and the requesting team disagree.
An engineer needing an urgent production database change searches "prod DB change," sees that they own changes to their own service under a rollback plan but that schema changes to shared tables require the platform team's approval, and proceeds without opening a single thread. The registry didn't decide anything — it told the engineer, in ten seconds, exactly what authority they had and where the line was. Query volume in the "who-approves" channel drops because the answer now lives somewhere you can look it up.
How it works¶
The registry is a catalog with one entry per decision category and a fixed schema per entry. Category as the key — decisions are indexed by the recurring class they belong to, so a lookup starts from the situation the user is in ("refund," "prod change") rather than from an org chart. Current-state fields — each entry stores the owner, the approval requirement, the numeric or categorical threshold at which requirements change, and the escalation route, and it stores only the version in force, overwriting rather than accreting. Search and reachability — the value is entirely in retrieval, so the registry lives where work happens (a command, a portal, an integration) and is optimized for finding the right entry fast. The distinctive engineering problem is staleness: a registry that lags reality is worse than none, because people trust a wrong answer. So entries carry an owner and a last-reviewed date, and the tool makes the current state cheap to update.
Tuning parameters¶
- Category granularity — how finely decisions are split into entries. Fine granularity answers narrow questions precisely but multiplies entries and maintenance; coarse categories stay lean but leave grey zones the registry can't resolve.
- Field schema — how much each entry captures (owner and threshold only, versus owner, threshold, escalation, rationale, and constraints). Richer entries answer more but are heavier to keep current.
- Update model — self-service editing by owners versus a gatekept change process. Open editing keeps entries fresh but risks unauthorized rewrites of authority; gatekeeping is trustworthy but lags.
- Freshness signaling — whether entries display a last-reviewed date and flag stale ones. Visible freshness lets users calibrate trust; hiding it lets rot pass as truth.
- Surface of access — a standalone portal versus embedding the lookup into the tools where decisions arise. Embedding maximizes use at the moment of need but costs integration work.
When it helps, and when it misleads¶
Its strength is turning a rights design from a document people have to know into a service they can query, which is what actually collapses the permission-seeking and duplicate-approval traffic that clarified rights are supposed to end. It scales: a hundred categories are as findable as five.
It misleads in a specific and dangerous way — a registry radiates authority. When an entry is stale, everyone who trusts it is now confidently wrong, and the failure is silent because the tool looks authoritative regardless of accuracy. A second misuse is treating the registry as the rights design itself: cataloging owners and thresholds is not the same as having done the hard work of actually deciding and legitimizing them, and a tidy searchable table can lend false settledness to authority that was never really agreed. The guard is to pair every entry with an accountable owner and a freshness signal, and to feed the registry from a real review discipline rather than a one-time data-entry sprint — the catalog is only as true as the last time someone checked it.
How it implements the components¶
decision_category— the registry is indexed by category; the recurring decision class is the primary key every lookup starts from.decision_owner— each entry stores and serves the current owner for its category, so "who decides this?" is a retrieval, not an investigation.decision_threshold— entries record the approval requirements and the numeric or categorical thresholds at which those requirements change.escalation_path— each entry records where a case goes when it exceeds the owner's boundary, so the route is looked up, not improvised.
It does not detect when its own entries have gone stale or reconcile them against actual practice (rights_review_trigger, informal_authority_reconciliation — that's Authority Boundary Review); nor does it pry apart the recommend/consult/approve roles behind a single decision (decision_participation_roles — that's the RACI / RAPID-Style Tool).
Related¶
- Instantiates: Decision Rights Clarification — the registry is the operational surface that makes the clarified rights retrievable at the point of decision.
- Sibling mechanisms: Authority Boundary Review · Delegation Charter · Governance Charter · RACI / RAPID-Style Tool · Decision-Rights Matrix · Escalation Protocol · Decision Log · Approval Workflow
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Decision Registry operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a searchable system of record for decision rights — look up any decision category and get its current owner, approval requirements, threshold, and escalation path on demand.
Independent corroboration: The frozen evidence defines Decision Registry as 'A searchable system of record for decision rights — look up any decision category and get its current owner, approval requirements, threshold, and escalation path on demand', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Organization design cohered standing catalogs of decision ownership, approval thresholds, and escalation paths so authority is defined before particular cases arise.
Related originating lineages:
- Computer Science & Software Engineering — Information systems supplied searchable, current systems of record and point-of-need lookup.
- Library & Information Science — Registry and catalog practice supplied controlled categories, authoritative entries, and stewardship of current metadata.
Review resolution: Organization design cohered standing catalogs of decision ownership, approval thresholds, and escalation paths so authority is defined before particular cases arise.
Attribution caveat: Decision-rights content is managerial; the live queryable registry is an information-system synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A Decision Registry is forward-looking authority, not a history. Do not confuse it with a Decision Log, which records what was decided and why after the fact: the registry says who may decide going forward; the log says who did decide and their rationale. A team usually wants both, pointed at different questions.
References¶
[1] DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Technics Publications (2017). Identifies the registry’s defining property as being a live system of record. registry ↩