Doctrine
Description
The artifact-shape of an operational rule — named, addressable, and invocable rather than implicit or ad hoc. A doctrine has four structural elements: a name (so it can be cited), a triggering condition (so it knows when to activate), a protected-against failure (the thing it prevents), and a citation address (where the authoritative statement lives). Without all four, a rule is just a preference or a habit; with them, it becomes an institution.
Doctrines are distinguished from individual decisions by their generality and repeatability — they apply whenever the trigger fires, not just in the current case. The most common failure mode is a rule that has the form of a doctrine but is missing its trigger, making it a bare principle rather than an actionable policy. This is why trigger-rule-pair is so closely coupled to doctrine: the trigger is what makes a doctrine load-bearing rather than decorative.
Triggers
User-initiated: User is articulating a rule, policy, or principle — especially when they use “always,” “never,” “when X, do Y,” or “our rule is.” Also when reviewing a document that is meant to govern recurring decisions (style guides, team wikis, architectural decision records).
Agent-initiated: Agent notices the target situation involves a standing rule or policy decision rather than a one-off choice. Candidate inference: “this rule has the shape of a doctrine — does it have a named trigger and a protected failure?” Also surfaced when a rule is being violated or when someone is asking whether a rule applies.
Vocabulary cues: “doctrine,” “policy,” “convention,” “mandate,” “standing rule,” “we always,” “we never,” “the rule is,” “per our convention,” “governing principle.”
Situation-shape signals: The presence of a rule stated without a trigger (“do X”) is an invitation to apply the trigger-rule-pair concept — what condition causes X to activate?
Exclusions
- One-off decisions — a choice made in a specific situation with no expectation of recurrence isn’t a doctrine. Applying the doctrine frame over-formalizes it and adds ceremony without dividend.
- Taste or heuristic — aesthetic preferences (“I prefer short functions”) that don’t carry a protected failure or trigger aren’t doctrines; they’re style. The doctrine frame inflates their status.
- Contested norms — in contexts where the rule is genuinely in dispute, naming it a “doctrine” prematurely forecloses the debate. Better to call it a proposal until it earns consensus.
Relationships
- trigger-rule-pair (creation relationship) — doctrine is the artifact; trigger-rule-pair is the structural criterion that makes a doctrine executable. A bare doctrine without an explicit trigger is incomplete.
- graduation-promotion (creation relationship) — doctrines are often the output of graduation: a pattern that recurred enough to be named and elevated becomes doctrine. The graduation move produces doctrines as its artifact.
- route-as-context (specialization relationship) — route-as-context is a specific doctrine: “path encodes intent.” The doctrine concept is the containing category; route-as-context is a high-confidence instance.
- active-gate-vs-passive-audit (composition relationship) — doctrines often specify how errors are handled: some doctrines are gates (block on violation), some are audit-trails (record and review). The posture choice is load-bearing.
Examples
Military doctrine (e.g. U.S. Army field manuals)
Domain: military-sciences
Doctrine takes its name from military usage: a codified, named body of standing rules — the U.S. Army’s field manuals, for instance — that tells a unit the standard response for a recognized situation, so subordinates can act coherently without re-deriving tactics under fire. Each entry pairs a triggering condition with a prescribed action and the failure it exists to prevent, and lives at a citable address (a manual, a chapter, a paragraph) that can be invoked in training or after-action review. That four-part shape — name, trigger, protected failure, lookup address — is what separates a doctrine from a mere habit or a one-off order.
CLAUDE.md files
Domain: computer-science
project-orientation files that state rules for agent behavior (“always read X before doing Y,” “never propose Z without W”). Each instruction is a doctrine fragment; together they constitute an operational doctrine set for the session.
Git workflow conventions
Domain: computer-science
“never push to main directly” is doctrine; “always create a PR” — similar.
Code-review norms
Domain: computer-science
“never merge without test coverage” is a doctrine; “write good tests” is not (no trigger, no protected failure).
”Load-bearing instruction”
Domain: computer-science
the diagnostic for which CLAUDE.md entries are genuine doctrines vs. boilerplate: does this rule actually change behavior when triggered?