Decision Taxonomy and Routing: stop debating where decisions go, start closing them

Estimated reading time: 10 minutes

For executives running transformation who want a repeatable decision system: one taxonomy, one intake, one record, and SLAs that actually hold.

Transformation slows down when decisions have no stable routing. People do not disagree on the answer, they disagree on where the question belongs and who owns it. Decision Taxonomy and Routing fixes that with six decision categories, each with metadata: Definition, Owner, Forum, Default SLA, and Required inputs. Then it enforces two artifacts. The Decision Intake Card is the decision request: it provides the context needed to route the request to the right forum with the right SLA. The Decision Output card is the decision record: it documents closure, rationale, risks, and follow-ups. Decision rule: no record = the program treats it as unresolved. This strictness reduces noise, speeds up closure, and improves decision quality without adding process overhead.

The “we already decided that” argument that costs you a quarter

It happens in a steering committee, usually 10 minutes before time runs out.

A leader says: “We already decided this. Why is it back?”
Delivery answers: “We never got a record. We treated it as unresolved.”
Architecture says: “We gave guidance, not a decision.”
Risk says: “We were never asked to accept residual risk.”
Finance says: “Funding was assumed, not approved.”

Nobody is lying. The system is missing.

If decisions can’t be classified, routed, and recorded consistently, they will reappear as rework, escalation, and hidden delay.

That’s what Decision Taxonomy and Routing is designed to prevent.

---

A. Six decision categories and their metadata (taxonomie)

The taxonomy is the map. The metadata is what makes it executable.

1) Strategy and outcomes

Definition: enterprise direction and outcome targets.
Owner: CEO or business president
Forum: Executive committee
Default SLA: 2 to 4 weeks
Required inputs: options, strategic rationale, value and risk narrative, impacts on other priorities

Actual examples:

• “Set 2026 outcome targets for commerce: margin floor, delivery promise, and customer retention objectives.”
• “Decide the enterprise direction for AI: cost productivity first vs differentiated customer experience first.”
• “Approve the operating model outcome: product-led vs project-led delivery for the next 18 months.”

2) Investment and prioritization

Definition: funding, capacity, sequencing, start stop decisions across initiatives.
Owner: COO or CFO
Forum: Portfolio council
Default SLA: 5 to 10 business days
Required inputs: value case, cost and capacity, dependencies, cost of delay

Actual examples:

• “Stop Initiative B and redirect capacity to checkout stabilization due to cost of delay.”
• “Approve incremental funding for data foundation work required for Q3 personalization.”
• “Sequence the platform upgrade ahead of loyalty because dependency risk is now critical.”

3) Product and customer experience

Definition: customer promise and experience choices.
Owner: VP Product, VP Commerce, or CX leader
Forum: Product council
Default SLA: 3 to 10 business days
Required inputs: customer impact, margin impact, experiment plan, guardrails check

Actual examples:

• “Change the returns policy: extend window from 30 to 60 days, with guardrails for abuse.”
• “Adjust delivery promise from 2 days to 3 days for specific regions to protect margin.”
• “Launch guest checkout with fraud guardrails and an experiment plan.”

4) Platform and architecture

Definition: technology choices that create reusable constraints for multiple teams.
Owner: CTO or Chief Architect plus business co owner
Forum: Architecture board
Default SLA: 5 to 15 business days
Required inputs: options assessment, non functional requirements, total cost, migration path

Actual examples:

• “Standardize the API gateway pattern for all customer-facing services.”
• “Select the identity approach for customer login across channels.”
• “Choose the migration path: big bang vs parallel run for the platform upgrade.”

5) Risk, compliance, and guardrails

Definition: non negotiable rules and risk acceptance boundaries.
Owner: Legal, Security, or Risk, single accountable owner per guardrail set
Forum: Risk council or embedded sign off in relevant forum
Default SLA: 5 to 10 business days
Fast track SLA: 24 to 48 hours
Required inputs: risk assessment, control plan, residual risk acceptance path

