# configuration/strings/derivation.strings.ts
> 134 lines of code and 8 definitions.
Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-derivation-strings-ts
Source text: https://banes-lab.com/assets/sources/source.a8f4c9fda5318e841f3cc5b614e93895424dad120525e4fe211f9c4a030143b7.generated.txt
## Definitions
- `AXIS_DIAGRAM` (lexical_declaration, line 9)
- `SUBJECT_DIAGRAM` (lexical_declaration, line 12)
- `STATE_DIAGRAM` (lexical_declaration, line 15)
- `COPIES_DIAGRAM` (lexical_declaration, line 18)
- `DETERMINISM_SECTION` (lexical_declaration, line 21)
- `DERIVED_SECTION` (lexical_declaration, line 62)
- `DUPLICATE_SECTION` (lexical_declaration, line 102)
- `DERIVATION_SECTIONS` (lexical_declaration, line 142, exported)
## Source
```typescript
import {
DERIVED_SECTION_ICON,
DETERMINISM_SECTION_ICON,
DUPLICATE_SECTION_ICON,
} from "#configuration/icons/derivation.icons";
import { DERIVED_SECTION_ID, DETERMINISM_SECTION_ID, DUPLICATE_SECTION_ID } from "#core/ids/derivation.ids";
import type { Section } from "#types/document.types";
const AXIS_DIAGRAM =
'flowchart TB\n det["Deterministic · one correct answer exists"]\n heal["Healable · a fixer can restore it"]\n enforce["Enforceable · a check can hold it"]\n predict["Predictable · a reader can predict it"]\n scale["Scalable · a hundred consumers agree on it"]\n det --> heal\n det --> enforce\n det --> predict\n det --> scale';
const SUBJECT_DIAGRAM =
'flowchart TB\n mechanism["A mechanism is proposed"]\n subject{"Is the subject deterministic?"}\n build["Build the check and its healer"]\n change{"Can the subject be made deterministic?"}\n work["Change the subject · an act nothing records becomes an act a writer records"]\n conduct["Declare it unobservable, with the evidence a check would need"]\n mechanism --> subject\n subject -- yes --> build\n subject -- no --> change\n change -- yes --> work --> build\n change -- no --> conduct';
const STATE_DIAGRAM =
'flowchart TB\n tree["The tree on disk"]\n traverse["A traversal, every time"]\n state["The current state"]\n written["A status written last week"]\n reader["The reader"]\n tree --> traverse --> state --> reader\n written -. read as the present .-> reader\n tree -. changed since .- written';
const COPIES_DIAGRAM =
'flowchart TB\n dup["Two copies of one fact"]\n collapse{"Is either derivable from the other?"}\n reduce["One declaration, one derivation · the divergence becomes unrepresentable"]\n count{"How many claim to be the source?"}\n one["One · a source exists"]\n zero["Zero · a cycle, each points at another"]\n many["Many · an undecided choice"]\n derive["Make every other copy a derivation"]\n declare["Declare one home and break the cycle"]\n decide["Decide, then derive"]\n period{"How often does the derivation run?"}\n record["A record"]\n stale["Drift"]\n dup --> collapse\n collapse -- yes --> reduce\n collapse -- no --> count\n count -- one --> one --> derive\n count -- zero --> zero --> declare\n count -- many --> many --> decide\n derive --> period\n period -- often --> record\n period -- never --> stale';
const DETERMINISM_SECTION: Section = {
icon: DETERMINISM_SECTION_ICON,
id: DETERMINISM_SECTION_ID,
intro: "Determinism is the one property the others depend on, as shown in the four properties. A deterministic mechanism can be healed, enforced, predicted and scaled, while pursuing those four separately produces mechanisms that have none of them; the ontology's names for what follows from determinism are predictability, repeatability and reproducibility. So the first question about a mechanism is not whether its subject can be checked, but whether its subject is deterministic, and the first question shows what follows from each answer. The architecture page draws the consequence for the size of a system in scale follows determinism.",
subsections: [
{
blocks: [
{
application:
"In practice, every mechanism is asked whether one correct answer exists for it. Where one does, the mechanism is built to produce that answer and nothing else, with its healer beside it. Where none does, the question is whether the subject can be changed so that one exists, and the subject is changed rather than the check loosened. Where neither is possible, that is said openly and a developer stays in the loop, with the evidence a check would need written down.",
boundary:
"The model's output is not deterministic, and no instruction format makes it so; as the architecture page puts it, the author is probabilistic. The input is therefore structured and the output verified. A rule often has one deterministic half and one that is not, and the honest form of the rule names which half is which.",
cause: "A mechanism with two possible answers cannot be checked, healed or trusted at scale, because every consumer has to handle both.",
decision:
"Determinism comes before speed and before elegance of any kind, rather than being traded against them.",
failureMode:
"A check passes on one machine and fails on another, and the team learns to re-run it until it passes.",
kind: "lesson",
principle:
"For this reason I reach for determinism first, because the other four properties follow from it.",
problem: "Much of what looks like a tooling problem is a non-determinism problem in disguise.",
validation:
"To check this, run the mechanism twice on the same input and compare the bytes. A difference is a finding, whatever the tool says about itself.",
},
{
kind: "text",
text: "Each of the four derived properties fails in a recognisable way when determinism is missing. A healer working on a judgement call guesses. A check over a non-deterministic subject either fires on everything or flakes. A verdict that depends on who ran it cannot be quoted. A protocol that rests on care multiplies its cost by the number of parties while its enforcement stays flat. All four are the same defect, and naming determinism as the source is what lets one question test them all.",
},
{
kind: "text",
text: "Changing the subject is the move most often missed. An act that nothing records cannot be checked, but the same act performed through a tool that records it can, which is the purpose described in tools live in the tree. A rule that a reader has to remember cannot be checked, but the same rule written as a declaration a mechanism resolves can. The rule's wording does not change in either case. What changes is the subject, from something that happens in a turn to something that leaves an artifact, and once it leaves an artifact, the check, the healer and the verdict all follow.",
},
{ caption: "the four properties", kind: "mermaid", text: AXIS_DIAGRAM },
{ caption: "the first question", kind: "mermaid", text: SUBJECT_DIAGRAM },
],
title: "Four properties, one axis",
},
],
title: "One correct answer",
};
const DERIVED_SECTION: Section = {
icon: DERIVED_SECTION_ICON,
id: DERIVED_SECTION_ID,
intro: "Every reader derives the state of the work each time, by looking at what is on disk, the route through the tree shown in two routes. A checkbox that you or the model ticked is a claim, while a report a run wrote is evidence. A count you typed is a copy of a fact the tree already holds, and it is wrong from the first change you did not carry over to it. The property this aims at is self-describing architecture, the health test named in a system is a graph, and here introspection over the tree replaces every written status.",
subsections: [
{
blocks: [
{
application:
"In practice, counts, statuses and progress are derived by traversal and written nowhere, and history is kept out of the documents that state what is true now. A superseded statement is deleted rather than marked, and a document that states how many of something exist is regenerated rather than written by hand.",
boundary:
"A prior value that a mechanism consumes to compute a change is an input, not history. A drift detector needs both states; the earlier one lives in the artifact the comparison produces and disappears when the comparison does. The test is whether removing the comparison would leave the value still written.",
cause: "Nothing re-reads a marker after the tree moves, so its staleness has no observer.",
decision:
"The cost of a traversal is paid on every read, rather than the cost of staleness on every write.",
failureMode:
"The plan says three of five phases are done, two of the three were undone by a later change, and the plan still says three.",
kind: "lesson",
principle:
"For this reason the state is derived from the tree and never written, and history is kept apart from the current truth.",
problem: "Markers written into a plan describe the past and get read as the present.",
validation:
"To check this, delete a written status and derive it again. If the derived value differs from the written one, the written one was already wrong.",
},
{
kind: "text",
text: "Written into the plan, a status reads phase three of five, done, updated last week; derived from the tree, it reads phase three of five, two tasks open, one closed since the last run. The first was true once, and the second is true now. The difference is not a matter of diligence. A written marker goes stale by construction, and a stale marker creates a false belief, while an absent marker simply reads as absence.",
},
{
kind: "text",
text: "The same rule reaches documents: every document states what is true now. It carries no change notes, no clauses saying what something was renamed from, no dates tied to our own actions, and no explanation of the current state in terms of a former one. History has two homes and no third: an accumulator that a mechanism can read, and the message the developer receives. The check that enforces this is described in documentation is code.",
},
{ caption: "two routes", kind: "mermaid", text: STATE_DIAGRAM },
],
title: "Derived, never written",
},
],
title: "Derived state",
};
const DUPLICATE_SECTION: Section = {
icon: DUPLICATE_SECTION_ICON,
id: DUPLICATE_SECTION_ID,
intro: "A fact stated in more than one place is not yet a defect. DRY names the aim, a dual write names the failure, and a walk with a fixed order decides which of the two a given pair is, as shown in the walk. The walk asks whether the copies can collapse into one, how many of them claim to be the source, how often each derivation runs, and which consumer each copy reaches. Walked out of order, the same set of copies leads either to a repair that destroys evidence or to a comparison over an edge that cannot exist.",
subsections: [
{
blocks: [
{
application:
"In practice, collapse is asked first: where one copy can be derived from the other, the derivable one stops being written, and the divergence can no longer occur. Only where collapse is not available are the distinguished copies counted, and then one resolves to a derivation, zero to a declaration, and many to a decision. Next, the period of every derivation edge is read, because a copy that is regenerated is an instance of the source that can go stale, while a copy fixed once at creation is a record. Last comes what each copy reaches, because a set of copies can be fully collapsed and still deliver nothing.",
boundary:
"A one-shot copy, written once against the fact as it stood at the time, is a record rather than a stale instance. Collapsing it would destroy evidence rather than remove duplication, so the repair is inverted: the copies are diagnosed and the source is repaired.",
cause: "Copying never records which copy was the original, so the walk has to count.",
decision:
"Every duplicate is decided by its collapse, its count of distinguished copies, its derivation period and its delivery, in that order, rather than by which copy looks newer.",
failureMode:
"Two configs disagree, each team believes its own is the source, both get edited, and neither derives from the other.",
kind: "lesson",
principle:
"For this reason a duplicate is resolved by counting its distinguished copies, and how often a derivation runs decides whether a copy is a record or a stale one.",
problem: "Deciding which of two copies is right is guesswork until you count.",
validation:
"To check this, name the source of a duplicated fact and the period at which its copies refresh. A copy whose refresh nothing schedules is stale from the first change to its source.",
},
{
kind: "text",
text: "Refusing to pick a source when there are zero is the directed acyclic graph ruling in the form a duplicate reaches it. A second declaration is an edge rather than a fact standing beside the first, so a set of copies is a dependency graph and collapsing it means choosing a direction along it; a cycle among the copies is a circular dependency between facts. Where no copy is distinguished, the graph has no root, and a collapse would have to choose one that the structure does not supply. Refusing is the whole of the correct behaviour there, and it is the part a builder is most tempted to improve: a tiebreak applied to a cyclic set turns a correct refusal into a confident wrong answer.",
},
{
kind: "text",
text: "Every repair of a divergence first asks which side is authoritative. A join can report that two declarations agree, but never that the value they agree on is right. Where one side cites the other, the direction is forced and the repair is bookkeeping. Where both sides declare, the repair is a decision about which value is correct, and the pull is always toward whichever side is free to change. Converging on the cheap side and reporting it as maintenance is the substitution to refuse. A comparison's green result is a correctness verdict only where one side is authoritative; elsewhere it says the two match without saying that either is right.",
},
{ caption: "the walk", kind: "mermaid", text: COPIES_DIAGRAM },
],
title: "Count the distinguished copies",
},
],
title: "Counting copies",
};
export const DERIVATION_SECTIONS: readonly Section[] = [DETERMINISM_SECTION, DERIVED_SECTION, DUPLICATE_SECTION];
```