# configuration/strings/stance.strings.ts
> 135 lines of code and 7 definitions.
Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-stance-strings-ts
Source text: https://banes-lab.com/assets/sources/source.2da6942691d86e2124e860ae6ab6dce9304c78fd4f6d741ba11a0463f3d6f6ef.generated.txt
## Definitions
- `CLAIM_DIAGRAM` (lexical_declaration, line 10)
- `SPREAD_DIAGRAM` (lexical_declaration, line 13)
- `READING_DIAGRAM` (lexical_declaration, line 16)
- `STANCE_SECTION` (lexical_declaration, line 19)
- `ADVERSARIAL_SECTION` (lexical_declaration, line 67)
- `READING_SECTION` (lexical_declaration, line 97)
- `STANCE_SECTIONS` (lexical_declaration, line 142, exported)
## Source
```typescript
import {
ADVERSARIAL_SECTION_ICON,
READING_SECTION_ICON,
STANCE_SECTION_ICON,
} from "#configuration/icons/methodology.start.icons";
import { ADVERSARIAL_SECTION_ID, READING_SECTION_ID, STANCE_SECTION_ID } from "#core/ids/methodology.start.ids";
import { nodeLink as node, stageLink as stage } from "#domain/converters/link.converter";
import type { Section } from "#types/document.types";
const CLAIM_DIAGRAM =
'flowchart TB\n claim["A claim about the tree"]\n read{"Read in this session?"}\n lead["A lead · follow it to the file"]\n evidence["Evidence · the path and the line"]\n act["Act on it"]\n claim --> read\n read -- no --> lead\n read -- yes --> evidence\n lead --> read\n evidence --> act';
const SPREAD_DIAGRAM =
'flowchart TB\n claim["A claim is written"]\n agree1["A peer agrees · one read of the sentence"]\n agree2["A second peer agrees · one read of the agreement"]\n plan["It becomes a plan row"]\n open["A reader opens the file"]\n refuted["Refuted · the file moved before the claim was written"]\n claim --> agree1 --> agree2 --> plan\n claim -. costs one read of the operand .-> open --> refuted';
const READING_DIAGRAM =
'flowchart TB\n message["A message arrives"]\n subgraph readings["Read whole, in order"]\n identity["What exists"]\n composition["What it is made of"]\n structure["How the parts are arranged"]\n relation["What it connects to"]\n space["Where it sits"]\n time["When it happens"]\n state["The condition it is in"]\n change["How it is already moving"]\n behaviour["What it does"]\n function["The role that doing serves"]\n cause["Why it happens"]\n meaning["What it signifies"]\n scale["The level it lives at"]\n probability["How sure each reading is"]\n novelty["What cuts against expectation"]\n end\n reply["The reply is that understanding, made explicit"]\n message --> identity --> composition --> structure --> relation --> space --> time --> state --> change --> behaviour --> function --> cause --> meaning --> scale --> probability --> novelty --> reply';
const STANCE_SECTION: Section = {
icon: STANCE_SECTION_ICON,
id: STANCE_SECTION_ID,
intro: "The stance is four sentences, and the rest of the method depends on them. The first is that a claim stays unverified until you or your model read it in the current tree, as shown in claim to evidence. The second is that review is adversarial by default, because agreeing is cheaper than verification, as shown in agreement outruns. The third is that every manual step is a failure of automation; the ontology names what a manual step decays into, manual runbook dependency and manual-only governance. The fourth is that a document states what is true now and carries no history of its own, which is single source of truth applied to prose. Everything else in the method is a mechanism that keeps one of these four sentences true without the developer or the model having to remember it.",
subsections: [
{
blocks: [
{
application:
"In practice, the file is opened before the model or you say what it contains, the command is run before the model or you say what it prints, and the line is quoted rather than recalled. A claim about what a mechanism does is settled by running the mechanism, because a report about it, a rule describing it and a peer's account of it are all prose.",
cause: "The model remembers a version of the file that sounds right, and the developer remembers the version they last edited, and neither of those is the file as it is now.",
decision:
"A claim about the tree stays unverified until the model or the developer reads the tree, rather than being accepted because it sounds right.",
failureMode:
"The model describes a function the way it was before you renamed it two sessions ago, makes an edit based on that description, and the edit lands in the wrong place.",
kind: "lesson",
principle:
"For this reason I treat what either of you remembers as a lead to follow, never as evidence.",
problem:
"A question about the code is often answered from memory, by the model or by the developer, without opening the file.",
validation:
"To check this, ask the model for the file path and line behind each claim it makes. A claim it cannot point to is an assumption.",
},
{
kind: "text",
text: `The stance applies to every input in the same way. My own messages, the model's reasoning, its edits and the reports that say they succeeded, a summary of an earlier turn, a peer's account and a file's claim about itself are all unverified until they are checked now. Reasoning is not verification, and a report that something succeeded is exactly the failure described in it looked right. Verified means read or run in the current state of the tree, which is what the ${node("ver-ground-truth", "ground truth")} node of the loop asks for. A file is also read in full, because reading part of it loses its structure, and the structure is what is being analysed.`,
},
{
kind: "text",
text: "A wrong claim spreads faster than its correction, for a simple reason. Agreeing with a peer costs one read of what they wrote, while refuting them costs opening the thing they wrote about, and only a party with a reason to doubt goes to that effort. The more coherent the argument around a wrong claim, the faster it spreads, because a claim that fits invites agreement rather than inspection. What follows from this is a small discipline: a statement that rests on another party's reading is checked by opening the thing they read, not by reading their sentence, and a claim about a mechanism is settled by making the mechanism run rather than by reading its source.",
},
{
kind: "text",
text: "The difference shows in one exchange. Asked whether the router uses the new name, the answer from memory is the router already uses the new name, so nothing else needs to change. The answer from the tree is the handler in the router still calls the old name, here is the line. Only the second answer can be shown to be wrong, because it points at a line that can be checked.",
},
{
kind: "text",
text: "The last two sentences of the stance follow from the first two. A step a developer performs by hand is a step no check observes, so it is done differently the next time; the repair is described in tools live in the tree. A document that carries its own history makes the reader reconstruct what is true now, and a reader reconstructing the truth is guessing; the repair is described in derived state.",
},
{ caption: "claim to evidence", kind: "mermaid", text: CLAIM_DIAGRAM },
{ caption: "agreement outruns", kind: "mermaid", text: SPREAD_DIAGRAM },
],
title: "Read before you claim",
},
],
title: "The stance",
};
const ADVERSARIAL_SECTION: Section = {
icon: ADVERSARIAL_SECTION_ICON,
id: ADVERSARIAL_SECTION_ID,
intro: "The second sentence of the stance says that review is adversarial by default, and it follows from the first. If a claim about the work stays unverified until the developer, the model or a check has tried to break it, then a review that starts by approving has nothing left to verify.",
subsections: [
{
blocks: [
{
application:
"In practice, a review opens by listing what is wrong, and approval is what remains once that list is empty. A reply that opens with praise is rejected, and you or your model attack your own output before presenting it, because work that neither you nor a check has tried to break is not finished.",
cause: "Training rewards the model for agreeing, so agreement is the easiest answer it can give.",
decision:
"The deliverable of a review is its list of findings, rather than a verdict with reasons attached.",
failureMode:
"The review reads well and approves the change, and the regression ships, because no party in the review was looking for it.",
kind: "lesson",
principle:
"For this reason, approval can only be the result of verification, never the position a review starts from.",
problem:
"A model asked to review a change tends to agree with it, and that agreement looks like a review.",
validation:
"To check this, count the findings in a review. A review with none either checked nothing or checked the wrong thing.",
},
],
title: "The list before the verdict",
},
],
title: "Adversarial by default",
};
const READING_SECTION: Section = {
icon: READING_SECTION_ICON,
id: READING_SECTION_ID,
intro: `A message from the developer is not simply answered. It is first understood as a whole, in one pass, before any reply is written, by reading it through the fifteen questions shown in the readings. This is the ${stage("orient")} node of the loop applied to a request. It matters because most drift starts here: a request answered at its surface is one the model answered without reading what lies under it.`,
subsections: [
{
blocks: [
{
application:
"In practice, the model is asked to read a request through the fifteen questions in their order before replying, and to write the reply as that understanding, in connected sentences rather than under headings.",
boundary:
"The questions scale with the request. A one-line request that comes down to one file and one edit still goes through them, but they take a moment and most of the answers are empty; an empty answer is still an answer, not a skipped question.",
cause: "A reply forms from the first plausible reading of a message, and the first reading is the surface.",
decision:
"A message is understood before it is answered, rather than answered from its first reading.",
failureMode:
"A request to rename a function is answered by renaming the function, and three collectors that found it by a naming pattern quietly stop finding anything, because the model never asked what the name was connected to.",
kind: "lesson",
principle:
"For this reason I treat the structure behind a request as what is being asked about, and the wording as evidence about that structure.",
problem:
"A message answered only at its surface gets wrong the details that only its structure would have shown.",
validation:
"To check this, take a reply and ask which of the fifteen questions it rests on. A reply that skipped one is incomplete rather than concise, and the question it skipped is where its mistake will be.",
},
{
kind: "text",
text: `The fifteen questions are what turn this kind of judgement into something a check can enforce, because each one has a defined kind of answer. ${node("ont-identity", "Identity")} asks what exists, and the answer is a set. ${node("ont-structure", "Structure")} asks how the parts are arranged, and the answer is an ordering. ${node("ont-relation", "Relation")} asks what a thing connects to, and the answer is a graph. ${node("ont-probability", "Probability")} asks how sure each reading is, and the answer is a number between zero and one. The others, ${node("ont-composition", "composition")}, ${node("ont-space", "space")}, ${node("ont-time", "time")}, ${node("ont-state", "state")}, ${node("ont-change", "change")}, ${node("ont-behaviour", "behaviour")}, ${node("ont-function", "function")}, ${node("ont-cause", "cause")}, ${node("ont-meaning", "meaning")}, ${node("ont-scale", "scale")} and ${node("ont-novelty", "novelty")}, each have a kind of answer of their own.`,
},
{
kind: "text",
text: "A question with a defined kind of answer can be turned into a condition that a check can test. What that condition does from there is described in from intent to predicate, on the architecture page, and that is how a reading the developer did once becomes a check that runs every time.",
},
{
kind: "text",
text: "Introspection means looking one level below the abstraction a thing presents. A document's list of sections is its surface, and the rule that decides what may go into a section is its structure. A function's signature is its surface, and which state it owns and how long that state lives are its structure. A count is a surface, and the scope it was counted over is its structure. Reading at that level is what makes the first reading of a request agree with the final verification of its result, because both are then looking at the same thing.",
},
{ caption: "the readings", kind: "mermaid", text: READING_DIAGRAM },
],
title: "Fifteen readings, one pass",
},
],
title: "Resolving a message",
};
export const STANCE_SECTIONS: readonly Section[] = [STANCE_SECTION, ADVERSARIAL_SECTION, READING_SECTION];
```