> ## Documentation Index > Fetch the complete documentation index at: https://agentconcepts.io/llms.txt > Use this file to discover all available pages before exploring further. # doctrine > An operational rule promoted to a named, addressable artifact: name + triggering condition + protected-against failure + citation address. computer-science military-sciences # 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. ## Structure Internal structure of doctrine: a table of its component slots and the concepts that fill them. ## Relationships Relationship neighborhood of doctrine: a graph of the concepts it connects to and the concepts it is a part of. * [trigger-rule-pair](/concepts/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](/concepts/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](/concepts/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](/concepts/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 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. 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. "never push to main directly" is doctrine; "always create a PR" — similar. "never merge without test coverage" is a doctrine; "write good tests" is not (no trigger, no protected failure). the diagnostic for which CLAUDE.md entries are genuine doctrines vs. boilerplate: does this rule actually change behavior when triggered?