diff --git a/diagnostics/bias-scan.md b/diagnostics/bias-scan.md new file mode 100644 index 0000000..f60d05e --- /dev/null +++ b/diagnostics/bias-scan.md @@ -0,0 +1,77 @@ +# Bias Scan Diagnostic + +Load when motivated reasoning, deadline pressure, unusual confidence, political pressure, or high-stakes downside could distort the analysis. + +--- + +## Purpose + +AZIMUTH already has inline circuit-breakers for sycophancy, availability, domain calibration, and verdict softening. This diagnostic centralizes the broader bias pass so the core skill does not bloat while still catching common decision distortions. + +Run the scan after the initial risk register exists. Bias scanning before risk generation can prematurely narrow the search space. + +--- + +## Triggers + +Load in STANDARD when any of these fire: + +- user is unusually certain but evidence is thin +- user asks for a fast check on a high-stakes decision +- Module 4 returns YELLOW or RED +- plan contains sunk cost, public commitment, deadline pressure, or authority pressure +- all risks look generic or conveniently manageable +- proposed verdict is PROCEED or PROCEED WITH SAFEGUARDS despite unsupported critical assumptions + +Load unconditionally in DEEP. + +--- + +## Fast Bias Pass + +For each triggered bias, answer: **signal, counter-question, effect on register**. + +| Bias | Signal | Counter-question | Register effect | +|---|---|---|---| +| Sycophancy | User confidence appears mirrored by the model | Would this classification be the same if a stranger proposed it? | Re-check strongest user claim as first UNSUPPORTED candidate | +| Optimism / Planning fallacy | Timeline assumes clean path | What does the outside view say for similar work? | Raise likelihood or add evidence gate | +| Anchoring | Estimate inherits first number mentioned | What estimate would emerge from bottom-up constraints? | Re-score timing risks | +| Availability | Risks mirror generic examples | Which failure trigger is specific to this plan? | Discard generic chains without anchors | +| Confirmation | Only supportive evidence is cited | What would change the verdict? | Add falsifier or DELAY gate | +| Sunk cost | Past spend affects forward decision | Would this be approved fresh today? | Raise governance / reversibility severity | +| Commitment consistency | Public prior statement narrows options | Is consistency being valued over correctness? | Add elephant or incentive entry | +| Authority bias | Senior sponsor/vendor/board pressure dominates | Does their authority apply to this domain? | Escalate Module 4 conflict if needed | +| Social proof / bandwagon | Others doing it is treated as evidence | Do those others share our constraints and failure costs? | Require reference-class fit | +| FOMO | Urgency based on scarce opportunity | What is the cost of waiting, and will similar chances recur? | Test RAPID vs artificial urgency | +| Loss aversion | Avoiding loss dominates upside/downside balance | What opportunity cost is created by avoiding loss? | Add opportunity-cost lens if material | +| Status quo bias | Current path preserved without analysis | Is doing nothing being evaluated as an active option? | Add baseline scenario | +| Shiny object | Novelty substitutes for fit | Is this better or just newer? | Add alternative-path comparison | +| Survivorship bias | Examples include only winners | What failed examples are missing? | Load base rates / failure references | +| Endowment effect | Existing asset/team/idea is overvalued | Would we buy/build this today from scratch? | Re-check cost/benefit assumptions | + +--- + +## Output Shape + +Only include biases that changed the analysis. + +```markdown +## Bias Scan +- [Bias]: [signal]. Counter-question: [question]. Register impact: [risk score / evidence class / verdict changed how]. +``` + +If no bias changed the register, omit the section and state internally: bias scan completed, no output-relevant change. + +--- + +## Verdict Hooks + +- If bias scan changes the top assumption to UNSUPPORTED, Module 10 confidence ceiling applies. +- If bias scan reveals artificial urgency, RAPID may still run, but output must state the urgency appears incentive-driven. +- If bias scan reveals authority, social proof, or sunk-cost pressure, add or escalate an Elephant / incentive conflict entry. + +--- + +## Provenance + +Synthesizes AZIMUTH's existing circuit-breakers with decision-bias counter-question patterns from decision-toolkit-style references. No external text copied. diff --git a/diagnostics/likelihood-impact-matrix.md b/diagnostics/likelihood-impact-matrix.md new file mode 100644 index 0000000..02af07a --- /dev/null +++ b/diagnostics/likelihood-impact-matrix.md @@ -0,0 +1,119 @@ +# Likelihood / Impact Matrix Diagnostic + +Load when STANDARD, DEEP, or any advanced lens produces a non-trivial risk register. This diagnostic quantifies risk without pretending precision the evidence does not support. + +--- + +## Purpose + +AZIMUTH already classifies evidence quality and structural fragility. This file adds a small quantitative layer so the output can distinguish: + +- highly likely moderate failures from rare catastrophic failures +- scary but unsupported speculation from evidence-backed launch blockers +- mitigations that change risk from mitigations that merely sound responsible + +The score is a triage aid, not a verdict by itself. Verdicts still come from the full register, incentive tier, reversibility, and evidence gates. + +--- + +## When to Run + +Run automatically in: + +- **STANDARD** when the register has 3+ material risks, any potential PILOT FIRST verdict, or any potential PROCEED / PROCEED WITH SAFEGUARDS verdict +- **DEEP** whenever Critical Risks are produced +- **RESIDUAL-RISK-REGISTER** outputs when ranking the 3-5 remaining controllable risks +- **MULTI-LENS** or **FOOL** drill-downs when they add risks back into the main register + +Do not run in FAST unless the user explicitly asks for scoring. FAST should stay low-friction. + +--- + +## Scale + +Use a 5x5 matrix unless the user provides a native risk scale. + +### Likelihood (L) + +| Score | Probability anchor | Use when | +|---|---:|---| +| 1 | <5% | Possible, but no direct evidence and weak fit to base rates | +| 2 | 5-20% | Plausible but not the modal path | +| 3 | 20-50% | Credible risk with partial evidence or relevant base-rate support | +| 4 | 50-80% | More likely than not without mitigation | +| 5 | >80% | Already happening, structurally forced, or strongly supported by base rates | + +### Impact (I) + +| Score | Severity anchor | Use when | +|---|---|---| +| 1 | Minor | Local rework; no decision-level impact | +| 2 | Moderate | Schedule slip or bounded cost; recoverable inside current scope | +| 3 | Major | Meaningful delay, reputation hit, missed launch, or stakeholder escalation | +| 4 | Severe | Budget/headcount/customer/contract damage; reversal costly | +| 5 | Existential / decision-killing | Objective fails, public trust loss, irreversible commitment, or strategic dead end | + +--- + +## Base-Rate Adjustment + +Before finalizing L, compare the inside-view estimate to the closest usable reference class. + +1. Identify the closest reference class from `references/base-rates.md` or domain references. +2. If the user's estimate is materially more optimistic than the reference class, raise L by 1 unless they supplied strong differentiating evidence. +3. If the reference class is adjacent but not exact, label it directional and cap its adjustment at +1. +4. If no reference class fits, leave L evidence-based and state uncertainty. + +Never present an adjusted score as actuarial precision. Use language like "directional L=4" when the reference class is imperfect. + +--- + +## Score and Bands + +`Risk Score = Likelihood × Impact` + +| Score | Band | Action posture | +|---:|---|---| +| 1-4 | Green | Track only; do not let it drive the verdict | +| 5-9 | Yellow | Mitigate if cheap; include only if decision-relevant | +| 10-14 | Orange | Requires mitigation or explicit acceptance | +| 15-19 | Red | Decision blocker unless structurally mitigated or tested first | +| 20-25 | Black | Strong bias toward DELAY, REDUCE SCOPE, PILOT FIRST, or REJECT | + +Tie-breaker: when two risks have equal scores, rank later-detectable and less-reversible risks higher. + +--- + +## Output Shape + +Use only for the top 1-5 risks. Do not score every hypothetical. + +| Risk | L | I | L×I | Base-rate adjustment | Detectability | Reversibility | Action | +|---|---:|---:|---:|---|---|---|---| +| [risk] | 4 | 5 | 20 | +1 from reference class | Late | Low | Pilot before full commitment | + +--- + +## Verdict Hooks + +- **PROCEED** is unavailable if any unmitigated register risk scores 15+. +- **PROCEED WITH SAFEGUARDS** requires every 15+ risk to have a named structural safeguard, owner, leading indicator, and review date. +- **PILOT FIRST** requires the pilot to target the highest L×I unsupported assumption or dependency. +- **REDUCE SCOPE** fires when the score is high mainly because scope amplifies impact. +- **DELAY PENDING EVIDENCE** fires when one narrow evidence gate could move L by 2+ points. +- **REJECT** is favored when multiple 15+ risks remain untestable or structurally unmitigated. + +--- + +## Anti-Patterns + +- Do not use scoring to launder weak evidence into confidence. +- Do not assign false precision to unknown probabilities. +- Do not let one dramatic low-likelihood scenario crowd out the most likely failure path. +- Do not average scores. One Black risk can kill the decision. + +--- + +## Provenance + +Adapted conceptually from common likelihood × impact risk matrices and the L/I gap noted in DasClown/premortem-skill `AUDIT.md`. Implementation is AZIMUTH-native: base-rate adjusted, register-bound, and verdict-gated. diff --git a/diagnostics/risk-triage.md b/diagnostics/risk-triage.md new file mode 100644 index 0000000..878e9f9 --- /dev/null +++ b/diagnostics/risk-triage.md @@ -0,0 +1,103 @@ +# Risk Triage Diagnostic + +Load when the register has more risks than the output can responsibly carry, when a user or team is conflating anxiety with evidence, or when unspoken organizational risks may be suppressing the true failure mode. + +--- + +## Purpose + +Separate real launch-blocking risks from scary but weak speculation and from political / unspoken concerns. This keeps AZIMUTH sharp: fewer generic risks, more decision-grade triage. + +--- + +## Categories + +Use the taxonomy in `references/risk-categories.md`. + +- **Tiger** — real, evidence-backed, capable of material harm +- **Paper Tiger** — sounds scary but is unsupported, low-likelihood, or low-impact after inspection +- **Elephant** — unspoken, political, incentive-laden, or socially costly to name + +For Tigers, assign urgency: + +- **Launch-Blocking** — must resolve before commitment / launch +- **Fast-Follow** — can proceed only with a dated post-decision owner and review point +- **Track** — monitor with a leading indicator; does not drive verdict alone + +--- + +## Triage Steps + +1. **Evidence check** — What makes this risk real? +2. **Impact check** — What breaks if it fires? +3. **Timing check** — Must it be resolved before commitment, or can it be watched? +4. **Politics check** — Did the room get quieter around this risk? Is someone punished for naming it? +5. **Actionability check** — Is there a structural action, owner, and review date? + +--- + +## Register Fields + +Use these fields when triage is active: + +| Field | Required? | Notes | +|---|---|---| +| Risk | Yes | Plain-English risk name | +| Category | Yes | Tiger / Paper Tiger / Elephant | +| Urgency | For Tigers | Launch-Blocking / Fast-Follow / Track | +| Evidence | Yes | Data, observation, prior incident, or explicit lack of evidence | +| L/I Score | When scoring active | From `diagnostics/likelihood-impact-matrix.md` | +| Owner | For Launch-Blocking / Fast-Follow / Elephant | Single accountable role/person | +| Leading Indicator | For all output risks | Observable early warning sign | +| Review Date | For accepted / residual risks | Date or decision checkpoint | + +--- + +## Output Shape + +```markdown +## Risk Triage +| Risk | Category | Urgency | Evidence | Owner | Leading Indicator | Review Date | +|---|---|---|---|---|---|---| +``` + +Omit Paper Tigers from Critical Risks unless explaining why a scary objection should not drive the verdict. + +--- + +## Verdict Hooks + +- Any unmitigated **Launch-Blocking Tiger** blocks PROCEED. +- Two or more Launch-Blocking Tigers usually imply DELAY, REDUCE SCOPE, PILOT FIRST, or REJECT. +- Any unresolved **Elephant** involving authority, incentives, dissent suppression, or hidden ownership raises governance severity and may cap confidence. +- A register dominated by Paper Tigers is evidence that anxiety is high but decision risk may be lower than it feels; do not inflate the verdict. + +--- + +## Automation Reference + +A user may implement simple automation with this schema: + +```json +{ + "risks": [ + { + "description": "Authentication service had 3 P1 outages in 30 days", + "category": "tiger", + "evidence": "Incident reports", + "urgency": "launch_blocking", + "owner": "Platform lead", + "leading_indicator": "P1 recurrence or error budget breach", + "review_date": "YYYY-MM-DD" + } + ] +} +``` + +AZIMUTH does not require code execution. The schema is enough to improve reasoning and handoff quality. + +--- + +## Provenance + +Adapted conceptually from the Tiger / Paper Tiger / Elephant framing in borghei/Claude-Skills pre-mortem. This file is original AZIMUTH integration and avoids copying the Commons Clause script. diff --git a/learnings/outcome-tracking.md b/learnings/outcome-tracking.md new file mode 100644 index 0000000..5811b71 --- /dev/null +++ b/learnings/outcome-tracking.md @@ -0,0 +1,54 @@ +# Outcome Tracking Loop + +Use after a decision has time to produce signal. This is not part of the core run unless the user asks for a learning review. + +--- + +## Purpose + +Feed real outcomes back into AZIMUTH's base rates, gotchas, and diagnostic calibration. The skill improves only if predictions are compared against reality. + +--- + +## Review Cadence + +At the review date from `templates/commitment-lock.md` or `templates/decision-record.md`, capture: + +| Field | Prompt | +|---|---| +| Original verdict | What did AZIMUTH recommend? | +| Actual decision | What did the user/team do? | +| Outcome | What happened? | +| Prediction hit | Which risks occurred? | +| Prediction miss | What happened that AZIMUTH missed? | +| False alarm | Which risks were over-weighted? | +| Leading indicator quality | Did indicators fire early enough? | +| Calibration change | What should change in base rates, gotchas, or diagnostics? | + +--- + +## Learning Classes + +- **Base-rate update** — observed outcome changes reference-class expectations +- **Gotcha candidate** — recurring cross-domain pattern not currently captured +- **Diagnostic weakness** — existing diagnostic missed or over-weighted a signal +- **Commitment failure** — risk was identified but no owned action happened +- **Verdict calibration** — verdict was too soft or too severe for the evidence + +--- + +## Output + +```markdown +## AZIMUTH Outcome Review +- Original verdict: ... +- Actual outcome: ... +- Calibration finding: ... +- Repository update candidate: ... +``` + +--- + +## Provenance + +Implements AZIMUTH's self-improvement loop: outcome evidence should feed future base-rate, gotcha, and commitment calibration rather than remain anecdotal. diff --git a/references/audit-trail.md b/references/audit-trail.md new file mode 100644 index 0000000..b2cf2a2 --- /dev/null +++ b/references/audit-trail.md @@ -0,0 +1,72 @@ +# Audit Trail and Provenance Tags + +Load when DEEP mode, MULTI-LENS, external references, or any consequential recommendation needs traceability. + +--- + +## Purpose + +The reader should know why AZIMUTH reached the verdict, which modules ran, what evidence changed the decision, and which claims are unsupported. + +Audit trail is not academic citation bloat. It is operational accountability. + +--- + +## Claim Tags + +Use compact tags in decision records or DEEP outputs: + +| Tag | Meaning | +|---|---| +| `[USER]` | Provided directly by user | +| `[PLAN]` | Derived from supplied plan text | +| `[BASE-RATE]` | Grounded in `references/base-rates.md` or domain reference | +| `[DIAGNOSTIC]` | Produced by an AZIMUTH diagnostic file | +| `[INFERENCE]` | Reasoned from context; not directly evidenced | +| `[MISSING]` | Required evidence absent | +| `[CONFLICT]` | Evidence contradicts the plan or another claim | + +Do not tag every sentence. Tag decision-driving claims only. + +--- + +## Module Audit + +For DEEP and exportable decision records, include: + +```markdown +## Audit Trail +| Module / Lens | Ran? | Decision-changing finding | +|---|---:|---| +| Objective Integrity | Yes | ... | +| Assumption Audit | Yes | ... | +| Incentive Scan | Yes | ... | +| L/I Matrix | Yes | ... | +| Risk Triage | Yes | ... | +| Multi-Lens | No | Not triggered | +``` + +--- + +## Provenance Line + +When borrowing a framework or running a drill-down, include a one-line provenance note in the artifact if it affects the output: + +```markdown +Provenance: Used AZIMUTH `risk-triage` and `likelihood-impact-matrix` diagnostics; no external claims beyond user-supplied plan and loaded base-rate references. +``` + +--- + +## Anti-Patterns + +- Do not use provenance tags to make weak inference look strong. +- Do not cite a framework as evidence for a factual claim. +- Do not include audit trail in FAST mode unless user asks. +- Do not let traceability obscure the verdict-first rule. + +--- + +## Provenance + +Implements AZIMUTH's planned evidence tags and audit-trail roadmap item. diff --git a/references/bias-encyclopedia.md b/references/bias-encyclopedia.md new file mode 100644 index 0000000..0c6dad4 --- /dev/null +++ b/references/bias-encyclopedia.md @@ -0,0 +1,163 @@ +# Bias Encyclopedia + +Load when `diagnostics/bias-scan.md` needs deeper counter-questions or when the user explicitly asks for a bias audit. + +--- + +## Core Biases and Counter-Questions + +### FOMO + +**Signal:** urgency is based on fear that the opportunity disappears. + +**Counter-questions:** +- What evidence suggests this is truly one-of-a-kind? +- What is the actual cost of waiting? +- Will similar opportunities exist later? + +### Sunk Cost Fallacy + +**Signal:** prior spend, reputation, or effort is used as a reason to continue. + +**Counter-questions:** +- If nothing had been invested yet, would this be approved today? +- Is continuing actually recovering the past investment? +- What future value justifies the next commitment? + +### Authority Bias + +**Signal:** sponsor, executive, vendor, investor, or expert status substitutes for evidence. + +**Counter-questions:** +- Does this authority apply to the specific domain? +- What is their track record on similar decisions? +- Would the same evidence persuade us from an unknown person? + +### Social Proof / Bandwagon + +**Signal:** others doing it is treated as proof it will work here. + +**Counter-questions:** +- Are those examples operating under the same constraints? +- What is the base rate for teams that copied this pattern and failed? +- Would we still do this if no peer had done it? + +### Commitment and Consistency + +**Signal:** prior public position narrows willingness to revise. + +**Counter-questions:** +- Has new information emerged since the commitment? +- Is consistency being valued above correctness? +- What would a neutral reviewer advise now? + +### Optimism / Planning Fallacy + +**Signal:** timeline assumes clean execution and no compounding failures. + +**Counter-questions:** +- What does the outside view say? +- What usually slips first in this category? +- What would make the estimate double? + +### Confirmation Bias + +**Signal:** supportive evidence is abundant; disconfirming evidence is absent. + +**Counter-questions:** +- What evidence would change the verdict? +- Has anyone looked for failure cases? +- Are neutral facts being interpreted as supportive? + +### Anchoring + +**Signal:** initial estimate, budget, or scope persists despite weak grounding. + +**Counter-questions:** +- What estimate emerges if rebuilt from constraints? +- Who supplied the anchor and what incentive did they have? +- What is the reference-class estimate? + +### Availability + +**Signal:** examples are recent, vivid, or generic rather than plan-specific. + +**Counter-questions:** +- What risks are statistically common but not vivid? +- Is this failure path anchored in the plan's actual dependencies? +- What would the analysis say if the last memorable example were unavailable? + +### Loss Aversion + +**Signal:** avoiding loss dominates potential upside or opportunity cost. + +**Counter-questions:** +- Are losses and gains being weighted symmetrically? +- What is the cost of avoiding this risk? +- Is the safer path actually creating a larger strategic loss? + +### Status Quo Bias + +**Signal:** doing nothing is treated as neutral. + +**Counter-questions:** +- What happens if no decision is made? +- What risks compound under the current state? +- Would the status quo be chosen if it were a new proposal? + +### Shiny Object Syndrome + +**Signal:** novelty is treated as evidence of superiority. + +**Counter-questions:** +- Is this better or just newer? +- What boring alternative solves the same problem? +- What maintenance cost appears after novelty fades? + +### Survivorship Bias + +**Signal:** success stories dominate the evidence base. + +**Counter-questions:** +- What failed examples are missing? +- Who tried this and reverted? +- What do base rates say across all attempts? + +### Endowment Effect + +**Signal:** existing asset, idea, team, or codebase is overvalued because it is ours. + +**Counter-questions:** +- Would we buy or build this again today? +- What would an outsider value it at? +- Is ownership distorting expected value? + +### Groupthink + +**Signal:** consensus appears too smooth; dissent is absent or minimized. + +**Counter-questions:** +- Who disagrees privately? +- What concern would be costly to state publicly? +- Has the strongest counter-position been steelmanned? + +### Halo Effect + +**Signal:** one positive attribute spills into unrelated judgments. + +**Counter-questions:** +- Which parts of the decision are independently verified? +- Are we treating brand, founder, or team reputation as evidence for execution? +- What would this look like without the halo? + +--- + +## Use Rule + +Do not list biases for education. Use this file only to change the register, confidence, verdict, or decision record. + +--- + +## Provenance + +Original AZIMUTH reference synthesized from common decision-science bias taxonomies and decision-toolkit counter-question patterns. diff --git a/references/critical-reasoning-modes.md b/references/critical-reasoning-modes.md new file mode 100644 index 0000000..1795167 --- /dev/null +++ b/references/critical-reasoning-modes.md @@ -0,0 +1,121 @@ +# Critical Reasoning Modes + +Load when the user asks for `AZIMUTH FOOL: ...`, when framing is uncertain, or when the standard pre-mortem finds a real unresolved clash rather than a simple risk register. + +--- + +## Purpose + +These modes add challenge depth without turning AZIMUTH into a general debate bot. They are drill-down lenses that feed findings back into the main AZIMUTH register and verdict. + +Use one mode at a time unless DEEP explicitly needs synthesis across modes. + +--- + +## Modes + +| Command | Mode | Use when | Output | +|---|---|---|---| +| `AZIMUTH FOOL: socratic` | Socratic Assumption Surfacing | The plan's premises are vague or inherited | Assumption inventory + probing questions + validation experiments | +| `AZIMUTH FOOL: dialectic` | Dialectic / Steelman / Synthesis | There is a credible opposing view | Thesis, antithesis, conflict dimensions, synthesis | +| `AZIMUTH FOOL: red-team` | Attack This | An adversary, competitor, regulator, or internal failure actor matters | Attack vectors + defenses + perverse incentives | +| `AZIMUTH FOOL: evidence` | Evidence Testing | Claims may outrun evidence | Claim table + evidence grade + falsifier + competing explanation | +| `AZIMUTH FOOL: critic` | Brutal Critic | Output is too polite, padded, or non-decisive | Hardest truthful objections + what must change | + +--- + +## Auto-Load Triggers + +Auto-load only in STANDARD+ and only when useful: + +- **Socratic**: objective or success metric is fuzzy; key assumption is inherited from another plan +- **Dialectic**: two credible paths remain after Module 10, or the user asks for the other side +- **Red-team**: competitor, abuse, regulatory, launch, or adversarial exploitation risk is central +- **Evidence**: top claims have partial / unsupported evidence but user confidence is high +- **Critic**: draft output risks softening, motivational filler, or over-balanced prose + +--- + +## Dialectic Synthesis + +Process: + +1. Steelman the user's thesis. +2. Construct the strongest opposing argument. +3. Name points of genuine conflict. +4. Propose a synthesis using one of these patterns: + - Conditional: X when A, Y when B + - Scope partition: X for domain A, Y for domain B + - Temporal: start with X, migrate to Y at trigger Z + - Risk mitigation: proceed with X only with safeguards from Y + - Pivot: antithesis is stronger; reconsider original path + +Output: + +```markdown +## Synthesis +- What survives from the thesis: ... +- What survives from the antithesis: ... +- What must be given up: ... +- Register impact: [risk / assumption / verdict change] +``` + +--- + +## Evidence Testing + +For each load-bearing claim: + +| Claim | Evidence grade | Falsifier | Competing explanation | Register impact | +|---|---|---|---|---| + +Evidence grades: + +- Strong: directly relevant, recent, observable, independently checked +- Partial: relevant but incomplete, adjacent, or not independently verified +- Unsupported: asserted without evidence +- Contradicted: evidence points against the claim + +--- + +## Red-Team + +Ask: + +- Who benefits if this fails? +- Who can exploit the plan's weakest dependency? +- What would a competitor, regulator, attacker, or internal opponent do first? +- What defense changes system conditions rather than adding vigilance? + +--- + +## Brutal Critic + +Use sparingly. The critic is not rude; it is compression without politeness-padding. + +Rules: + +- Name the hardest true objection. +- Remove hedging unless uncertainty is real. +- Convert vague concerns into concrete blockers. +- If the plan should not proceed, say so. + +--- + +## Integration Rule + +Every FOOL finding must map back to one of: + +- a new or changed register entry +- a changed evidence classification +- a changed L/I score +- a changed verdict +- a decision-record note + +If it does none of those, omit it. + +--- + +## Provenance + +Adapted conceptually from critical-reasoning skill patterns: Socratic questioning, dialectic synthesis, red teaming, and evidence audits. Rewritten as AZIMUTH drill-down modes. diff --git a/references/module-customization.md b/references/module-customization.md new file mode 100644 index 0000000..df39679 --- /dev/null +++ b/references/module-customization.md @@ -0,0 +1,74 @@ +# Module Customization Guide + +Load when users want to fork AZIMUTH, add a domain pack, or tune it for a team. + +--- + +## Purpose + +Make AZIMUTH easy to adapt without weakening the core decision discipline. + +--- + +## What to Customize + +Safe extension points: + +- `references/` — domain failure patterns, base rates, bias references +- `diagnostics/` — deeper scoring or audit procedures +- `templates/` — output shapes for an audience or tool +- `learnings/` — outcome review and calibration notes + +Avoid changing these unless you have eval evidence: + +- verdict taxonomy +- Module 4 incentive tiering consequences +- Module 10 confidence ceilings +- WRONG TOOL / INSUFFICIENT SIGNAL / RESIDUAL-RISK-REGISTER boundaries +- anti-slop rules + +--- + +## Domain Pack Pattern + +A domain pack should include: + +```text +references/[domain]-failure-patterns.md +templates/[domain]-azimuth.md +evals/[domain]-case-study.md +``` + +Each failure pattern should have: + +- signal +- diagnostic question +- evidence class +- mitigation that changes system conditions +- known false positives + +--- + +## Checklist for New Modules + +- [ ] Does it load conditionally? +- [ ] Does it change a verdict, score, category, commitment, or artifact? +- [ ] Does it avoid duplicating existing modules? +- [ ] Does it preserve verdict-first output? +- [ ] Does it include provenance? +- [ ] Is there at least one eval or case study showing why it matters? + +--- + +## Anti-Patterns + +- Adding frameworks because they are popular, not because they change decisions +- Expanding SKILL.md until core routing is buried +- Turning AZIMUTH into generic coaching or brainstorming +- Weakening hard verdicts to improve user comfort + +--- + +## Provenance + +Inspired by high-adoption meta-skill and skill-creator patterns. Rewritten for AZIMUTH's modular architecture. diff --git a/references/multi-frameworks.md b/references/multi-frameworks.md new file mode 100644 index 0000000..8a9444c --- /dev/null +++ b/references/multi-frameworks.md @@ -0,0 +1,116 @@ +# Multi-Framework Decision Lenses + +Load only when the user asks for MULTI-LENS, when opportunity cost is central, or when the main pre-mortem leaves a legitimate trade-off unresolved. + +--- + +## Purpose + +AZIMUTH's default job is pre-commitment pressure-testing. Multi-framework lenses are not a replacement for the core pipeline. They are auxiliary checks used when the decision is not only "will this fail?" but also "is this the right bet compared with alternatives?" + +--- + +## Routing + +Use 2-3 lenses maximum. More creates framework theater. + +| Lens | Use when | Output | +|---|---|---| +| Opportunity Cost | A decision consumes scarce time, capital, attention, or reputation | What is displaced and whether displacement is acceptable | +| Scenario Matrix | Outcomes vary meaningfully by external state | Worst / bad / neutral / good / best with probability and consequence | +| Regret Minimization | Long-term strategic or identity-level decision | Regret of action vs inaction over long horizon | +| 10-10-10 | Emotional urgency or short-term pressure may distort choice | View at 10 minutes, 10 months, 10 years | +| First Principles | Framing may be inherited or solution-first | Problem, constraint, and non-negotiable truth check | + +--- + +## Opportunity Cost + +Ask: + +- What does this consume that cannot also go elsewhere? +- What current initiative slows, loses owner attention, or becomes impossible? +- Is the displaced option more reversible, more evidence-backed, or more strategically central? + +Output: + +```markdown +## Opportunity Cost +- Scarce resource consumed: [time/capital/reputation/attention] +- Displaced alternative: [alternative] +- Relative evidence: [which option has stronger evidence] +- Decision impact: [how this changes verdict or scope] +``` + +--- + +## Scenario Matrix + +Use when external uncertainty dominates: market timing, regulation, partner behavior, funding, macro, hiring market, customer adoption. + +| Scenario | Probability | Outcome | Leading Indicator | Decision implication | +|---|---:|---|---|---| +| Worst | X% | ... | ... | ... | +| Bad | X% | ... | ... | ... | +| Neutral | X% | ... | ... | ... | +| Good | X% | ... | ... | ... | +| Best | X% | ... | ... | ... | + +Keep probabilities directional. If probabilities cannot be grounded, say so and use ordinal likelihood. + +--- + +## Regret Minimization + +Ask from a longer horizon: + +- Would the user regret doing this if it fails for predictable reasons? +- Would the user regret not doing it if the opportunity remains real? +- Is regret driven by principle, status, fear, or evidence? + +Use this lens to surface strategic preference, not to override operational risk. + +--- + +## 10-10-10 + +Ask: + +- 10 minutes after deciding, what emotion dominates? +- 10 months later, what operational consequence dominates? +- 10 years later, what strategic story dominates? + +If the 10-minute answer drives the choice but the 10-month answer bears the cost, flag short-term affect bias. + +--- + +## First Principles + +Ask: + +- What problem must be solved? +- What constraints are real rather than inherited? +- What would be true if the current solution were unavailable? +- What is the smallest commitment that tests the core truth? + +If first-principles analysis changes the decision frame, do not hide that inside a normal verdict. State that AZIMUTH found a framing problem and separate it from the go/no-go verdict. + +--- + +## Synthesis Rule + +Multi-lens output must reconcile with the AZIMUTH verdict. + +```markdown +## Multi-Lens Synthesis +- Core AZIMUTH verdict: [verdict] +- Lens conflict: [where a lens points differently] +- Reconciliation: [why the final decision does or does not change] +- Decision record note: [what should be preserved for future review] +``` + +--- + +## Provenance + +Adapted from common decision-toolkit frameworks including opportunity cost, scenario matrices, 10-10-10, regret minimization, and first-principles checks. Integrated as conditional references to avoid core-load bloat. diff --git a/references/risk-categories.md b/references/risk-categories.md new file mode 100644 index 0000000..90e94a9 --- /dev/null +++ b/references/risk-categories.md @@ -0,0 +1,89 @@ +# Risk Categories: Tigers, Paper Tigers, Elephants + +Use this reference when the risk register is crowded, politically sensitive, or risk-heavy enough that qualitative severity alone is not enough. + +--- + +## Tiger + +A **Tiger** is a real, evidence-backed risk that can materially harm the decision if not addressed. + +### Signals + +- Supported by data, incidents, customer evidence, failed prior attempts, known constraints, or credible base rates +- Concrete failure mechanism can be described +- Ignoring it would be negligent +- There is a plausible path from trigger to business cost + +### Urgency + +| Urgency | Meaning | Required response | +|---|---|---| +| Launch-Blocking | Must be resolved before commitment / launch | Structural mitigation, owner, leading indicator, review date | +| Fast-Follow | Can proceed only with short dated follow-up | Owner, 1-2 week review, escalation trigger | +| Track | Real but not decision-blocking yet | Leading indicator and review cadence | + +--- + +## Paper Tiger + +A **Paper Tiger** sounds dangerous but is low-likelihood, low-impact, unsupported, or already handled. + +### Signals + +- Hypothetical without evidence +- Dramatic but not plausible for this context +- Duplicates a mitigated risk +- Has low impact even if it occurs +- Based on anxiety, not mechanism + +### Required response + +Do not let Paper Tigers drive the verdict. Either omit them or include a short note explaining why they were downgraded. + +--- + +## Elephant + +An **Elephant** is an unspoken, political, incentive-laden, or socially costly risk. Elephants often involve people, power, ownership, dissent, accountability, or hidden disagreement. + +### Signals + +- The team avoids the topic +- Concern is known privately but absent from written plans +- Someone benefits if the risk is not discussed +- Naming the risk would create conflict with a sponsor, executive, vendor, or founder +- The plan depends on a disengaged, overloaded, or opposed person + +### Required response + +1. Name it neutrally. +2. Decide whether it is also a Tiger in disguise. +3. Assign owner or escalation path. +4. If it remains unresolved, cap confidence and reflect it in Module 4 / governance risk. + +--- + +## Integration with AZIMUTH + +- Module 2 assumptions can become Tigers if unsupported and load-bearing. +- Module 4 conflicts often become Elephants. +- Module 5 dependencies often become Tigers. +- Module 6 failure chains should be built primarily from Tigers and Elephants, not Paper Tigers. +- Module 8 ranks risks by detectability and reversibility after categorization. +- Module 10 blocks PROCEED when launch-blocking Tigers remain unmitigated. + +--- + +## Anti-Patterns + +- Calling every risk a Tiger because the team is anxious +- Calling political risks Paper Tigers because they are uncomfortable +- Treating Paper Tigers as harmless if they distract from a real Tiger +- Using Elephant language as gossip; keep it operational and evidence-based + +--- + +## Provenance + +Concept adapted from borghei/Claude-Skills pre-mortem. Definitions and integration rules are rewritten for AZIMUTH's register, verdict, and progressive-disclosure architecture. diff --git a/references/thinking-partners.md b/references/thinking-partners.md new file mode 100644 index 0000000..a291091 --- /dev/null +++ b/references/thinking-partners.md @@ -0,0 +1,63 @@ +# Thinking Partner Protocols + +Load only when AZIMUTH needs a lightweight internal challenge persona without leaving the decision-pressure pipeline. + +--- + +## Brutal Critic + +Use when the output risks being too nice, too balanced, or too verbose. + +### Protocol + +1. State the central weakness in one sentence. +2. Name the strongest reason the plan should not proceed as framed. +3. Identify the one unsupported claim most responsible for false confidence. +4. Remove any mitigation that depends on vibes: "communicate," "align," "monitor," "try harder." +5. Convert the critique into a required plan change. + +### Output + +```markdown +## Brutal Critic Pass +- Hardest true objection: ... +- False-confidence source: ... +- Required change: ... +``` + +--- + +## Socratic Explorer + +Use when the plan may be solving the wrong problem, or when the user's stated objective is too thin to support a verdict. + +### Protocol + +Ask no more than 5 questions, ordered by decision leverage: + +1. What problem would still exist if this plan succeeded? +2. What must be true for this to be the right problem? +3. What would make the opposite decision obviously correct? +4. Who pays the cost if this is wrong? +5. What is the smallest test that would change the decision? + +### Output + +If the answers change the frame, state: + +```markdown +## Framing Shift +AZIMUTH found that the decision frame changed from [old] to [new]. Run the verdict on the new frame, not the original wording. +``` + +--- + +## Use Discipline + +Thinking partners are not personas for style. They are conditional reasoning tools. Load only when they change the register or frame. + +--- + +## Provenance + +Inspired by thinking-partner protocols such as Brutal Critic and Socratic Explorer. Rewritten for AZIMUTH as conditional internal references. diff --git a/references/token-aware-loading.md b/references/token-aware-loading.md new file mode 100644 index 0000000..8973466 --- /dev/null +++ b/references/token-aware-loading.md @@ -0,0 +1,64 @@ +# Token-Aware Loading and Drill Commands + +Load when extending AZIMUTH or when a run risks bloat from too many diagnostics. + +--- + +## Purpose + +AZIMUTH's advantage is progressive disclosure. The core should route sharply; depth should load only when it changes the decision. + +--- + +## Drill Commands + +Users can force specific modules without turning on every advanced lens: + +| Command | Loads | +|---|---| +| `AZIMUTH DRILL: commitments` | `templates/commitment-lock.md`, `references/workflow-closure.md` | +| `AZIMUTH DRILL: score` | `diagnostics/likelihood-impact-matrix.md` | +| `AZIMUTH DRILL: triage` | `diagnostics/risk-triage.md`, `references/risk-categories.md` | +| `AZIMUTH DRILL: bias` | `diagnostics/bias-scan.md`, optionally `references/bias-encyclopedia.md` | +| `AZIMUTH DRILL: export` | `templates/export-formats.md`, `templates/decision-record.md` | +| `AZIMUTH DRILL: audit` | `references/audit-trail.md` | +| `AZIMUTH DRILL: learn` | `learnings/outcome-tracking.md` | +| `AZIMUTH MULTI-LENS` | `references/multi-frameworks.md`, `templates/multi-lens-summary.md` | +| `AZIMUTH FOOL: [mode]` | `references/critical-reasoning-modes.md` | + +--- + +## Loading Budget + +Use this order: + +1. Core SKILL routing and modules +2. Domain template / domain reference +3. Only diagnostics whose triggers fired +4. Only templates needed for final artifact +5. Audit/provenance only for DEEP or exportable records +6. Learning loop only after outcome evidence exists + +If more than three optional files would load in STANDARD, stop and ask whether the user wants deeper analysis or a lean verdict. + +--- + +## Integration Rule + +Optional files must change at least one of: + +- evidence classification +- L/I score +- risk category +- verdict +- commitment / owner / indicator +- export artifact +- learning update + +If not, do not include their output. + +--- + +## Provenance + +Original AZIMUTH loading discipline for modular adoption-oriented extensions. diff --git a/references/workflow-closure.md b/references/workflow-closure.md new file mode 100644 index 0000000..f14c385 --- /dev/null +++ b/references/workflow-closure.md @@ -0,0 +1,93 @@ +# Workflow Closure Protocol + +Load after AZIMUTH returns a verdict or residual-risk register and the user needs follow-through rather than more analysis. + +--- + +## Purpose + +High-quality decision analysis fails if it does not change the next action. This protocol turns a verdict into an execution handoff, persistent tracking artifact, and review loop. + +Use it to make AZIMUTH a workflow closer, not a report generator. + +--- + +## When to Run + +Run in STANDARD+ when any of these are true: + +- Verdict is PROCEED WITH SAFEGUARDS, PILOT FIRST, REDUCE SCOPE, DELAY PENDING EVIDENCE, or RESIDUAL-RISK-REGISTER +- User asks "what now?", "make this actionable", "turn into a plan", "handoff", or "track this" +- The output includes any Launch-Blocking Tiger, Elephant, Red/Black L×I risk, or accepted residual risk +- DEEP mode was used and a decision record is warranted + +Do not run automatically for INSUFFICIENT SIGNAL or WRONG TOOL unless the user asks for a refactoring prompt. + +--- + +## Next Action Protocol + +Produce only decision-changing follow-through. + +```markdown +## Next Action Protocol + +### 1. Immediate Decision Gate +- Decision owner: [person/role] +- Gate: [what must be true before commitment] +- Deadline / review point: [date or named milestone] + +### 2. Required Commitments +| Finding | Action | Owner | Leading Indicator | Review Date | Escalation Trigger | +|---|---|---|---|---|---| + +### 3. Handoff Prompt +Use this prompt with the execution agent / team: + +> We are acting on AZIMUTH verdict [VERDICT] for [decision]. Preserve these constraints: [constraints]. Do not proceed past [gate] until [evidence]. Track these indicators: [indicators]. + +### 4. Follow-Up Review +- First review: [date] +- Outcome evidence to collect: [evidence] +- Decision that will be revisited: [scope / proceed / stop / expand] +``` + +--- + +## Persistence Options + +If the user wants durable state, write or export one of: + +- `templates/decision-record.md` — final decision artifact +- `templates/commitment-lock.md` — owned mitigation table +- `learnings/outcome-tracking.md` — post-outcome calibration record +- `templates/export-formats.md` — CSV/Jira/Obsidian-ready register formats + +AZIMUTH should not pretend it can persist files unless the runtime can actually write them. If persistence is unavailable, output a copy-ready artifact. + +--- + +## Safety Gates Before Execution + +Before handing off to execution, confirm: + +1. The execution task matches the verdict. Do not execute full scope after PILOT FIRST or REDUCE SCOPE. +2. Every Launch-Blocking Tiger has an owner and decision date. +3. Every accepted Red/Black L×I risk has a leading indicator and escalation trigger. +4. The highest-risk assumption has a falsifier or evidence gate. +5. The handoff prompt names what must not be optimized away. + +--- + +## Anti-Patterns + +- Do not turn every finding into a task; only decision-changing findings get tracked. +- Do not use "team" as owner. +- Do not let a generic implementation plan overwrite the verdict constraints. +- Do not produce follow-up theater when the verdict is REJECT; the only next action may be stopping or reframing. + +--- + +## Provenance + +Inspired by workflow-orchestration and persistent-planning patterns common in high-adoption Claude skills. Rewritten for AZIMUTH's verdict and register model. diff --git a/templates/commitment-lock.md b/templates/commitment-lock.md new file mode 100644 index 0000000..1487417 --- /dev/null +++ b/templates/commitment-lock.md @@ -0,0 +1,69 @@ +# Commitment Lock Template + +Use in DEEP mode and in STANDARD when the verdict is PROCEED, PROCEED WITH SAFEGUARDS, PILOT FIRST, DELAY PENDING EVIDENCE, or RESIDUAL-RISK-REGISTER. + +--- + +## Purpose + +A decision-pressure test only matters if it changes the plan. Commitment Lock converts findings into owned, dated actions. + +This is not a generic action-items list. Each item must map to a Critical Risk, Weak Assumption, Launch-Blocking Tiger, or residual risk. + +--- + +## Commitment Triplet + +Use this format: + +| Risk / Finding | Action | Owner | Leading Indicator | Review Date | Stop / Escalate Trigger | +|---|---|---|---|---|---| +| [risk] | [specific structural action] | [one owner] | [observable signal] | [date] | [condition that changes decision] | + +The minimum unit is actually five fields: **Action + Owner + Leading Indicator + Review Date + Escalation Trigger**. + +--- + +## Rules + +- Every Launch-Blocking Tiger needs a Commitment Lock entry. +- Every accepted Red/Black L×I risk needs a Commitment Lock entry. +- Every residual risk needs a leading indicator and escalation trigger. +- Owners must be singular. "Team" is not an owner. +- Review dates must be calendar dates or named decision checkpoints. +- Weak mitigations are rejected. + +--- + +## Confirmation Block + +For DEEP mode, end with: + +```markdown +## Commitment Lock +The decision should not be treated as accepted until the following commitments are explicitly owned: + +[table] + +Confirmation required: [decision-maker] accepts these owners, indicators, and review dates before proceeding. +``` + +For STANDARD mode, include the table when it changes the verdict or prevents a soft PROCEED. + +--- + +## Residual-Risk Variant + +When Module 10 returns RESIDUAL-RISK-REGISTER, do not ask whether to proceed. Use: + +```markdown +## Residual Risk Commitments +| Residual Risk | Owner | Leading Indicator | Escalation Trigger | First Review | +|---|---|---|---|---| +``` + +--- + +## Provenance + +Adapted from commitment mechanisms in premortem practice and the commitment gap identified in DasClown/premortem-skill `AUDIT.md`. Implemented as an AZIMUTH verdict-to-action gate. diff --git a/templates/decision-record.md b/templates/decision-record.md new file mode 100644 index 0000000..24c63f5 --- /dev/null +++ b/templates/decision-record.md @@ -0,0 +1,60 @@ +# Decision Record Template + +Use when the user asks for an exportable decision record, when MULTI-LENS is used, or when a DEEP run produces a consequential verdict. + +--- + +## Template + +```markdown +# Decision Record: [Decision] + +Date: [YYYY-MM-DD] +Decision owner: [owner] +AZIMUTH mode: [FAST / STANDARD / RAPID / DEEP] +Advanced lenses loaded: [none / L-I / Bias Scan / Risk Triage / Multi-Lens / FOOL] + +## Decision +[PROCEED / PROCEED WITH SAFEGUARDS / PILOT FIRST / REDUCE SCOPE / DELAY PENDING EVIDENCE / REJECT / RESIDUAL-RISK-REGISTER] + +## Rationale +[1-3 sentences] + +## Critical Assumptions +| Assumption | Evidence Class | Falsifier | Review Date | +|---|---|---|---| + +## Critical Risks +| Risk | Category | L/I Score | Owner | Leading Indicator | Escalation Trigger | +|---|---|---:|---|---|---| + +## Commitments +| Action | Owner | Due / Review Date | Evidence of Completion | +|---|---|---|---| + +## Alternatives Considered +| Alternative | Why rejected / deferred | Opportunity cost | +|---|---|---| + +## Revisit Conditions +- [condition] +- [condition] + +## Outcome Review +Scheduled review date: [YYYY-MM-DD] +Outcome notes: [blank until review] +``` + +--- + +## Use Rules + +- Do not include raw diagnostic clutter. +- Preserve only decision-changing evidence. +- Every commitment must be owned and dated. + +--- + +## Provenance + +Original AZIMUTH template inspired by lightweight ADR / decision-record practices and decision-toolkit export patterns. diff --git a/templates/export-formats.md b/templates/export-formats.md new file mode 100644 index 0000000..b283c62 --- /dev/null +++ b/templates/export-formats.md @@ -0,0 +1,111 @@ +# Export Formats + +Use when the user wants AZIMUTH output to become an operational artifact in CSV, Jira, GitHub Issues, Obsidian, Notion, or a plain Markdown decision packet. + +--- + +## CSV Risk Register + +```csv +id,risk,category,urgency,likelihood,impact,score,evidence,owner,leading_indicator,review_date,escalation_trigger,status +R1,"[risk]","Tiger","Launch-Blocking",4,5,20,"[evidence]","[owner]","[indicator]","YYYY-MM-DD","[trigger]","open" +``` + +Required fields: + +- `risk` +- `category` +- `evidence` +- `owner` for Launch-Blocking / Fast-Follow / Elephant +- `leading_indicator` +- `review_date` or decision checkpoint +- `escalation_trigger` + +--- + +## Jira / GitHub Issue + +```markdown +## Risk / Finding +[Clear description] + +## Source +AZIMUTH verdict: [verdict] +Category: [Tiger / Paper Tiger / Elephant] +L/I score: [score] +Evidence class: [Strong / Partial / Unsupported / Contradicted] + +## Required Action +[Specific structural action] + +## Acceptance Criteria +- [ ] Evidence gate satisfied: [gate] +- [ ] Leading indicator instrumented: [indicator] +- [ ] Escalation trigger agreed: [trigger] +- [ ] Review date scheduled: [date] + +## Owner +[one accountable person/role] +``` + +--- + +## Obsidian Decision Note + +```markdown +--- +type: decision-record +date: YYYY-MM-DD +azimuth_mode: [mode] +verdict: [verdict] +confidence: [low/medium/high] +status: active +review_date: YYYY-MM-DD +tags: [azimuth, decision, risk] +--- + +# [Decision] + +## Verdict +[verdict + rationale] + +## Critical Risks +- [[R1]] — [risk] + +## Commitments +- [ ] [Action] — owner: [owner] — review: [date] + +## Revisit Conditions +- [condition] +``` + +--- + +## Notion / Table Fields + +Recommended properties: + +| Property | Type | Notes | +|---|---|---| +| Name | Title | Risk or decision name | +| Verdict | Select | AZIMUTH verdict | +| Category | Select | Tiger / Paper Tiger / Elephant | +| L/I Score | Number | 1-25 | +| Evidence Class | Select | Strong / Partial / Unsupported / Contradicted | +| Owner | Person/Text | Single accountable owner | +| Review Date | Date | Next decision checkpoint | +| Leading Indicator | Text | Observable early signal | +| Escalation Trigger | Text | Condition that changes action | +| Status | Select | Open / Accepted / Mitigated / Closed | + +--- + +## Use Discipline + +Export only the top decision-changing risks and commitments. A polished artifact that includes every speculative risk is worse than a shorter register people actually use. + +--- + +## Provenance + +Original AZIMUTH template for production-ready handoffs. Designed to reduce post-analysis formatting work. diff --git a/templates/multi-lens-summary.md b/templates/multi-lens-summary.md new file mode 100644 index 0000000..c9fc82f --- /dev/null +++ b/templates/multi-lens-summary.md @@ -0,0 +1,46 @@ +# Multi-Lens Summary Template + +Use when `references/multi-frameworks.md` is loaded. + +--- + +## Template + +```markdown +## Multi-Lens Summary + +### Core AZIMUTH Verdict +[verdict + one-sentence rationale] + +### Lens 1 — [name] +- Finding: ... +- Decision impact: ... + +### Lens 2 — [name] +- Finding: ... +- Decision impact: ... + +### Lens 3 — [name, optional] +- Finding: ... +- Decision impact: ... + +### Synthesis +- Where lenses agree: ... +- Where lenses conflict: ... +- Final reconciliation: ... +- Register / verdict change: ... +``` + +--- + +## Use Rules + +- Use 2 lenses by default; 3 only in DEEP or user-requested MULTI-LENS. +- Do not let a lens override a launch-blocking operational risk without explaining why. +- If lenses create complexity but no decision change, omit the section. + +--- + +## Provenance + +Original AZIMUTH output template for conditional multi-framework synthesis.