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.
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.
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: Federation vs Integration in Mission Networks
Why architects must preserve autonomy while achieving alignment This guide explains why federation over full integration keeps mission networks flexible, politically viable, and fast to adapt without forcing every partner into one rigid stack. Use…
Doctrine 02: Distributed Decisions Increase Alignment, Speed, 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: 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: 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 Must Live at the Edge, Not in the Center
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 Is the Enemy of Mission Tempo. Architecture Is the Remedy
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: Degraded Operations Are the Normal Mode, Not the Exception
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 liked to being able to define the problem in the first…
Doctrine 14: Technical Debt Is a Leadership Signal, Not 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: Architecture Must Accelerate Teams, Not Bottleneck Them
Why architecture succeeds only when it makes teams faster, clearer, and more capable 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: 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: Stewardship Places the Burden on the Steward, Not the Parties
Stewardship vs. Optimization: Preserving What Cannot Be Allowed to Fail Why mission-critical systems require stewards, not just managers Organizations optimize for efficiency. Leaders optimize for performance. Stewards optimize for preservation of mission-critical capability. The distinction…
Field Report: College Financing and the 5-Year Home Runway
A First-Principles Analysis of Landed Costs, Cash Flow, and Optimal Pathways Claim: “The advice that worked for your parents’ generation is now structurally impossible. Most parents don’t know this yet. Most students find out too…
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)
This doctrine is a living map of my thinking as a mission architect, strategist, and leader.
It captures the principles, patterns, and lived experiences that guide the way I design systems, make decisions, support teams, and navigate complex environments.
It is not a textbook or a set of generic leadership quotes.
It is a philosophy of operations.
It reflects what I have learned during high-tempo mission work, federated environments, degraded conditions, partner onboarding, and the real human dynamics that shape decision-making.
This document serves two purposes:
- Internal compass.
It gives me a single, coherent framework to return to when I need clarity or when decisions become noisy. - External structure.
It allows me to create expansion pages, video segments, onboarding materials, or training modules for others.
Each principle in this master list links to a separate expansion where I develop the idea in full depth.
The doctrine is the index.
The expansion pages are the chapters.
The video scripts, essays, and field notes are the expressions.
This document is designed to evolve over time.
It is the spine of my operating system as a leader and architect.