Doctrine: Patterns for building resilient, federated systems
This page is the table of contents for all doctrine guides and annexes. This page collects the principles and patterns I keep coming back to when I design or repair complex systems. Doctrine, in this archive, means field-tested operating patterns. It does not mean final truth.
It’s written for people who work in high-tempo environments, manage portfolios, or carry the weight of decisions that cannot fail quietly.
Use these guides to clarify how you want your system to behave, how you want decisions to be made, and what “good” looks like when the pressure is on.
What you will find here
- Core doctrine guides that explain the main patterns.
- Annexes that zoom in on specific workflows, case studies, and edge conditions.
- Pointers to field notes and services where the doctrine is used in real work.
Want to see how these Doctrine entries connect to Field Notes and supporting cases? View the Doctrine Knowledge Graph.
What to read first
Doctrine is a set of reusable principles for building systems that survive contact with reality. Each guide explains one principle, shows how it works in practice, and connects to related patterns. If you’re new here, start with Federation vs Integration or Two-Lane Architecture.
Federated vs Integrated systems and resilient operations
Why forcing uniformity shrinks participation in complex mission networks
The big map. This guide explains why I use the word โdoctrine,โ how federated systems behave, and how decision altitudes, golden datasets, and portfolio thinking fit together.
Golden datasets and useful interoperability
Why contracts and stewards are essential to interoperability
A practical look at how to put โtruth in one placeโ without pretending everything is perfect. This guide covers golden datasets, data contracts, and how to federate information across partners who move at different speeds.
Decision altitudes for complex systems
Which decisions belong at which level (and how to keep executives out of ticket queues)
A short guide to decision altitudes. It explains which decisions belong at which level, how to keep executives out of ticket queues, and how to give front line teams real freedom without losing control.
What you will find here:
Doctrine Guides & Companions (Gold)
Core principles that answer “What do I believe about how good systems behave under stress?” These are the reusable patterns that show up across missions, tools, and organizations.
A Doctrine Companion is a focused deep dive that hangs off a single doctrine. It clarifies vocabulary, edges, or technical implementation details, without bloating the main doctrine.
Annexes (Gold)
Detailed explainers that zoom in on specific workflows, case studies, and edge conditions. Read these when you’re in the middle of a problem and need concrete moves.
How They Connect
Below you will find every doctrine guide and annex. Use the filters to switch between core doctrine and annexes, or explore everything together.
ANNEX A. Human Contracts
The interpersonal agreements that make federated systems, distributed decisions, and high visibility work possible Technical systems run on code – federated systems run on trust. A Human Contract is the “interpersonal scaffolding” that prevents political…
ANNEX B. Data Contracts
The technical agreements that stabilize interfaces, reduce ambiguity, and enable useful interoperability Doctrine Claim: Without a Data Contract, every system update is a potential outage for your partners. Contracts stop the “silent drift” of schemas…
ANNEX C. Interface Ownership Model
Why every interface needs two owners, one on each side, and why systems fail when ownership is ambiguous Doctrine Claim: Most organizations assign owners to the boxes (systems) but leave the lines (interfaces) ownerless. This…
ANNEX D. Decision Altitudes Model
Why decisions must be made at the right altitude to move fast, stay aligned, and avoid unnecessary friction Doctrine Claim: Decisions have mass. Strategic choices are heavy and belong at the top. Tactical choices are…
ANNEX E. PreventionโContingency Matrix
Why resilient systems require both prevention and contingency, and how the balance determines performance under stress Doctrine Claim: You cannot prevent every failure, and you cannot firefight your way to stability. Resilient systems require two…
ANNEX F. Pattern Library
Reusable architectural, leadership, and workflow patterns that stabilize systems and accelerate mission tempo Doctrine Claim: Systems fail when every problem is treated as unique. High-tempo organizations survive by recognizing patterns: “This is a federation problem,”…
ANNEX G. Leadership Doctrine
The leadership patterns that create high trust, high tempo, low drag environments Doctrine Claim: Leadership is not a personality trait; it is the architecture of human behavior. This doctrine defines the patterns: altitude discipline, clear…
ANNEX H. Architecture Doctrine
The structural principles that shape systems, reduce drag, absorb drift, and create resilience under real conditions Doctrine Claim: Architecture is not a set of diagrams; it is the set of structural decisions that determine how…
ANNEX I. High Visibility Workflows
How to stabilize work that is high profile but not always high mission value This Annex serves as a guide for managing work that has disproportionate political risk but low operational tolerance for error 1….
ANNEX J. System Evolution and Drift Management
ANNEX J. System Evolution and Drift Management How systems change over time, why drift is inevitable, and how to manage evolution without losing coherence 1. Purpose of System Evolution and Drift Management Every real system…
ANNEX K. System and Workflow Profiles (Case Studies)
Anchor examples from mission systems, federal workflows, modernization programs, international coordination, and the authorโs lived domains that illuminate the doctrine Doctrine Claim: Doctrine is abstract until it collides with reality. This Annex defines the specific…
Annex L: The Rosetta Stone for Data Teams: Bridging the Gap Between Technicians and Executives
Data Modeling for Practitioners: Vocabulary Crosswalk from Field Experience to Architecture Terms Doctrine Claim: Whether you are troubleshooting a schema in a secure facility or defining strategic intent in a boardroom, you are governing the…
Doctrine 01 Companion: Choosing Federation or Integration
Federation and integration aren’t architectural preferences or style choices. They’re structural requirements determined by authority (can you compel compliance?) and value distribution (does standardization serve entities as well as local optimization?). Choosing the wrong model…
Doctrine 01 Companion: Federation and Integration as Endpoints, Not Destinations
Throughout this doctrine, I’ve presented federation and integration as distinct approaches. This binary framing is pedagogical, not absolute. Real coordination exists in messy middle, shifting across temporal, spatial, and organizational dimensions.
Doctrine 01: Federation vs Integration in Mission Networks
Use this guide when: deciding between unified platform vs. federated approach
You’ll learn: why federation scales, when integration fails, how to design for diversity, and when integration can be best.
Doctrine 02: Well-Designed Distributed Decisions Increase Speed, Alignment, and Resilience
Why mission systems move faster and survive more when decisions are made at the lowest competent level 1. Centralization Creates Fragility Centralized control feels safe during planning. It appears orderly. Predictable. Controlled. But once an…
Doctrine 03 Companion: Constraints: bidirectional translation: Compression vs Construction
This Doctrine Companion guide presents different ways of thinking and different structures to fit those needs. Constraint 1: Construction Before Compression Some thinkers require time to construct the model before they can accurately compress it…
Doctrine 03 Companion: ITIL 4 Foundation: A Practitioner Crosswalk
Purpose This entry is not a study guide for the ITIL 4 Foundation exam. It is a crosswalk between ITIL 4’s formal vocabulary and twenty years of operational experience solving the same problems ITIL was…
Doctrine 03 Companion: Ledger/Visibility Collapse
How reciprocal relationships appear one-sided when contributions become invisible Ledger/Visibility Collapse is when selective accounting makes reciprocal relationships appear one-sided by making some contributions visible while others become structurally invisible. This is not about one…
Doctrine 03 Companion: The FrameGate Check: Clarifying the Problem Before Commitment
Most downstream failures are frame entry failures, not execution failures. FrameGate enforces five minimal capture tags before commitment: Decision Owner, Objective, Evaluation Mode, Risk Posture, and Time Horizon. If two or more tags are undefined,…
Doctrine 03 Companion: The Interface Void
Doctrine Claim: High-resolution mental models are a dangerous luxury when they have never been tested against a low-resolution reality. The Interface Void is the technical debt of unearned knowledge: it is the gap between a…
Doctrine 03 Companion: The RS-CAT Framework: Converting Raw Recall into Teachable Principle
Doctrine Claim: Knowledge transfer in mission-critical environments is a process of signal extraction, not information dumping. The RS-CAT Framework is the specific methodology used to bypass the “Expert Blind Spot,” the psychological reality where a…
Doctrine 03 Companion. How important conversations get killed at the first correction (The Ackshually Gate)
The “Ackshually” Gate is the moment a conversation gets diverted from the real question to a technically correct but strategically useless correction. It is not necessarily lying. It is not necessarily bad faith. It is…
Doctrine 03: Interfaces Are Where Systems Break, So They Require Stewards, Contracts, and Ownership
Why boundaries fail first and why every interface needs a clear owner on each side Systems rarely fail in the middle. They fail at the edges. In every complex system, the most fragile point is…
Doctrine 04: Useful Interoperability Is the Goal, Not Perfect Interoperability
Why forcing perfect alignment destroys participation and slows down missions Perfect interoperability is a myth. Useful interoperability is a skill. Mission environments are too diverse, too fast, and too asymmetric for perfect alignment. If you…
Doctrine 05: Innovation Emerges at the Edge, but the Center Must Protect It
Why experiments succeed closer to real problems and fail inside central offices Real innovation comes from friction, not conference rooms. Innovation happens where reality is felt. Innovation does not originate in headquarters. It grows at…
Doctrine 06: A Two-Lane System Protects Stability and Enables Evolution
Why mature systems need both a stable lane and an adaptive lane to survive real conditions This guide overlaps with Doctrine 05 (Innovation at the Edge), but it is distinct: Doctrine 05 is about where…
Doctrine 07: Clear Intent Matters More Than Perfect Data
Why missions fail without intent, even when the data are perfect Perfect data never arrives on time If you wait for perfect data, you will make perfect decisions too late. In mission systems, the world…
Doctrine 08: Clear Intent Compresses Ambiguity, Reduces Conflict, and Accelerates Action
Why everything flows faster when people know the purpose, the boundaries, and the desired outcome This doctrine guide is about Focus and Speed. It argues that “Intent” is the ultimate compression algorithm for messy organizations….
Doctrine 09 Companion: Artifacts Over Adjectives
Doctrine Companion to Decision Altitude There is a quiet lie that shows up in a lot of org charts and LinkedIn profiles. We act like skills live in adjectives. These words float near job titles…
Doctrine 09: Decision Drag Erodes Mission Tempo. Architecture Can Reduce It
Why waiting multiplies work and how architectural clarity keeps decisions flowing One decision made early replaces five decisions made late. Decision drag is the hidden tax on every mission environment. Most leaders and engineers see:…
Doctrine 10 Companion: Span of Control and Cross Training Are Load-Bearing Constraints
TLDR (Read This First) Organizations fail when they expect humans to track, decide, and support more than their cognitive limits allow. Most people can reliably manage three to seven direct relationships, decisions, or workstreams. Beyond…
Doctrine 10: Design for Degraded Operations as a Normal Condition
Why systems must perform under partial failure, partial truth, and partial coordination The goal here is to visualize that “Degraded” does not mean “Broken. ” It means “Operating in a different mode.” The world almost…
Doctrine 11 Companion: Agency vs. Outcome
Companion to Numbered Doctrine 11: Preventive and Contingent Action In a Contact Environment, the system always has a vote. Whether you are managing a fire line, a medical crisis, or a crashing server, reality possesses…
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),…
Doctrine 12: Resilience Is an Emergent Property, Not a Feature
Why resilience cannot be bolted on and only appears when the system is aligned at every layer This doctrine argues that resilience is the result of getting all the other patterns right. You cannot โadd…
Doctrine 13: Problem Solving Requires Finding the Real Deviation and the Relevant Change
Why teams fix the wrong thing and how architects identify the signal hidden inside the noise This guide explains why solving a problem is linked to being able to define the problem in the first…
Doctrine 14: Technical Debt Is Often a Leadership Signal, Not Merely a Coding Failure
Why accumulated debt reveals decision environments, not developer shortcomings This Doctrine guide redefines Technical Debt as Institutional Pressure, not (just) bad code. Technical debt is not a mistake. It is a message. When leaders see…
Doctrine 15 Companion: Activity vs. Outcome
Coordination offices measure activity (meetings held, attendance rates, documents produced) while decision latency increases and stakeholder satisfaction decreases. The coordination infrastructure looks busy but doesn’t improve coordination outcomes.
Doctrine 15: Architecture Must Accelerate Teams, Not Bottleneck Them
This guide is a argument against most โIvory Towerโ architecture. It argues that if architecture doesnโt make the team faster, itโs useless.
Doctrine 16: Portfolio Thinking Ensures Effort Aligns With What Actually Matters
Why doing the work right is meaningless if you are not doing the right work Doing the work right matters only if you are Doing the Right Work. This guide argues that perfect execution on…
Doctrine 17: Architects Translate Strategy Into Engineering and Engineering Into Strategy
Why missions fail when strategy and engineering do not speak the same language This guide established a framework for the Architect as a “Translator” between the boardroom and the server room. Strategy talks in outcomes….
Doctrine 18 Companion: The Five Levels of Commitment Durability
When a system fails or an interface breaks, the natural institutional response is to produce an acknowledgment of the problem. For practitioners operating in federated environments, this creates a dangerous illusion of closure. A system…
Doctrine 18: Commitment Outperforms Compliance in High Trust, High Tempo Environments
Why teams built on commitment move faster, adapt better, and deliver more value than teams built on rule following This guide moves beyond the “rules vs. freedom” debate and shows why Compliance and Commitment are…
Doctrine 19: Supervision, Management, and Leadership Are Three Different Jobs. Confusing Them Breaks Systems
Why systems collapse when these roles blur, and why high-performing mission environments keep them distinct This guide distinguishes the Three Altitudes of people management. When you confuse supervision, management, and leadership, you create drag, conflict,…
Doctrine 20: Golden Datasets: Putting Truth In One Place Without Pretending Everything Is Perfect
This guide defines “Truth as a Product.” It argues that data must be owned, scoped, and contracted, not just stored. Every complex system eventually trips over the same problem. Different teams build different tools. Each…
Doctrine 21 Companion: Claims, Roles, and Entitlements in Microsoft 365
Companion to: Doctrine 21: Zero Trust Is A Trust Model, Not A Card โTypeโ This page is a Doctrine Companion. It hangs off Doctrine 21 and gives you a shared vocabulary for identity and access…
Doctrine 21: Zero Trust Is A Trust Model, Not A Card “Type”
Doctrine Claim:PKI proves who you are. Zero trust constantly questions what you should be allowed to do. It allocates risk explicitly through policy, context, and least privilege. Core statement Zero trust is not a new…
Doctrine 22: When “It Depends” Is the Right Answer: How to Think in Probabilities Under Uncertainty
Doctrine Claim:“It depends” is not a cop-out; it is the only honest answer to complex problems. But to be useful, you must follow it with what it depends on, the base rates of success, and…
Doctrine 23: Loop Closure as Load-Bearing System Infrastructure
Doctrine claim: Loop closure is not about politeness; it is about physics. In any system (digital or human) an open loop consumes resources (memory, attention, bandwidth). This guide defines Acknowledgment as Infrastructure: the specific protocols…
Doctrine 24 Companion: The Conflict Buffer
When Coordination Offices Absorb Unresolved Tensions Rather Than Clarify Ownership Companion to: Educational Diagnostic #5 (The Conflict Buffer), Doctrine 24: Stewardship Places the Burden on the Steward, and Doctrine 03: Interfaces Are Where Systems Break….
Doctrine 24 Companion: The Eight Capture Mechanisms
Coordination offices require structural independence to coordinate neutrally across stakeholders. But multiple dependencies on one dominant stakeholder create compound capture that makes neutral coordination impossible.
Doctrine 24: Stewardship Places the Primary Burden on the Steward
Organizations optimize for efficiency. Leaders optimize for performance. Stewards optimize for preservation of mission-critical capability.
Doctrine vs annexes: how to use them
Doctrine Guides
These are the core principles. They answer questions like:
โWhat do I believe about how good systems behave under stress?โ
โWhat stays constant across missions, tools, and organizations?โ
Doctrine guides are what you read when you want to reset your bearings or explain your view of the system to someone else.
Annexes
Annexes zoom in on specific patterns, workflows, or environments.
- They often show how a principle shows up in the real world.
- Many link to field notes, case studies, or service offers.
Annexes are what you read when you are in the middle of a problem and need concrete moves, examples, and tradeoffs.
How doctrine connects to the rest of this site
Doctrine on its own is just words. It matters when it shapes real work.
If you want to see how these patterns behave in practice, or how I apply them with other teams, here is where to go next.
Field Notes (green band)
Field notes are stories from real deployments and projects spanning multiple disciplines and time periods. They show what happens when doctrine collides with reality, including when things go sideways.
Read them if you want lived examples, not just clean diagrams.
Services (blue band)
Services are the ways I work directly with organizations to apply this doctrine. That can mean clarifying decision altitudes, building a portfolio view, or supporting high consequence operations.
Use them when you want help shaping your own systems, not just ideas.
Doctrine vs annexes: how to use them
What This Doctrine Is (And Isn’t)
This is not a textbook or a set of generic leadership quotes.
This doctrine was earned in:
- Disaster deployments after Katrina
- National infrastructure protection work
- Wildfire camps under NWCG and ICS
- Federal workflows that touched law, policy, and the public
- Coalition environments where sovereignty mattered
- Systems where failure had real consequences
It’s a philosophy of operations for people who build systems in high-tempo, high-consequence environments where incomplete information is normal and perfect data never arrives on time.
Common Problems Doctrine Addresses
In almost every environment I care about, the same problems keep showing up:
- Pictures that are incomplete but presented as perfect
- Interfaces between systems that fail first and fail silently
- Central platforms trying to snap onto federated realities that never consented
- Critical datasets with no visible stewards
- Leaders pulled into problems that belong at lower altitudes
- Operators waiting too long for decisions they should own
This doctrine gives you tools for those problems: clear principles, reusable patterns, and concrete ways to pre-commit to degraded modes and real safety gates.
Doctrine Diagnostic (Quick Scan)
Each doctrine contains a diagnostic to show you how things are really working (or not). Use these prompts against any system, team, or workflow, for example:
- Where is drift accumulating with no one naming it?
- Which interfaces have no clear upstream and downstream owner?
- Where are decisions made at the wrong altitude?
- Where is fallback missing in high-visibility workflows?
- Where is federation needed, but integration is being forced?
The cards above are for quick browsing. The lists below give you a plain text index of every doctrine guide and annex, with one line on what each one is about.
If you get lost in the details, just head back to the โWhat to read firstโ section at the top of this page.
Purpose and Use (from a personal perspective)
I built this doctrine because I kept running into the same problems in different places.
At first, they looked unrelated. Disaster response. Wildland fire. Federal workflows. Enterprise systems. Coalition coordination. Science governance. Different rooms, different vocabulary, different uniforms, different acronyms.
But underneath, the same patterns kept showing up.
Interfaces failed before the systems did. Decisions got made at the wrong altitude. People tried to force integration where federation was the only workable option. Critical knowledge lived in one personโs head. Leaders asked for visibility but did not always create ownership. Teams kept doing the work right without stopping to ask whether they were doing the right work.
This doctrine is my attempt to keep those patterns from disappearing back into isolated stories.
It is not a textbook. It is not a universal theory. It is not a claim that every organization should use my language.
It is a working map.
I use it to remember what I have learned, test whether a new situation fits an old pattern, and explain complex coordination problems without starting from zero every time. Other people can use it the same way: as a reference shelf, a diagnostic aid, or a starting point for better questions.
- The doctrine entries are the principles.
- The annexes and companions are the deeper dives.
- The field notes are where the principles hit reality.
Some of this came from successful work. Some of it came from frustration. Some of it came from watching good people struggle inside systems that made coordination harder than it needed to be.
That matters to me because operational knowledge that is not transferred usually dies with the operator.
This archive is one way of pushing back against that. It keeps the patterns visible, inspectable, and useful for the next person who has to inherit the system, fix the interface, explain the tradeoff, or make the decision under imperfect conditions.