# Three encodings

> The rules of the method are written down in three different forms, and each form holds a different kind of rule.

Page: Methodology · Start
Canonical: https://banes-lab.com/disciplined-methodology#three-encodings

This section is stop 6 of 102 in the learning route. Previous: [05 - Resolving a message](https://banes-lab.com/disciplined-methodology/start/resolving-a-message.md). Next: [07 - Where a rule lives](https://banes-lab.com/disciplined-methodology/start/from-chat-to-tree.md). It builds on [02 - Who does what](https://banes-lab.com/disciplined-methodology/start/who-does-what.md).

The rules of the method are written down in three different forms, and each form holds a different kind of rule. Mechanical rules are enforced by checks, behavioural rules tell the model how to work, and the context architecture decides what the model is given to read. The three feed into each other, as shown in [F1·a three encodings](https://banes-lab.com/disciplined-methodology#three-encodings-panel-a). A method that uses only one of the three leaks through the other two, and when two documents disagree, the order shown in [F1·b precedence](https://banes-lab.com/disciplined-methodology#three-encodings-panel-b) decides which one wins.

### One kind of discipline per home

Rules are often written as one long instruction document, which mixes what a check should enforce with what [the developer and the model](https://banes-lab.com/disciplined-methodology/collaborate/the-human-and-the-ai.md) are expected to remember, and the whole document then decays as fast as its weakest part. A rule about the tree is written into the behaviour policy, the model may keep to it for a session, and the tree drifts anyway, because nothing outside the conversation reads that sentence. A rule written where no check reads it is held only by memory, and a rule written in two places becomes two rules that drift apart.

For this reason I keep each kind of rule in its own form: mechanical rules, behavioural rules and context architecture each hold one kind, and all three defer to the tree. Each rule is assigned to one of the three forms before it is written down, rather than added wherever it happens to fit. In practice, a rule about the tree goes into a check. A rule about how the model should work goes into the behaviour policy, as one line with a stable name. What the model needs to know goes into the context architecture, arranged so that the general part carries over to other projects and everything specific to this project sits in one file. A fact lives in exactly one of the three places, and the other two point to it.

To check this, take any rule and name the place it lives. A rule you cannot place in one of the three is either two rules or a rule that nothing enforces. The split follows what a rule applies to, never how important it feels. A behavioural rule whose effect can be seen in an artifact is really a mechanical rule written as prose, and moving it into a check is progress, not a demotion.

Mechanical rules are the ones a check can decide from the tree alone: where a file may live, what a name may say, which imports cross a boundary, whether a fact is declared twice and whether a document's references resolve. They are [policy as code](https://banes-lab.com/records/arch/policy-as-code.md), enforced by checks, fixers, validators and generators through [static analysis](https://banes-lab.com/records/arch/static-analysis.md) and [fitness functions](https://banes-lab.com/records/arch/fitness-functions.md). Each returns pass or fail, and all of them run in [one chain](https://banes-lab.com/disciplined-methodology/ship/one-chain.md), which is what [the gate holds the line](https://banes-lab.com/disciplined-methodology/build/the-gate-holds-the-line.md) describes. The developer has no part in this form at all, and that is intended: a mechanical rule that needs a developer to apply it is a behavioural rule disguised as a check.

Behavioural rules cover how the model is asked to work where no artifact can show whether it did: that it reads a file before saying what the file contains, that it asks a question before the work that depends on the answer rather than after, and that it never runs a step whose output it will not read in full. Each is one line with a stable name, in the shape [rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md) describes, so that a correction has a place to land and a citation has something to point to.

Context architecture is how the other two forms reach the model in the same way every session. Its core documents name no project: an ontology of readings, a canon of principles as [principles are typed](https://banes-lab.com/software-architecture/principles/principles-are-typed.md) describes, the naming standard that [placement is a grammar](https://banes-lab.com/disciplined-methodology/build/placement-is-a-grammar.md) describes, and the [core templates](https://banes-lab.com/pag/templates/templates-core.md) the grammar page publishes. A single adapter binds them to one project, as [the drop-in](https://banes-lab.com/disciplined-methodology/start/onboarding.md) explains. Digests expand one concern each where a rule needs more room. Memory holds one fact per file and serves as reference rather than authority, so a remembered fact is checked against the tree before anything is done with it. An order of precedence runs through all of it, and the tree outranks every document: a document that disagrees with what is on disk is wrong, and it is corrected in the same turn the disagreement is found.

The feedback between the three forms is what makes them work as one system rather than three separate ones. A check raises a finding, and the model is asked to repair it within the behavioural rules. A correction I give is written down as a behavioural rule and a memory in the same turn. When a behavioural rule has to be stated twice for the same kind of problem, that is the signal to build the check that makes it mechanical; the prose then becomes a pointer, and the rule has a [single source of truth](https://banes-lab.com/records/arch/single-source-of-truth.md). The core documents stay untouched throughout, because they name nothing specific to this project, and the adapter absorbs whatever changes.

F1·a three encodings

```mermaid
flowchart TB
subgraph mechanical["Mechanical rules · what the tree must be"]
checks["Checks, fixers, validators, generators"]
end
subgraph behavioural["Behavioural rules · how the agent is asked to work"]
policy["One-line rules with stable names"]
end
subgraph context["Context architecture · what the agent knows and where"]
cores["Agnostic cores · ontologies, templates, the standard"]
adapter["One adapter · binds every slot to this tree"]
digests["Digests · one concern each, expanding a rule"]
memory["Memory · one fact per file, reference never authority"]
end
tree["The tree"]
checks -- findings, healed or not --> policy
policy -- a correction hardens into a rule --> policy
policy -- a pattern stated twice becomes a check --> checks
cores -- read through --> adapter
adapter -- resolved slots --> policy
digests -- expand --> policy
memory -. recalled, then verified against .-> tree
checks -- read and heal --> tree
policy -- edits --> tree
```

F1·b precedence

```mermaid
flowchart TB
policy["The behaviour policy"]
contract["The codebase contract"]
boundary["A member's own boundary document"]
digests["The per-concern digests"]
canon["The document canon"]
source["Source files"]
memory["Memory"]
tree["The tree on disk"]
policy --> contract --> boundary --> digests --> canon --> source --> memory
tree -. wins over every document, and the document is fixed the same turn .-> policy
```

## Links to

- [The developer and the model](https://banes-lab.com/disciplined-methodology/collaborate/the-human-and-the-ai.md)
- [Policy as Code](https://banes-lab.com/records/arch/policy-as-code.md)
- [Static Analysis](https://banes-lab.com/records/arch/static-analysis.md)
- [Fitness Functions](https://banes-lab.com/records/arch/fitness-functions.md)
- [One chain](https://banes-lab.com/disciplined-methodology/ship/one-chain.md)
- [The gate holds the line](https://banes-lab.com/disciplined-methodology/build/the-gate-holds-the-line.md)
- [Rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md)
- [Principles are typed](https://banes-lab.com/software-architecture/principles/principles-are-typed.md)
- [Placement is a grammar](https://banes-lab.com/disciplined-methodology/build/placement-is-a-grammar.md)
- [Core templates](https://banes-lab.com/pag/templates/templates-core.md)
- [The drop-in](https://banes-lab.com/disciplined-methodology/start/onboarding.md)
- [Single Source of Truth](https://banes-lab.com/records/arch/single-source-of-truth.md)

## Linked from

- [The behaviour document](https://banes-lab.com/disciplined-methodology/start/the-behaviour-document.md)
- [The developer and the model](https://banes-lab.com/disciplined-methodology/collaborate/the-human-and-the-ai.md)