# configuration/strings/evidence.strings.ts
> 185 lines of code and 11 definitions.
Tree: Site tree
Language: typescript
Layer: product
Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-evidence-strings-ts
Source text: https://banes-lab.com/assets/sources/source.ea78a29887fa7ef2444078cadf71c422eda4802236e7d23febbe58234cea7a5c.generated.txt
## Definitions
- `VERDICT_SHAPE` (lexical_declaration, line 17)
- `CLAIM_DIAGRAM` (lexical_declaration, line 20)
- `OUTPUT_DIAGRAM` (lexical_declaration, line 23)
- `CONTROL_DIAGRAM` (lexical_declaration, line 26)
- `STANDING_DIAGRAM` (lexical_declaration, line 29)
- `VERDICT_DIAGRAM` (lexical_declaration, line 32)
- `APPEARANCE_SECTION` (lexical_declaration, line 35)
- `VERIFIER_SECTION` (lexical_declaration, line 76)
- `REPORT_SECTION` (lexical_declaration, line 122)
- `UNKNOWN_SECTION` (lexical_declaration, line 160)
- `EVIDENCE_SECTIONS` (lexical_declaration, line 191, exported)
## Source
```typescript
import {
APPEARANCE_SECTION_ICON,
REPORT_SECTION_ICON,
UNKNOWN_SECTION_ICON,
VERIFIER_SECTION_ICON,
} from "#configuration/icons/evidence.icons";
import {
APPEARANCE_SECTION_ID,
REPORT_SECTION_ID,
UNKNOWN_SECTION_ID,
VERIFIER_SECTION_ID,
} from "#core/ids/evidence.ids";
import { nodeLink as node, stageLink as stage } from "#domain/converters/link.converter";
import type { Section } from "#types/document.types";
import { TYPESCRIPT_LANGUAGE } from "#configuration/constants/code.constants";
const VERDICT_SHAPE =
'export type Value = "pass" | "fail";\nexport type Standing = "authoritative" | "withdrawn";\n\nexport interface Stamp {\n readonly surface: string;\n readonly seen: string;\n}\n\nexport interface Verdict {\n readonly value: Value;\n readonly standing: Standing;\n readonly reached: readonly string[];\n readonly moved: readonly Stamp[];\n readonly healedByThisRun: readonly string[];\n readonly derivations: readonly Finding[];\n}\n\nexport const standingOf = (moved: readonly Stamp[]): Standing => (moved.length === 0 ? "authoritative" : "withdrawn");\n\nexport const quotable = (verdict: Verdict): boolean => verdict.value === "pass" && verdict.standing === "authoritative";';
const CLAIM_DIAGRAM =
'flowchart TB\n edit["An edit lands"]\n read["The model reads it back"]\n story["A story about the result"]\n run["The verifier runs"]\n exit["An exit code and parsed findings"]\n done{"Done?"}\n edit --> read --> story\n edit --> run --> exit --> done\n story -. never the signal .-> done';
const OUTPUT_DIAGRAM =
'flowchart TB\n output["A message printed by a run"]\n subject{"Is its subject the mechanism that printed it?"}\n report["A report · the authority of an execution"]\n prose["Prose · opened at the mechanism it names, never trusted for arriving as output"]\n output --> subject\n subject -- yes --> report\n subject -- no --> prose';
const CONTROL_DIAGRAM =
'flowchart TB\n written["A check is written"]\n real["A conforming member it passes"]\n planted["A planted violation it fails"]\n adversarial["Adversarial inputs it rejects"]\n self["The tooling passes through its own gate"]\n recorded["The first firing and the first clearing are recorded"]\n trusted["Trusted, above a disclosed anchor"]\n written --> real --> planted --> adversarial --> self --> recorded --> trusted';
const STANDING_DIAGRAM =
'flowchart TB\n run["A run reads its surfaces and stamps each"]\n restamp["It re-stamps them at the end"]\n moved{"Did any surface move beneath it?"}\n authoritative["The verdict stands and may be quoted"]\n withdrawn["The verdict keeps its value and loses its standing · the moved set is named"]\n run --> restamp --> moved\n moved -- no --> authoritative\n moved -- yes --> withdrawn';
const VERDICT_DIAGRAM =
'flowchart TB\n surface["A surface a unit can fail in"]\n tested{"Does a test touch it?"}\n passed{"Did it pass?"}\n pass["Pass"]\n fail["Fail"]\n unknown["Unknown · never rounds up to pass"]\n surface --> tested\n tested -- no --> unknown\n tested -- yes --> passed\n passed -- yes --> pass\n passed -- no --> fail';
const APPEARANCE_SECTION: Section = {
icon: APPEARANCE_SECTION_ICON,
id: APPEARANCE_SECTION_ID,
intro: `The most expensive failures I have had were the ones that looked right: the code read well and the model said it was done, but nothing had run. Everything in this chapter follows from one distinction. A claim is a sentence that the developer or the model produced, and until something grounds it, it is ungrounded content. ${node("ver-evidence", "Evidence")} is an observation that a mechanism produced. Only evidence decides anything, as shown in a claim's source, and report and prose shows how to tell the two apart. The ${stage("verify")} node of the loop asks exactly this question, and the ontology's verification axis names its parts: ${node("ver-ground-truth", "ground truth")}, ${node("ver-falsification", "falsification")}, ${node("ver-confidence", "confidence")} and ${node("ver-refutation", "refutation")}.`,
subsections: [
{
blocks: [
{
application:
"In practice, the exit code is the answer and the parsed findings are the answer, while the model's summary is treated as a story about the answer.",
boundary:
"A mechanism's output is evidence about the mechanism itself and only prose about anything else. The sentence most likely to stop a reader looking further is one whose subject is not the thing that printed it, because it reads as if the looking has already been done.",
cause: "A model produces text that resembles a finished result, because that is what finished results look like in its training.",
decision:
"The report on disk decides when the work is done, rather than the reply that describes it.",
failureMode:
"The model claims compliance after one edit and never checks it again, and the next run of the tools finds the same fault plus a new one.",
kind: "lesson",
principle:
"For this reason the verdict comes from a machine, and the model's judgement is never the signal that the work is done.",
problem: "A model judges its own edit as clean by reading it, and reading is not running.",
validation:
"To check this, find the verifier output behind every claim of done in a session. A done with no output behind it is a claim, and a claim is unverified.",
},
{
kind: "text",
text: "A completion claim reads all done, the change is clean and everything passes, while a completion signal reads gate: every step passed, exit zero, report written to the run's path. The first is a sentence a model produced, and the second is a number a machine produced.",
},
{
kind: "text",
text: "Evidence comes in tiers, and the tiers are ranked: a measurement taken locally outranks a vendor's documentation, which outranks a community source, which outranks inference. A record carries its confidence and its derivation as two separate axes, because material adapted from elsewhere can be strong or weak evidence regardless of having been adapted, and folding a word about provenance into the vocabulary of strength would make the whole set impossible to rank. When sources conflict, both are recorded and the conflict is stated. A claim that is unverified or rests on a single source is labelled as such wherever it drives a decision.",
},
{ caption: "a claim's source", kind: "mermaid", text: CLAIM_DIAGRAM },
{ caption: "report and prose", kind: "mermaid", text: OUTPUT_DIAGRAM },
],
title: "Looks right is not runs right",
},
],
title: "It looked right",
};
const VERIFIER_SECTION: Section = {
icon: VERIFIER_SECTION_ICON,
id: VERIFIER_SECTION_ID,
intro: "Verification produces evidence, and the verifier itself has to be verified, in the order shown in earning trust. A gate that has never failed on purpose has never shown that it can fail, and a green result from a check that exercises nothing is the mock mirage. A checker applies its own rules to itself; otherwise it asks of the code what it does not ask of its own source. Above every verifier sits an anchor that cannot be verified, only disclosed, because a gate cannot prove itself. A verdict is the value typed in a verdict, and a verdict whose surfaces moved beneath it loses its standing, as shown in lost standing. The same proof, taken when a check is first written, is described in the check comes first.",
subsections: [
{
blocks: [
{
application:
"In practice, the two cases described in the check comes first are kept as tests beside the check. Every detector is also tested adversarially with the inputs that fool a shallow match, such as a look-alike character, a pattern inside a comment, or a shape without the structure. The governance tooling runs through the same gate it enforces. The anchor everything else rests on is disclosed, and when a gate goes green after a structural change, it is confirmed that the gate still loads what it claims to load.",
boundary:
"The anchor is the boundary of what can be verified. A verifier trusts that the runtime runs, that the filesystem reads, that a command executes and that tool output arrives, and it says so rather than pretending to verify them. Everything above the anchor is verified, and the anchor itself is disclosed.",
cause: "A check's own green is the only evidence of its health, and green is also what a broken check produces.",
decision:
"A verifier is trusted only after a conforming member, a planted violation and an adversarial test, rather than on the strength of its green results.",
failureMode:
"A gate is green for a year, until you read its source and find it has matched nothing since a refactor changed the file suffix it looked for.",
kind: "lesson",
principle:
"For this reason I verify the verifier with a conforming member before believing what it says.",
problem: "A green check is evidence of nothing until you know the check can go red.",
validation:
"To check this, find for each check the planted violation that turned it red and the conforming member that turned it green. A check missing either one is unverified.",
},
{
kind: "text",
text: "The failure the anchor guards against is concrete. A loader that discovers checks by a name pattern reports success while loading none of them if the pattern no longer matches what is on disk: every step passes, and nothing is checked. So a green run after a structural change is followed by one question, whether the run still loads what it claims to load, and the evidence is the generated index naming the checks together with the loader's own count. A harness that cannot fail belongs to the same class. A stub that stands in for an absent environment must answer only for that environment, because a permissive stub that also absorbs the subject's own missing symbols turns every defect into a silent success.",
},
{
kind: "text",
text: "A verifier that audits claims audits itself last, and an overclaim in its own contract drops its confidence below the threshold, so a run below the threshold is not a clearance. How that self-audit runs, and why a verifier binds to one phase at a time, is described in agents as executed contracts.",
},
{
kind: "text",
text: "A verdict carries a standing beside its value. Every surface a run reads is stamped when it is read and stamped again at the end, which is optimistic locking over a read set. A run whose read set moved beneath it names the surfaces that moved and is not authoritative. The verdict itself is untouched, so a pass stays a pass; what is withdrawn is its standing to be quoted, because the report then describes an interleaving of changes rather than a state. Holding a write barrier across the read would be the wrong repair: that is pessimistic locking, which serialises every verification against every write to answer a question about the past. In the type, the standing is derived from whether the moved set is empty, rather than written by the run. The set the run reached is named, so a green result reads as coverage over that set and silence over the rest, and the surfaces the run healed itself are named apart from the ones that moved, because a run's own repairs are not contention. A clearance is then one function over the record: a pass whose standing is authoritative. Any other combination is a value without the standing to be quoted.",
},
{ code: VERDICT_SHAPE, kind: "code", language: TYPESCRIPT_LANGUAGE, title: "a verdict" },
{ caption: "earning trust", kind: "mermaid", text: CONTROL_DIAGRAM },
{ caption: "lost standing", kind: "mermaid", text: STANDING_DIAGRAM },
],
title: "Conforming member first",
},
],
title: "Verify the verifier",
};
const REPORT_SECTION: Section = {
icon: REPORT_SECTION_ICON,
id: REPORT_SECTION_ID,
intro: "A verification runs once per state of the tree, and its first output is the answer. Reproducibility is what a second run would test, so a second run that differs is a finding rather than a retry. The output is read whole and never searched for the line you hoped to see. The run writes its report on every exit, so a report being present is never mistaken for a pass. On the grammar page, validation gates hold an instruction's claims to the same standard: checkable, and backed by evidence.",
subsections: [
{
blocks: [
{
application:
"In practice, the gate runs once and its full output is written to a file. The file is read whole, what it names is fixed, and the tree changes; only then does the gate run again, and never merely to see whether the answer changes. A report's scope is read before its verdict, because a clearance from a check that cannot see the whole surface is worse than a visible gap.",
boundary:
"A new run is warranted once the tree has changed; the earlier report is then history, and the new run is the measurement. The sign of misuse is a second run whose only difference is the filter.",
cause: "A second run of the same state either repeats the answer or reveals non-determinism, and both are already findings from the first run.",
decision: "The tree is changed between runs, rather than the filter between reads.",
failureMode:
"The check fails, is run twice more and passes on the third try, and the flake ships with the change, which is flaky test normalization in miniature.",
kind: "lesson",
principle:
"For this reason each state of the tree gets one run, its output is read whole, and its report is written on every exit path.",
problem: "Re-running a check until it passes turns a verifier into a slot machine.",
validation:
"To check this, count the runs per tree state in a session. Anything above one is either a flake that should have been filed or an answer you did not like.",
},
{
kind: "text",
text: "Reading whole is a rule about structure, not about diligence. A slice of a report answers only the question the reader already thought to ask, while the reason a check writes a finding is to raise something the reader had not thought of. A search is worse than an offset, because an offset shows what was skipped, and a search silently leaves out everything that did not match. The same holds for a file and for a coordination surface. When a read fails because the output is too large, that is the cue to read it in parts until the whole has been read, never the cue to sample it.",
},
{
kind: "text",
text: "A count is evidence of coverage only over the surface the scan reaches. A report therefore carries its derivations as well as its verdict, meaning what it reached, what it excluded and why, so that a green result reads as coverage rather than as silence. A negative result inherits the scope of the query that produced it and carries no evidence of its own, so before reporting that something does not exist, the measurement is run again one scope wider, over every surface where the thing could be declared.",
},
],
title: "One run, read whole",
},
],
title: "A report, not a checkbox",
};
const UNKNOWN_SECTION: Section = {
icon: UNKNOWN_SECTION_ICON,
id: UNKNOWN_SECTION_ID,
intro: "A verdict has three values, and the third is the one a percentage hides, as shown in three verdicts. A surface that no test touches has not passed. Its verdict is unknown, and unknown never rounds up to pass.",
subsections: [
{
blocks: [
{
application:
"In practice, the surfaces a unit can fail in are mapped before its tests are written, using the catalogue described in what can drift, seen through how it drifts, projected onto correctness: each surface with its failure modes, its technique, its predicate and its evidence source. Surfaces that are still unknown are reported as unknown, never as passed.",
cause: "A percentage counts lines executed, and a line can execute while no claim about it gets checked.",
decision:
"Coverage is measured as the surfaces a unit can fail in, rather than as a percentage of lines.",
failureMode:
"Coverage is high, the failure that ships lives in a case the test suite never imagined, and the number never moved.",
kind: "lesson",
principle:
"For this reason no evidence means unknown, never pass: a verdict is pass or fail only against an evidence set that is not empty.",
problem:
"Coverage pursued by intuition and reported as a percentage never walks the space a system can fail in.",
validation:
"To check this, name a failure surface of one unit that the tests do not touch. If you can, coverage is not complete, whatever the percentage says.",
},
{ caption: "three verdicts", kind: "mermaid", text: VERDICT_DIAGRAM },
],
title: "Three verdicts, not two",
},
],
title: "Unknown is not pass",
};
export const EVIDENCE_SECTIONS: readonly Section[] = [
APPEARANCE_SECTION,
VERIFIER_SECTION,
REPORT_SECTION,
UNKNOWN_SECTION,
];
```