# configuration/strings/architecture.fragment.strings.ts
> 57 lines of code and 4 definitions.
Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-architecture-fragment-strings-ts
Source text: https://banes-lab.com/assets/sources/source.1574fbaf8d9288adb0025ceefa2dc614315c35ead6b7974cb868ccd1c460ed4f.generated.txt
## Definitions
- `ENCODING_DIAGRAM` (lexical_declaration, line 5)
- `PRECEDENCE_DIAGRAM` (lexical_declaration, line 8)
- `ENCODING_SECTION` (lexical_declaration, line 11)
- `ENCODING_SECTIONS` (lexical_declaration, line 61, exported)
## Source
```typescript
import { ENCODING_SECTION_ICON } from "#configuration/icons/methodology.start.icons";
import { ENCODING_SECTION_ID } from "#core/ids/methodology.start.ids";
import type { Section } from "#types/document.types";
const ENCODING_DIAGRAM =
'flowchart TB\n subgraph mechanical["Mechanical rules · what the tree must be"]\n checks["Checks, fixers, validators, generators"]\n end\n subgraph behavioural["Behavioural rules · how the agent is asked to work"]\n policy["One-line rules with stable names"]\n end\n subgraph context["Context architecture · what the agent knows and where"]\n cores["Agnostic cores · ontologies, templates, the standard"]\n adapter["One adapter · binds every slot to this tree"]\n digests["Digests · one concern each, expanding a rule"]\n memory["Memory · one fact per file, reference never authority"]\n end\n tree["The tree"]\n checks -- findings, healed or not --> policy\n policy -- a correction hardens into a rule --> policy\n policy -- a pattern stated twice becomes a check --> checks\n cores -- read through --> adapter\n adapter -- resolved slots --> policy\n digests -- expand --> policy\n memory -. recalled, then verified against .-> tree\n checks -- read and heal --> tree\n policy -- edits --> tree';
const PRECEDENCE_DIAGRAM =
'flowchart TB\n policy["The behaviour policy"]\n contract["The codebase contract"]\n boundary["A member\'s own boundary document"]\n digests["The per-concern digests"]\n canon["The document canon"]\n source["Source files"]\n memory["Memory"]\n tree["The tree on disk"]\n policy --> contract --> boundary --> digests --> canon --> source --> memory\n tree -. wins over every document, and the document is fixed the same turn .-> policy';
const ENCODING_SECTION: Section = {
icon: ENCODING_SECTION_ICON,
id: ENCODING_SECTION_ID,
intro: "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 three encodings. A method that uses only one of the three leaks through the other two, and when two documents disagree, the order shown in precedence decides which one wins.",
subsections: [
{
blocks: [
{
application:
"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.",
boundary:
"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.",
cause: "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.",
decision:
"Each rule is assigned to one of the three forms before it is written down, rather than added wherever it happens to fit.",
failureMode:
"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.",
kind: "lesson",
principle:
"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.",
problem:
"Rules are often written as one long instruction document, which mixes what a check should enforce with what the developer and the model are expected to remember, and the whole document then decays as fast as its weakest part.",
validation:
"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.",
},
{
kind: "text",
text: "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, enforced by checks, fixers, validators and generators through static analysis and fitness functions. Each returns pass or fail, and all of them run in one chain, which is what the gate holds the line 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.",
},
{
kind: "text",
text: "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 describes, so that a correction has a place to land and a citation has something to point to.",
},
{
kind: "text",
text: "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 describes, the naming standard that placement is a grammar describes, and the core templates the grammar page publishes. A single adapter binds them to one project, as the drop-in 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.",
},
{
kind: "text",
text: "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. The core documents stay untouched throughout, because they name nothing specific to this project, and the adapter absorbs whatever changes.",
},
{ caption: "three encodings", kind: "mermaid", text: ENCODING_DIAGRAM },
{ caption: "precedence", kind: "mermaid", text: PRECEDENCE_DIAGRAM },
],
title: "One kind of discipline per home",
},
],
title: "Three encodings",
};
export const ENCODING_SECTIONS: readonly Section[] = [ENCODING_SECTION];
```