Actual examples:

• “Set non negotiable rules for customer data use in AI features: retention, vendor access, logging.”
• “Approve a risk exception to store prompts for 30 days with compensating controls.”
• “Define the guardrails for third-party scripts on checkout pages.”

6) Execution and delivery

Definition: delivery tradeoffs inside approved lanes.
Owner: Product owner or program director
Forum: Delivery review or team forum
Default SLA: 24 to 72 hours
Required inputs: delivery impact, dependency impact, mitigation options

Actual examples:

• “Move Feature X from Sprint 6 to Sprint 7 due to dependency delay, apply mitigation option B.”
• “Cut non-essential scope inside guardrails to protect the launch date.”
• “Change release sequencing this week to reduce deployment risk.”

---

B. Decision Intake Card and its metadata (with examples)

The Decision Intake Card is the decision request. It is what you need to route the request to the right forum with the right SLA.

It is allowed to be imperfect. Its job is speed, clarity, and routing.

Decision Intake Card (decision request)

• Context (one-two sentences)
• Category (1 to 6)
• Accountable decision owner (name, or “TBD by routing”)
• Needed by date (and why)
• Decision trigger (what happened or changed)
• What is blocked until this is decided (one sentence)
• Recommendations (XYZ)
• Required inputs (list, per category metadata)
• Attachments available now (list)

Intake example 1 (Investment and prioritization)

• Context: Checkout incidents increased and conversion dropped in peak periods. Current roadmap still funds feature work over stability work.
• Category: 2
• Accountable decision owner: TBD by routing
• Needed by date: Friday 5pm, to lock next sprint and vendor capacity
• Decision trigger: Incident trend + rising cost of delay
• What is blocked: Release plan and capacity allocation for next 6 weeks
• Recommendations (XYZ): X = pause two feature epics, Y = redirect to checkout stabilization, Z = reassess in 4 weeks
• Required inputs: value case, cost and capacity, dependencies, cost of delay
• Attachments available now: incident summary, conversion trend, current roadmap view

Intake example 2 (Risk, compliance, and guardrails – fast track)

• Context: Marketing launched a pilot chatbot. Legal and Security need a decision on prompt logging and retention before scale.
• Category: 5
• Accountable decision owner: Security lead (guardrail owner)
• Needed by date: 48 hours, before expanding to more traffic
• Decision trigger: pilot moved to production usage
• What is blocked: scale-up approval and vendor contract terms
• Recommendations (XYZ): X = no logging, Y = logging with redaction, Z = logging for 30 days with controls + residual risk acceptance
• Required inputs: risk assessment, control plan, residual risk acceptance path
• Attachments available now: vendor architecture note, current pilot configuration, data flow sketch

---

C. Routing rules (the 2-minute classifier)

Make the routing rules a muscle memory, not a debate:

• If it changes enterprise direction or targets -> Strategy and outcomes
• If it changes funding, capacity, or portfolio priority -> Investment and prioritization
• If it changes customer promise, price, policy, or experience -> Product and customer experience
• If it creates a reusable technical constraint or standard -> Platform and architecture
• If it sets or changes a non negotiable rule or risk acceptance -> Risk, compliance, and guardrails
• If it is a local tradeoff within approved scope and guardrails -> Execution and delivery

Tie breaker rule: if two categories apply, route to the higher altitude category.

This one rule removes a common failure mode: teams trying to “solve” a Strategy and outcomes decision inside a delivery meeting.

---

---

E. Decision Output card and its metadata (with examples)

The Decision Output card is the decision record. Use it after the decision is made, to document closure.

Decision rule: No record = the program treats it as unresolved.

This rule is intentionally strict. It reduces noise, speeds up closure, and improves decision quality without adding process overhead.

Decision Output card (decision record)

• Decision statement (one sentence)
• Context + why now
• Options considered
• Recommendation + rationale
• Risks / mitigations
• Owner + approvers
• Date + SLA
• Follow-ups (owner + due date)
• Dissent (if any)

