- Decision & Trust Design
Concept: What is Decision & Trust Design?
Decision & Trust Design starts from the outcomes and value streams you defined in Pillar 1 and focuses on the repeatable choices that materially affect those outcomes. Instead of letting policy and judgment stay hidden in code or tribal knowledge, you model who decides what, based on which information, under which rules, with which safeguards.
A decision is a repeatable choice that changes the path to an outcome (for example, “Approve claim,” “Route patient to fast‑track,” “Escalate incident to L3”). Decision & Trust Design connects:
- Outcomes and stages (from your Outcome Architecture Pack)
- Outcome‑critical decisions at those stages
- Inputs and sub‑decisions each decision depends on
- Business rules and automation boundaries
- Trust controls (logging, oversight, explainability, overrides)
When this chain is explicit, you can safely automate, audit, and improve decisions as conditions change.
Quick self‑check:
- For your main journey, can you name 5–10 decisions that truly change whether outcomes are reached?
- For one such decision, can you sketch its inputs, supporting decisions, and outputs in a way a non‑expert can understand?
Why it matters
Decision & Trust Design:
- Removes hidden policy: Rules stop living only in code and hallway conversations.
- Enables safe automation and AI: You know exactly what you’re automating and what must stay under human judgment.
- Builds trust: Stakeholders can see how decisions are made, challenge them, and rely on consistent behavior.
If you skip this pillar, you risk building powerful automation and analytics that amplify unclear or biased choices, and you make it hard to show regulators, customers, or leaders how critical decisions are being made.
How to learn and practice Pillar 2
Use your Outcome Architecture Pack as the starting point, especially the value‑stream diagram and outcome list.
Step A – Inventory outcome‑critical decisions
From each value‑stream stage:
- Ask: “What decision here significantly changes whether we achieve the outcome?”
- Capture decisions using a simple pattern:
- “Decide whether to <result> based on <inputs>.”
- Collect 10–20 decisions across the journey.
- Prioritize:
- Impact: Does this affect attainment of a key outcome?
- Frequency: How often is this decision made?
- Risk: What happens if it’s wrong (customer impact, safety, regulation)?
Deliverable: A decision inventory, with each decision mapped back to a stage and an outcome, and tagged with impact/frequency/risk.
Step B – Model the structure of a key decision
Pick one high‑priority decision from the inventory.
- Draw the main decision in the center (for example, “Approve claim?”).
- Surround it with:
- Input data (for example, policy details, claim amount, customer history).
- Supporting decisions (for example, “Check eligibility,” “Assess fraud risk,” “Verify documentation”).
- Connect inputs and supporting decisions to the main decision with arrows.
Check:
- Can someone unfamiliar with the domain see what information is needed and which sub‑decisions feed into the main one?
- Does every input and sub‑decision clearly link back to at least one outcome from Pillar 1?
Deliverable: A one‑page decision‑requirements diagram for one decision.
Step C – Turn policy into explicit rules
For the same decision (or a key supporting decision):
- Build a decision table:
- Columns for the most important input conditions (for example, amount ranges, risk scores, eligibility flags).
- One column for the decision result.
- Add 5–10 realistic rule rows that reflect how the organization currently behaves or wants to behave.
- Include a default/“otherwise” row for unexpected combinations.
Tie back to outcomes:
- For each rule row, note which outcome(s) it primarily supports (for example, “minimize fraud losses,” “maximize approval for low‑risk customers”).
Deliverable: A testable decision table for a real decision, with implicit policy made explicit.
Step D – Add a trust overlay
Now define how this decision earns and maintains trust.
For the same decision, specify:
- Logging:
- What gets recorded each time (inputs, rule hit, outcome, timestamp, decider identity).
- Oversight:
- Which cases must be manually reviewed (for example, large values, borderline scores, high‑risk segments).
- Who reviews them and in what timeframe.
- Explainability:
- What minimum explanation must be available (for example, “Declined because income below threshold and adverse history in last 6 months”).
- How explanations are presented to users or auditors.
- Overrides:
- Who is allowed to override the decision.
- How overrides are captured and later analyzed (for example, to refine rules or models).
Deliverable: A one‑page “trust overlay” document attached to the decision model.
Step E – Define and monitor decision quality
Choose 3–5 metrics for the decision:
- Decision latency: Time from request to decision.
- Quality/accuracy: Where you have later ground truth (for example, claim reopen rate, default rate).
- Override rate: Percentage of decisions overridden by humans (not necessarily “bad,” but a signal).
- Escalation rate: Volume sent for manual review.
- Stakeholder trust: Survey or feedback metric (for example, perceived fairness, clarity).
Connect back to outcomes:
- For each metric, identify which outcome(s) it influences (for example, “faster decisions improve Time‑to‑Outcome; unfair decisions harm trust and retention”).
