computer-science

​

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 (CLAUDE.md files, team wikis, architectural decision records). Agent-initiated: Engine 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

​

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