Output example 1 (Platform and architecture)

• Decision statement: “Standardize on API gateway pattern A for all customer-facing services.”
• Context + why now: Multiple teams are implementing different gateway patterns, creating reusable constraints and rising integration risk before the platform upgrade.
• Options considered: A = centralized gateway, B = per-domain gateway, C = vendor-managed gateway
• Recommendation + rationale: Choose A to reduce fragmentation and enforce consistent non functional requirements.
• Risks / mitigations: Migration complexity -> phased migration path and reference implementation.
• Owner + approvers: CTO (owner), Chief Architect and VP Commerce (approvers)
• Date + SLA: Feb 25, closed in 10 business days (SLA 5-15 business days)
• Follow-ups: Reference implementation by Architecture team, due Mar 15. Adoption checklist by Platform PM, due Mar 20.
• Dissent: Domain team B prefers option B due to autonomy, documented.

Output example 2 (Product and customer experience)

• Decision statement: “Launch guest checkout with fraud guardrails and an experiment plan.”
• Context + why now: Guest checkout is a conversion lever, but fraud exposure is rising. Decision needed before the next release train.
• Options considered: A = full guest checkout, B = guest checkout with step-up verification, C = no guest checkout
• Recommendation + rationale: Choose B to balance customer impact and margin impact.
• Risks / mitigations: Fraud spike -> guardrails check, monitoring thresholds, rollback plan.
• Owner + approvers: VP Commerce (owner), Security (approver), Finance (approver on margin threshold)
• Date + SLA: Feb 25, closed in 7 business days (SLA 3-10 business days)
• Follow-ups: Experiment plan owner Product Analytics, due Mar 5. Fraud monitoring owner Security Ops, due Mar 1.
• Dissent: None.

---

F. Measure decision flow weekly and fix root causes

Your operating metrics are exactly the right set:

• % of decisions classified within 24h
• Median cycle time to closure by category vs SLA
• Number of escalations and root cause
• Rework events caused by late or unclear decisions

Use the metrics diagnostically:

• If Strategy and outcomes cycle time is long, check whether too many items are being escalated upward unnecessarily.
• If Platform and architecture is slow, check inputs quality: options assessment, non functional requirements, migration path.
• If Risk, compliance, and guardrails triggers frequent fast track, you likely have poor early guardrails checks upstream.

Over time, this becomes governance as an operating system, not governance as meetings.

---

Related Article

Your transformation is not stuck in tech. It is stuck in approvals

---

FAQ

What is the difference between Decision Intake Card and Decision Output card?

The Decision Intake Card is the request used to route and schedule a decision with the right Owner, Forum, and SLA. The Decision Output card is the record used to document closure, rationale, risks, approvers, and follow-ups. Intake enables speed. Output prevents rework.

Why include “Recommendations (XYZ)” on the Intake Card?

Because leaders should see a directional recommendation early, even if it changes. It reduces ambiguity and helps the decision owner prepare closure. The Intake Card does not require perfect analysis. It requires enough to route and decide.

What does “no record = unresolved” change in practice?

It stops the “we decided that” argument. If the decision is not recorded, delivery cannot treat it as settled. This makes decision closure real, reduces rework, and forces accountability for follow-ups.

How do we prevent everything from being labeled Strategy?

Enforce the routing rules and the tie breaker rule. Most items are Investment, Product, Platform, Risk, or Execution. Strategy should be rare and high altitude. If it is frequent, your outcomes are probably not explicit enough.

---

Executive Takeaways

• The taxonomy is the map, the metadata is the execution engine.
• Decision Intake Card routes fast, Decision Output card prevents rework.
• “No record = unresolved” is the enforcement rule that makes governance real.
• Routing rules plus tie breaker rule stop category leakage into delivery meetings.
• Weekly metrics turn decision flow into an operating system.