| name | technical-derisking |
| description | Run a bounded, evidence-first Technical De-Risking Compass (TDC) before committing to full development — or at any expensive, hard-to-reverse decision point. Load when a project needs its core premise or architecture tested with the cheapest experiments that can actually distinguish success from failure, BEFORE building the real thing. Triggers — "de-risk this", "is this feasible", "should we build it this way", "prove the architecture", "technical due diligence", "spike / proof of concept / feasibility study", "what could kill this project", "which assumptions are we betting on", "before we commit to <provider/architecture/hardware>". Produces falsifiable hypotheses with GREEN/YELLOW/RED/UNKNOWN verdicts, one thin end-to-end thread, a capability matrix, ADRs, and a risk-ordered roadmap. Domain-agnostic (software, AI/agents, scientific platforms, hardware, materials). |
Technical De-Risking Compass — the operating skill
The shape of a good de-risking program: frame the next irreversible decision → map only the assumptions that can kill the project → design falsifiable experiments that change that decision → build the minimum evidence-producing thread through the real interfaces → classify every result GREEN/YELLOW/RED/UNKNOWN → transfer the evidence into ADRs and a risk-ordered roadmap → stop. Most "proofs of concept" demonstrate a happy path and prove nothing about failure; this skill ends with decision-quality evidence and an explicit go/no-go.
The one governing principle
Do not prove the whole system before building it. Buy only the information needed to justify the next expensive or hard-to-reverse decision. If an experiment cannot change a decision, it is research theater — do not run it. Stop de-risking the moment the remaining uncertainty is ordinary implementation work.
The loop
- Frame the decision (Gate F). Write the one-page framing: objective, current approach + its limit, proposed difference, system boundary, the next irreversible commitment, initial success measures, and the effort/budget ceiling. No experiment starts before the decision being informed is named. Template:
templates/framing.md.
- Map critical uncertainties (Gate M). Decompose into claims that must be true across: mechanism, interface, architecture, environment, dependency, security/safety, operational, performance, scale, cost. Score each 1–5 and rank by Criticality = Consequence × Uncertainty × max(Irreversibility, Reach, Environment gap). Explicitly list what you are accepting without testing, and why. Templates:
templates/assumption.md, templates/risk-register.csv.
- Design discriminating experiments (Gate D). For each top uncertainty, the cheapest test that yields decision-changing evidence. Rank by Experiment value = Criticality × Decision sensitivity × Evidence strength ÷ Effort. Each charter states GREEN/YELLOW/RED thresholds and the decision branch before implementation. A charter without a decision branch is not ready to run. Template:
templates/experiment-charter.md.
- Execute the minimum thread. Build only what the experiment requires. Prefer one thin end-to-end thread through the real critical path (real source, real/representative interfaces, proposed authority boundaries, one success path, one failure path, instrumentation, intended environment at minimum relevant fidelity) over disconnected component demos. Preserve raw evidence, versions, environment, and reproduction steps. Then attack the thread with failure / concurrency / security / environmental / scale conditions.
- Decide explicitly (Gate V). Classify every critical hypothesis with a verdict + confidence. Allowed decisions: proceed / proceed-with-constraints / pivot / continue-focused-research / stop. No "mostly successful" without a precise constraint. Template:
templates/verdict.md.
- Transfer into development. ADRs (status + confidence + reversal cost), capability/readiness matrix, residual-risk register with owners + retirement milestones, supported claims + prohibited claims, and a roadmap ordered by remaining risk — not feature sequence. Template:
templates/final-assessment.md.
The four verdicts (no soft middle)
- GREEN — demonstrated using the intended mechanism in an adequate environment.
- YELLOW — works with a material limitation, experimental dependency, or fidelity gap. Must carry the exact constraint it imposes on the product claim.
- RED — disproven, or needs an unacceptable redesign/dependency. A well-evidenced RED can save more than a GREEN — preserve it so it isn't rediscovered.
- UNKNOWN — unresolved within the timebox, with a named blocker. Not a soft YELLOW.
Decision gates (question · pass · if-failed)
- Gate F — Framing. Is the next irreversible commitment named, with a boundary and an effort ceiling? Fail → stop; you'll de-risk the wrong thing.
- Gate M — Risk selection. Are the investigated assumptions actually project-killing (high criticality), and is the untested set justified? Fail → you're de-risking everything; re-rank and cut.
- Gate D — Discrimination. Does each experiment have a falsifiable threshold and a decision branch written before running? Fail → it's a demo, not an experiment; rewrite or drop.
- Gate T — Thin thread. Does at least one thread touch the real interfaces end-to-end, with a failure path, in the environment the next commitment needs? Fail → component demos can hide the integration risk; build the thread.
- Gate V — Verdict. Is every critical hypothesis GREEN / YELLOW-with-constraint / RED-with-accepted-pivot, with evidence + confidence? Fail → not ready to decide; name the UNKNOWN and its blocker.
- Gate Stop — Transfer. Can the roadmap be ordered with no hidden foundational assumptions, every residual risk owned? Fail → the report changes no decision; fix the transfer.
Proportionality — choose depth deliberately
- Lite (≈2–5 days): known architecture, 1–2 uncertain integrations, cheap to reverse → narrow spikes, one ADR, proceed/pivot.
- Standard (≈2–4 weeks): new multi-component architecture or costly rewrite risk → full assumption+interface map, prioritized experiment portfolio, thin end-to-end thread, failure injection, capability matrix, ADR set.
- Deep (≈4–10+ weeks): unresolved physics/safety/regulation/hardware/high consequence → representative-environment testing, adversarial + independent review, model/test-method validation, production-viability wave.
Reserve ~5–15% of the first committed build effort as an initial heuristic; the real rule is that de-risking cost stays well below the cost of following the most plausible wrong architecture.
Waves (re-enter at each new irreversible commitment)
- Wave A — mechanism: can the central mechanism work at all?
- Wave B — architecture & integration: do the components and boundaries work together?
- Wave C — production viability: can it be trusted under real failure, security, load, recovery?
- Wave D — scale & deployment: does it meet the required economics/manufacturing/fleet behavior?
Run only the wave the next commitment requires. Don't run all four "for certainty."
Agent guardrails (enforce on yourself and any sub-agent)
Attempt to falsify the premise. No claim without evidence. Capture versions + environment. Write pass/fail thresholds before execution. No hidden manual steps. Never substitute a mock for the mechanism under test. Preserve negative + UNKNOWN results. Do not expand into product features not needed for an experiment. When the stakes are high, run an independent reviewer whose job is to invalidate the conclusion, not confirm the demo runs.
Overbuilding smells — stop when you see these
Polishing UI that isn't under test · generalizing before the second concrete case exists · building auth/billing/org/ops that aren't critical risks · optimizing past the next required threshold · refactoring disposable experiment code for elegance · a demo becoming a maintained product with no explicit decision · moving success criteria to justify more work.
Worked example
See templates/fields-example.md for a real Standard-ish TDC wave (the Fields agent-federation project): 17 falsifiable hypotheses, a three-harness thin thread, a clean RED that became a wording constraint (H9), a bounded YELLOW (H7), and a "PROCEED WITH CURRENT ARCHITECTURE" verdict — all evidence-linked.
Reusable master prompt
templates/master-prompt.md is a drop-in starting prompt for a fresh de-risking agent on a new project.
Full essay + canonical version: the Technical De-Risking Compass gist.
