--- title: "Doctrine 11: Preventive Action and Contingent Action Must Both Be Designed Intentionally" description: "# *Why planning for the expected and structuring for the unexpected creates systems that survive real conditions* This Doctrine guide is the manifesto for **Defense in Depth**. It argues that you cannot stop all failures (Prevention), so you must also…" url: "https://anthonyveltri.com/guide/preventive-action-and-contingent-action-must-both-be-designed-intentionally/" updated: "2026-02-22" category: "Decision Tempo & Governance" tags: - contracts - governance - interfaces - interoperability - visibility --- # Doctrine 11: Preventive Action and Contingent Action Must Both Be Designed Intentionally # *Why planning for the expected and structuring for the unexpected creates systems that survive real conditions* This Doctrine guide is the manifesto for **Defense in Depth**. It argues that you cannot stop all failures (Prevention), so you must also plan for survival (Contingency). This page is a **Doctrine Guide**. It shows how to apply one principle from the [Doctrine](/doctrine/) in real systems and real constraints. Use it as a reference when you are making decisions, designing workflows, or repairing things that broke under pressure. --- # **A system built only for prevention will fail under surprise. A system built only for contingency will drown in chaos.** [![Infographic compares firefighters’ reactive crisis response to fire marshals’ preventive measures like inspections, drills, and maintenance. Graphs show frequent crises with firefighting versus sustained system stability with fire prevention.](https://anthonyveltri.com/wp-content/uploads/2025/12/generation-firefighter-vs-fire-marshall-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/generation-firefighter-vs-fire-marshall.jpg) Two Types of Defense. The Fire Marshal represents Prevention (Inspections, Codes). The Firefighter represents Contingency (Response). You cannot choose one; you need both. Most organizations fall into one of two traps: **Trap one: They optimize everything for prevention.** This creates brittle systems that collapse under stress. **Trap two: They rely entirely on contingency.** This creates reactive chaos and waste. Resilient systems blend both: - preventive scaffolding that blocks avoidable failures - contingent scaffolding that handles unavoidable ones You cannot choose one. You must design for both. --- # **Lived Example: The ingest pipeline that survived the partner outage** During an activation: - a major partner feed died - another partner feed drifted by four hours - timestamps became inconsistent - geometry changed without notice Prevention alone would have failed because: - no prevention can stop partners from failing Contingency alone would have failed because: - without preventive scaffolding, fallback behavior would have been chaotic Because we had both: - preventive alignment kept errors isolated - contingent fallback filled gaps - cached layers preserved situational awareness - annotations explained uncertainty - analysts continued making correct decisions Prevention reduced avoidable chaos. Contingency absorbed unavoidable chaos. The system survived because both layers were intentional. --- # **Business Terms: Prevention and contingency serve different purposes** [![A diagram contrasts "Gates" (non-negotiable survival requirements, like food and water) with "Guardrails" (adaptive strategic guidance, like seasonal animal needs), both leading to successful stewardship of critical systems.](https://anthonyveltri.com/wp-content/uploads/2025/12/generation-gates-guardrails-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/generation-gates-guardrails.jpg) Gates vs. Guardrails. Prevention acts as a Gate (Binary, Stop/Go). Contingency acts as a Guardrail (Keeps you on the road when you drift). A resilient system uses Gates for critical safety and Guardrails for variance. **Preventive actions** reduce error probability by: - clarifying intent - defining contracts - setting boundaries - stabilizing interfaces - reducing ambiguity - improving alignment - removing confusion - designing constraints **Contingent actions** reduce error impact by: - defining fallback behavior - preserving partial truth - isolating failures - enabling local correction - tolerating drift - absorbing outliers - providing escape hatches Prevention avoids unnecessary problems. Contingency handles unavoidable problems. Without prevention: Teams drown in noise. Without contingency: Teams fail under surprise. --- # **System Terms: Prevention and contingency as architectural patterns** [![A diagram showing a "Normal lane" for routine workflows with requests, processing, and output, and a "Contingency lane" for stress conditions with fallback actions, alternate routes, and degraded mode.](https://anthonyveltri.com/wp-content/uploads/2025/12/contingent-lanes-01-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/contingent-lanes-01.jpg) Degraded Mode is a Lane, Not a Crash. A healthy architecture has a specific "Contingency Lane" (Orange) designed for when the "Normal Lane" (Blue) is blocked. Triggers move you between them safely. Do not mix your crisis response with your normal operations. Build a specific "Contingency Lane" (Orange) that activates when the "Normal Lane" (Blue) is blocked. Preventive architecture includes: - invariants - low coupling - clear interfaces - stable lanes - known constraints - schema contracts - versioning plans - explicit decision altitudes - intent articulation Contingent architecture includes: - fallback modes - tolerant ingest - degraded operations - caching - last known good state - asynchronous updates - partial rendering - local autonomy A balanced architecture uses both. --- # **Why Prevention Alone Fails** ## Business perspective Prevention alone: - assumes compliance - assumes stability - assumes predictability - assumes partner maturity - assumes all conditions can be controlled But real missions: - involve diversity - involve drift - involve failure - involve political constraints - involve degraded conditions A prevention only approach collapses under real variation. ## System perspective Prevention alone: - over couples the system - creates global brittleness - requires synchronized correctness - magnifies partner failures - removes local flexibility - makes every deviation catastrophic Preventive systems without contingent scaffolding are doomed. --- # **Why Contingency Alone Fails** [![A flowchart with five steps: Name the risk, Define the contingent action, Choose mileposts, Define triggers and authority, and Rehearse and review. A green note at the bottom says to check off a contingent action only when all steps are complete.](https://anthonyveltri.com/wp-content/uploads/2025/12/contingent-action-workflow-02-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/contingent-action-workflow-02.jpg) Contingency is Design, Not Improv. A valid contingency plan has 5 parts: Risk Name, Action, Mileposts, Triggers, and Rehearsal. If you skip steps, it's not a plan- it's a wish. This checklist prevents the practitioner from thinking "Contingency = Winging It." ## Business perspective Contingency without prevention: - turns every day into firefighting - normalizes reactivity - overloads teams - causes misalignment - increases political heat - increases fatigue - hides structural flaws Contingency without prevention becomes chaos. ## System perspective Contingency alone: - increases entropy - encourages inconsistent behavior - breaks alignment - makes drift unmanageable - causes unpredictable outcomes - undermines trust - increases cognitive load Contingent systems without preventive structure deteriorate rapidly. --- # **The Prevention–Contingency Matrix (You Must Include This)** This becomes a powerful visual and conceptual tool for your doctrine. ### **1. Strong prevention, strong contingency** Best case. Systems are resilient and stable. ### **2. Strong prevention, weak contingency** Rigid. Fails under surprise. ### **3. Weak prevention, strong contingency** Chaotic. Survives but at high cost. ### **4. Weak prevention, weak contingency** Catastrophic. System collapses under minor stress. You design for box one. --- # **Business Example: The team that prevented dozens of failures through clarity** A cross agency team once struggled with constant emergencies. Every week felt like a crisis. When we introduced preventive clarity: - defined invariants - clarified intent - defined boundaries - set expectations - created simple contracts Emergencies dropped dramatically. Then we introduced contingent scaffolding: - fallback behavior - degraded mode behavior - tolerant ingest - cached layers Crises no longer derailed operations. Prevention reduced the number of crises. Contingency reduced the impact of the remaining ones. --- # **System Example: iCAV succeeded because it used both layers** [![A comparison chart shows “Ready when needed” with checked fire extinguisher versus “Looks ready, is not” with a broken extinguisher box. It highlights the importance of regular checks and documentation for emergency readiness.](https://anthonyveltri.com/wp-content/uploads/2025/12/contingency-vs-theater-04-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/contingency-vs-theater-04.jpg) Real vs. Fake Contingency. If you have a plan but no triggers or rehearsals, you have Theater (The Binder). Real contingency looks like a maintained fire extinguisher. iCAV’s preventive design: - stable ingest patterns - clear schemas - known connectors - predictable behavior - interface boundaries iCAV’s contingent design: - caching - degraded mode - tolerant parsing - fallback logic - asynchronous ingest - partial rendering This combination made iCAV reliable under chaos, not despite chaos. --- # **Architect-Level Principle** **As an architect, I design both preventive and contingent scaffolding. Prevention avoids the avoidable. Contingency absorbs the unavoidable. Resilience requires both.** --- # **Twenty-Second Takeaway:** “Mission systems need preventive clarity and contingent fallback. Prevention avoids avoidable problems. Contingency absorbs unavoidable ones. I design both so the system works during normal conditions and during surprise.” --- # **Cross Links to Other Principles** This principle integrates deeply with: - Degraded operations - Emergent resilience - Federation - Useful interoperability - Distributed decisions - Clear intent - Architecture accelerates - Decision drag - Portfolio thinking Prevention and contingency are the backbone of resilient architecture. --- # ****Doctrine Diagnostic - For Reflection:**** Ask yourself: Does your system prevent avoidable problems? Does it survive unavoidable ones? If the answer to either is no, your system is incomplete. Design both layers now. ### Narrated Video Walkthrough [Gumlet video player](https://play.gumlet.io/embed/699b696857a7b7f9b0507f26?background=false&autoplay=false&loop=false&disable_player_controls=false) Audio narration available for this document | Browse full [library](https://anthonyveltri.com/audio/) ### Field notes and examples - [Field Note: Defining “Operator”](https://anthonyveltri.com/field-note-defining-operator/) - [Field Notes – The Pre-Shoot Ritual: How To Lower Friction For High-Stakes Video](https://anthonyveltri.com/field-notes-creating-a-safe-beginner-space-on-camera/) - [Gates That Matter: Task Books, Checkrides And Real Safety](https://anthonyveltri.com/gates-that-matter-task-books-checkrides-and-real-safety/) Last Updated on February 22, 2026 ### Related Posts [![A black pen drawing of two rustic barn-like buildings sits on lined paper, with a pen resting at the edge and a brown, crumpled background visible behind the sheet.](https://anthonyveltri.com/wp-content/uploads/2025/12/home-drawing-169.png) #### Field Note: The 1790 Farmhouse and What It Taught Me About Stewardship](https://anthonyveltri.com/field-note-the-1790-farmhouse-and-what-it-taught-me-about-stewardship/) [![A graphic with the title "ANNEX K System and Workflow Profiles" in bold text on a dark overlay, set against a background of abstract blue and black circuit and network diagrams.](https://anthonyveltri.com/wp-content/uploads/2025/11/annex-k-system-and-workflow-profiles.jpg) #### ANNEX K. System and Workflow Profiles (Case Studies)](https://anthonyveltri.com/guide/annex-k-system-and-workflow-profiles-case-studies/) [![A diagram shows a translucent seated person labeled "Previous State: Unstructured Memory," a backpack labeled "Operational Assets: Field Repository," and five labeled cubes connected by arrows, representing stages of knowledge processing and organization.](https://anthonyveltri.com/wp-content/uploads/2025/12/the-backpack-featured-image-finally.jpeg) #### Field Note: Sorting the 20-Year Backpack](https://anthonyveltri.com/field-note-sorting-the-20-year-backpack/) [![A drawing of a machine.](https://anthonyveltri.com/wp-content/uploads/2026/02/who-are-you-to-speak-the-kings-coin-featured.jpeg) #### Who Are You to Speak? How Cultural Gatekeeping Silences Federal Expertise (Even When Legally Permitted)](https://anthonyveltri.com/who-are-you-to-speak-how-cultural-gatekeeping-silences-federal-expertise-even-when-legally-permitted/) [![A digital slide with a beige circuit-pattern background. A black box contains bold white text: "FrameGATE check for Pre-Commitment Interface Integrity." In the top right, a smaller black box reads, "Doctrine 03 Companion.](https://anthonyveltri.com/wp-content/uploads/2026/01/framegate-doctrine-03-companion.jpg) #### Doctrine 03 Companion: The FrameGate Check: Clarifying the Problem Before Commitment](https://anthonyveltri.com/guide/doctrine-03-companion-the-framegate-check-for-pre-commitment-interface-integrity/) [![A graphic with an abstract, circuit-like pattern in orange and beige tones. A dark box contains the text “ITIL 4 Foundation: A Practitioner Crosswalk.” In the top right, a gray label reads “Doctrine 03 Companion.”.](https://anthonyveltri.com/wp-content/uploads/2026/03/Doctrine-03-Companion-ITIL-4-Foundation-A-Practitioner-Crosswalk.jpg) #### Doctrine 03 Companion: ITIL 4 Foundation: A Practitioner Crosswalk](https://anthonyveltri.com/guide/doctrine-03-companion-itil-4-foundation-a-practitioner-crosswalk/)