Encyclopedia


D

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...

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 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 creates predictable coordination failures regardless of implementation quality.

Doctrine 24 Companion: The Conflict Buffer

When Coordination Offices Absorb Unresolved Tensions Rather Than Clarify Ownership Companion to: Educational Diagnostic #5 (The...

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 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 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 party being ungrateful or exploitative (though it can become that). This is about which items appear on the ledger and which items disappear into baseline.

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 a conversational choke point that reliably prevents people from reaching the higher-resolution model they actually need. It shows up everywhere: economics, medicine, policy, risk, and governance.

Doctrine 03 Companion: The FrameGate Check for Pre-Commitment Interface Integrity

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, the only valid action is frame clarification. This prevents helpful people from getting trapped in obligations they never consented to, and it creates instrumented action that RS-CAT can extract patterns from. FrameGate doesn't slow action. It prevents misaligned action

Doctrine 24: Stewardship Places the Burden on the Steward, Not the Parties

Organizations optimize for efficiency. Leaders optimize for performance. Stewards optimize for preservation of mission-critical capability.

Doctrine 09 Companion: Artifacts Over Adjectives

Doctrine Companion to Decision Altitude There is a quiet lie that shows up in a lot...

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...

Doctrine 03 Companion: The Interface Void

Doctrine Claim: High-resolution mental models are a dangerous luxury when they have never been tested...

Doctrine 03 Companion: Constraints: bidirectional translation: Compression vs Construction

This Doctrine Companion guide presents different ways of thinking and different structures to fit those...

Doctrine 11 Companion: Agency vs. Outcome

Companion to Numbered Doctrine 11: Preventive and Contingent Action In a Contact Environment, the system always...

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...

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...

Doctrine 23: Loop Closure as Load-Bearing System Infrastructure

Doctrine claim: Loop closure is not about politeness; it is about physics. In any system...

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...

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...

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,...

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...

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...

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...

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 02: Distributed Decisions Increase Alignment, Speed, and Resilience

Why mission systems move faster and survive more when decisions are made at the lowest...

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...

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...

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...

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...

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...

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 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...

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...

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...

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...

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...

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...

Doctrine 07: Clear Intent Matters More Than Perfect Data

Why missions fail without intent, even when the data are perfect This Doctrine guide is the...

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.