# configuration/strings/graph.fragment.strings.ts > 401 lines of code and 18 definitions. Tree: Site tree Language: typescript Layer: product Canonical: https://banes-lab.com/anatomy/tree#file-configuration-strings-graph-fragment-strings-ts Source text: https://banes-lab.com/assets/sources/source.6d3fd3af883cf475469048731c66a1fe52303e56b44a44090143095c0cba18bf.generated.txt ## Definitions - `FORCING_SHAPE` (lexical_declaration, line 22) - `FINDING_SHAPE` (lexical_declaration, line 25) - `FORCING_DIAGRAM` (lexical_declaration, line 28) - `COMPONENT_DIAGRAM` (lexical_declaration, line 31) - `COST_CHART` (lexical_declaration, line 34) - `ENFORCEMENT_CHART` (lexical_declaration, line 37) - `CEILING_DIAGRAM` (lexical_declaration, line 40) - `REDUCTION_DIAGRAM` (lexical_declaration, line 43) - `AUTHOR_DIAGRAM` (lexical_declaration, line 46) - `DETERMINISM_DIAGRAM` (lexical_declaration, line 49) - `MODEL_DIAGRAM` (lexical_declaration, line 52) - `FORCING_SECTION` (lexical_declaration, line 55) - `CEILING_SECTION` (lexical_declaration, line 116) - `REDUCTION_SECTION` (lexical_declaration, line 176) - `AUTHOR_SECTION` (lexical_declaration, line 234) - `DETERMINISM_SECTION` (lexical_declaration, line 294) - `MODEL_SYSTEM_SECTION` (lexical_declaration, line 353) - `SCALE_SECTIONS` (lexical_declaration, line 412, exported) ## Source ```typescript import { AUTHOR_SECTION_ICON, CEILING_SECTION_ICON, DETERMINISM_SECTION_ICON, FORCING_SECTION_ICON, MODEL_SYSTEM_SECTION_ICON, REDUCTION_SECTION_ICON, } from "#configuration/icons/architecture.icons"; import { AUTHOR_SECTION_ID, CEILING_SECTION_ID, DETERMINISM_SECTION_ID, FORCING_SECTION_ID, MODEL_SYSTEM_SECTION_ID, REDUCTION_SECTION_ID, } from "#core/ids/architecture.ids"; import { LAYER_FACE, TENSION_FACE } from "@govlab/constants"; import type { Section } from "#types/document.types"; import { TYPESCRIPT_LANGUAGE } from "#configuration/constants/code.constants"; import { faceLink } from "#domain/converters/ontology.converter"; const FORCING_SHAPE = 'export interface Forces {\n readonly from: SurfaceId;\n readonly to: SurfaceId;\n readonly evidence: string;\n}\n\nexport interface Concern {\n readonly id: ConcernId;\n readonly surfaces: readonly SurfaceId[];\n readonly owner: SeatId | null;\n}\n\nexport interface Claim {\n readonly author: SeatId;\n readonly cites: readonly SurfaceId[];\n readonly observedAt: Ordinal;\n}\n\nexport interface Bounds {\n readonly floor: number;\n readonly ceiling: number;\n readonly partition: readonly Concern[];\n readonly derivedBy: "mechanism" | "declared-unbuilt";\n}'; const FINDING_SHAPE = 'export interface Finding {\n readonly at: Location;\n readonly mismatch: { readonly expected: Shape; readonly found: Shape };\n readonly remediation: { readonly operation: Operation; readonly operands: readonly Operand[] };\n}\n\nexport const route = (finding: Finding): "heal" | "delegate" =>\n finding.remediation.operands.every((operand) => operand.resolved) ? "heal" : "delegate";'; const FORCING_DIAGRAM = 'flowchart TB\n surfaces["The surfaces a body of work touches"]\n relation["Join two surfaces when a change to one forces a change to the other"]\n components["The connected components · one per concern"]\n floor["Floor · the number of components"]\n fanin["Fan-in · how many parties\' claims rest on one surface, measured from traffic"]\n ceiling["Ceiling · where claims on one surface stop surviving composition"]\n count["A count inside the range · with the partition written down"]\n surfaces --> relation --> components --> floor --> count\n surfaces --> fanin --> ceiling --> count\n choice["The one choice · which reading of forces"]\n choice -. answerable to evidence, never taste .-> relation'; const COMPONENT_DIAGRAM = 'flowchart LR\n subgraph one["concern · one seat"]\n schema["schema"] --- loader["loader"]\n loader --- validator["validator"]\n end\n subgraph two["concern · one seat"]\n view["view"] --- renderer["renderer"]\n renderer --- styles["styles"]\n end\n subgraph three["concern · one seat"]\n pipeline["pipeline"] --- reporter["reporter"]\n end\n shared["shared surface · fan-in from every seat"]\n validator -.-> shared\n renderer -.-> shared\n reporter -.-> shared'; const COST_CHART = 'xychart-beta\n title "A stale claim: the rate has one writer, the cost has every reader"\n x-axis "parties" [1, 2, 3, 4, 5, 6, 7, 8]\n y-axis "cost of one stale claim" 0 --> 16\n line "unmarked claim · argued by every reader" [1, 2, 4, 6, 8, 10, 12, 14]\n line "marked claim · a glance per reader" [1, 1, 2, 2, 3, 3, 4, 4]\n line "rate of going stale · one writer" [1, 1, 1, 1, 1, 1, 1, 1]'; const ENFORCEMENT_CHART = 'xychart-beta\n title "Enforcement cost against the number of authors"\n x-axis "authors" [1, 2, 4, 8, 16, 32]\n y-axis "cost per change" 0 --> 32\n line "a protocol resting on care" [1, 2, 4, 8, 16, 32]\n line "a deterministic check" [1, 1, 1, 1, 1, 1]'; const CEILING_DIAGRAM = 'flowchart LR\n rate["The rate a claim goes stale · set by one writer and one composer"]\n cost["The cost of a stale claim · multiplied by every reader"]\n marker["A claim marked with the surface state it rested on"]\n glance["A glance instead of an argument"]\n ceiling["The ceiling rises"]\n rate -. unchanged by headcount .-> ceiling\n cost --> marker --> glance --> ceiling'; const REDUCTION_DIAGRAM = 'flowchart TB\n w1["worker"] --> o1["orchestrator · publishes the fused result of its workers"]\n w2["worker"] --> o1\n w3["worker"] --> o2["orchestrator"]\n w4["worker"] --> o2\n o1 --> composer["composer · one writer, one reduction"]\n o2 --> composer\n raw["Raw records passed upward · fan-in without reduction, accumulation by construction"]\n o1 -. never .-> raw'; const AUTHOR_DIAGRAM = 'flowchart TB\n intent["An architectural intent"]\n author{"Who writes against it?"}\n person["The developer · complies by attention · drifts slowly"]\n model["A model · complies probabilistically · produces locally reasonable changes at speed"]\n gate["A gate · the only party in the loop that refuses"]\n holds["The intent holds by construction"]\n decays["The intent decays at the author\'s speed"]\n intent --> author\n author -- developer --> person -. eventually .-> decays\n author -- model --> model --> decays\n model -- every intent as a predicate --> gate --> holds'; const DETERMINISM_DIAGRAM = 'flowchart LR\n subject["A subject with one correct answer"]\n check["A deterministic check · same cost, same verdict, any author"]\n authors["One author, ten, a model · enforcement cost stays flat"]\n care["A protocol resting on care · cost multiplied by every author"]\n subject --> check --> authors\n subject -. left to attention .-> care'; const MODEL_DIAGRAM = 'flowchart TB\n model["A model in the system"]\n governed["versioned, gated, evaluated · like any dependency"]\n grounded["generation grounded in retrieved evidence that cites its source"]\n structured["knowledge structured so the output can be explained"]\n bounded["authority bounded · output validated before any sink, capabilities declared"]\n canon["The same canon · contracts, schema and security applied to an author whose output is a distribution"]\n model --> governed --> canon\n model --> grounded --> canon\n model --> structured --> canon\n model --> bounded --> canon'; const FORCING_SECTION: Section = { icon: FORCING_SECTION_ICON, id: FORCING_SECTION_ID, intro: "This section covers how work is partitioned into concerns and how many parties it needs. The partition is derived rather than drawn, as shown in floor and ceiling, one body of work is walked in three components, and the records the derivation reads are typed in the derivation's records. The practice for a body of work is described in scale follows from structure on the methodology page.", subsections: [ { blocks: [ { application: "In practice, the surfaces a body of work touches are enumerated, and the pairs that force each other are recorded with evidence, where a change to one cannot land without a change to the other. The connected components of that relation are the concerns, each gets one owner, and the number of components is the floor. The fan-in on each shared surface is measured from the claims already recorded against it, and the worst fan-in sets the ceiling. A count is chosen inside that range, and the partition is written down beside the choice.", boundary: "The relation is chosen once, and that choice is the one place judgement enters. Two defensible readings of what forces what yield component counts far apart, so the claim is a derivation with a choice at the bottom. The choice is answerable to evidence, and where no mechanism yet computes the partition or the fan-in, that absence is written down as debt with its operands rather than left to read as a measurement.", cause: "A concern drawn as an area of a task list follows how the list was written, and a list is written by one developer on one day, so its areas cut across the couplings that actually force changes.", decision: "The work is cut along what forces what rather than along what the work list happened to group.", failureMode: "Two seats each own half of one coupled pair of surfaces, every change one makes forces a change in the other's, and the surface between them fills with items about the same edit from both sides.", kind: "lesson", principle: "For this reason a concern is a connected component of the relation that joins two surfaces when a change to one forces a change to the other.", problem: "Concerns are drawn as areas of a work list, so a seat owns a region rather than a component, and every coupled edit crosses two seats.", validation: "To check this, take any two concerns and find one change that forces edits in both. If one exists, the partition put a forcing edge across a boundary, and the two concerns are one component.", }, { caption: "floor and ceiling", kind: "mermaid", text: FORCING_DIAGRAM }, ], title: "Partition, floor, ceiling", }, { blocks: [ { kind: "text", text: "A concern is a bounded context drawn for people rather than for models, and context mapping is the activity that draws it. A concern is a component of the forcing relation for the same reason a bounded context is a region of one model, because inside it one party can be authoritative, and across its edge two parties have to be able to disagree. Separation of concerns at the scale of seats is the same principle as at the scale of files, and it is derived the same way, from what forces what.", }, { kind: "text", text: "Volume is the wrong operand for the floor. Quantity divides across parties and argues for a longer schedule, never a wider one. What forces a second party is indivisibility, a concern that has to be able to contradict another while both stay authoritative, and the floor counts those. Partitioning by volume is horizontal scaling of people, and it buys throughput where the concerns are already separate and nothing where they are not.", }, { caption: "three components", kind: "mermaid", text: COMPONENT_DIAGRAM }, { code: FORCING_SHAPE, kind: "code", language: TYPESCRIPT_LANGUAGE, title: "the derivation's records" }, ], title: "A concern is a bounded context for people", }, { blocks: [ { kind: "text", text: "The ceiling is set by fan-in rather than by the count, because a surface with one writer cannot have its volatility raised by adding a party, and staleness rises only where parties converge on one subject. Ownership bounds fan-in without defining it, since a formally owned surface that many parties reason about behaves like shared mutable state, and the concentration is continuous.", }, { kind: "text", text: "For this reason the ceiling is measured and never declared. A count chosen because it felt right is a bound nothing can disagree with, and so it bounds nothing. Fan-in read from the claims already recorded against each surface is a number a second reader can recompute, and the ceiling follows from the worst of them.", }, ], title: "Fan-in, measured", }, ], title: "A concern is a component", }; const CEILING_SECTION: Section = { icon: CEILING_SECTION_ICON, id: CEILING_SECTION_ID, intro: "This section covers how the ceiling on parties moves. A reader who takes the bound as fixed reaches for the wrong lever, and the expensive one, because the rate at which a claim goes stale has one writer while its cost has every reader, as shown in rate and cost and plotted in the two terms.", subsections: [ { blocks: [ { application: "In practice, the two terms are separated before the headcount is touched. The rate is left alone, because one writer and one composer set it and no number of readers changes it. The cost is attacked instead, by marking every claim with the state of the surface it rested on when it was written, so a claim whose surface has since moved costs its readers a glance where an unmarked one costs every party a read and a reply. The fan-in is measured again after the marker is in place, and the ceiling rises only by what the measurement shows.", boundary: "Two limits apply. Added parties never answer a claim that something is absent, because they produce agreement rather than coverage, and only a refusal that publishes its criterion turns an unanswerable absence into an ordinary read. The bound also does not move where the cost of a stale claim is dominated by the work already built on it, because no marker makes that work cheaper to redo.", cause: "Staleness looks like a rate problem because it is felt as a rate, but the rate has one writer, and what actually grows with the population is how many parties pay for each stale claim.", decision: "The ceiling is raised by cutting what a stale claim costs, never by cutting who reads it.", failureMode: "A team that keeps tripping over stale claims removes a seat, the remaining seats trip at the same rate, and the work that seat owned now has no owner.", kind: "lesson", principle: "For this reason the ceiling on fan-in moves with the cost of a stale claim, not with the rate at which claims go stale.", problem: "The bound on parties is read as fixed, so the only lever a team reaches for is fewer parties.", validation: "To check this, take any stale claim and count who read it and who answered it. If the count is the population, the cost is the term to attack, and if the claim went stale faster than one writer could produce it, you have found a second writer.", }, { caption: "rate and cost", kind: "mermaid", text: CEILING_DIAGRAM }, ], title: "The cost, not the rate", }, { blocks: [ { kind: "text", text: "A mechanism that records when a claim's cited surface was observed reduces no staleness, only what staleness costs, so it raises the ceiling without touching the partition.", }, { kind: "text", text: "The marker is a correlation id for reasoning, because it joins a claim to the state it was made against, the way a correlation id joins a log line to the request that produced it. Causal consistency is the property it buys, since a reader can tell whether a claim happened before or after the surface it rests on moved, without a clock and without asking.", }, { caption: "the two terms", kind: "mermaid", text: COST_CHART }, ], title: "The marker", }, { blocks: [ { kind: "text", text: "The lever changes one thing. The partition stays what the forcing relation derived, the seats stay what the floor demanded, and what changes is how expensive it is for the parties to be wrong about each other for a moment.", }, { kind: "text", text: "Eventual consistency between parties is the state the marker makes affordable. Each party holds a view that may lag, and the lag is visible rather than argued. Consensus is the expensive alternative, every party agreeing before any proceeds, and it is the right mechanism only where a stale claim costs more than a halt.", }, ], title: "What the lever leaves alone", }, ], title: "The ceiling moves by cost", }; const REDUCTION_SECTION: Section = { icon: REDUCTION_SECTION_ICON, id: REDUCTION_SECTION_ID, intro: "This section covers what happens above one tier, where a flat surface becomes the accumulation and the shape that survives is a tree, as shown in reduction.", subsections: [ { blocks: [ { application: "In practice, the surfaces are arranged as a tree once one tier is not enough. A parent hands scope down and publishes only the fused result of its children upward, and every record keeps its one writer at every depth, so identity and reduction hold unchanged whether the tree is two levels or ten. Each reduction is derivable and checkable, so a fusion that silently drops a live item fails exactly as a dropped record does. Where the reduction step is unbuilt, it is declared so, rather than letting a design read as if it had been measured at a headcount it never reached.", boundary: "Reduction changes what is published upward and never who may write. A parent that rewrites a child's record has taken a second writer's seat, and a child that reads the global view has bypassed the bound that made its reading finite. The tree holds only while both stay on their side.", cause: "Fan-in without reduction passes every record to every reader, so the volume a party has to read grows with the population, and that growth is the accumulation everyone then tries to drain by care.", decision: "The fused result is published rather than the raw records, at every tier.", failureMode: "An orchestrator forwards its workers' raw records upward, the composer reads everything every worker wrote, and the surface that was supposed to bound reading has become the unbounded thing it replaced.", kind: "lesson", principle: "For this reason, above one tier, scale is reduction, with fused results going up, scope coming down, and every record keeping one writer.", problem: "Flat fan-in grows without bound, and the growth is read as a discipline problem when it is the structure doing exactly what it was built to do.", validation: "To check this, take any surface above the first tier and ask what it publishes upward. If it forwards raw records, it is accumulating by construction, and no drain rule will keep up with it.", }, { caption: "reduction", kind: "mermaid", text: REDUCTION_DIAGRAM }, ], title: "Fused results up, scope down", }, { blocks: [ { kind: "text", text: "Reduction is fan-out/fan-in with the fan-in half taken seriously. Fan-out is cheap, because scope handed down divides. Fan-in is where every distributed design pays, because results handed up add, and the only way to keep the sum bounded is to reduce at each tier. Orchestration is the shape of one tier, a coordinating owner that hands scope down and publishes one fused result up, and choreography is the shape between peers who share no parent.", }, { kind: "text", text: "Branching is fractal, running from workers into an orchestrator, into another orchestrator and into a composer. Every record keeps its one writer, and a reduced tier is published by one writer, so identity and reduction hold unchanged at any depth. A message chain, one party relaying another's raw record to a third, is the anti-pattern that appears the moment a tier forwards rather than reduces.", }, ], title: "Fan-in taken seriously", }, { blocks: [ { kind: "text", text: "A reduction is derived and checkable, and a fusion that silently drops one live item beneath it fails exactly as a dropped record does. Missing backpressure is the same defect at a queue, where a tier that accepts more than it reduces accumulates, and the accumulation is the design working as built.", }, { kind: "text", text: "The reduction step itself is declared unbuilt and unmeasured at any headcount, and saying so is what stops the design reading as though it had been measured. A design that claims scalability it has not measured makes, in prose, the unevidenced claim the coverage tab refuses.", }, ], title: "Checkable, and honestly unmeasured", }, ], title: "Above one tier, reduction", }; const AUTHOR_SECTION: Section = { icon: AUTHOR_SECTION_ICON, id: AUTHOR_SECTION_ID, intro: "This section covers what architecture means when a model writes the code, as shown in three authors, and the finding that reaches the model, typed in a finding record. The same three parties are derived from the tooling's side in who does what on the methodology page.", subsections: [ { blocks: [ { application: "In practice, the seven controls are installed as checks before the model writes anything, and every architectural intent is treated as unenforced until its predicate runs in the chain. The model's authority is bounded, so every model-produced artifact is validated at the boundary it crosses and raw model output never reaches a trusted sink. The model is directed with findings rather than principles, in the loop described in detect, log, fix on the methodology page.", boundary: "The model is not the reviewer and the gate is not the designer. A gate decides whether a predicate holds and nothing about whether the predicate was worth stating. That decision stays with the developer, and a system whose predicates were chosen by the model has let the author grade its own work.", cause: "A model's adherence to an instruction is a distribution rather than a commitment, so an architecture that rests on adherence is a bet placed on every change.", decision: "Design is spent on choosing predicates rather than on explaining intentions to the model.", failureMode: "An edit is judged clean by the model's own read of it, the check that would have disagreed never ran, and the design principle the edit violates is still the first paragraph of the document the model was given.", kind: "lesson", principle: "For this reason the architecture is the set of predicates the gate holds, and design is choosing them.", problem: "Development with a model scales code production and leaves architecture where it was, held by intentions the model does not keep.", validation: "To check this, delete the design document from the session and run the gate. Whatever the gate refuses is the architecture that exists. Whatever it accepts that the document forbade was never architecture, and the model has been writing it since the first session.", }, { caption: "three authors", kind: "mermaid", text: AUTHOR_DIAGRAM }, ], title: "Every principle becomes a gate", }, { blocks: [ { kind: "text", text: "The division of labour follows from the author being a model. The tooling detects because detection is deterministic and a model's account of its own work is not. The model is asked to remediate because a finding is a task it is likely to perform consistently. The developer governs because choosing the predicates and deciding the tensions is not computed.", }, { kind: "text", text: "The arrangement is policy enforcement, with the policy held as code and the enforcement held by a gate, and it is the only arrangement in which an agentic architecture keeps an architecture at all. Prompt engineering can raise the odds that a model honours an intent. It cannot make the intent hold, because a probability is not a predicate.", }, ], title: "Who does what", }, { blocks: [ { kind: "text", text: "A finding is machine-actionable for exactly this reason, and its shape is described in detect, log, fix on the methodology page. Auto-remediation takes the findings with one correct answer, and the rest route to the model with their operands already resolved.", }, { kind: "text", text: "Ungrounded content is the failure this shape prevents. A model told a principle is likely to produce a plausible reading of it. A model handed a finding is asked to make the one change the finding names, and the gate that produced the finding is the same gate that checks the change, so the loop closes on evidence rather than on the model's report of itself.", }, { code: FINDING_SHAPE, kind: "code", language: TYPESCRIPT_LANGUAGE, title: "a finding record" }, ], title: "A finding is the contract", }, ], title: "The author is probabilistic", }; const DETERMINISM_SECTION: Section = { icon: DETERMINISM_SECTION_ICON, id: DETERMINISM_SECTION_ID, intro: "This section covers how scale relates to determinism, as shown in check against care and plotted in cost per change, and why a model author is the case where the relation matters most. The same axis is stated for a mechanism in one correct answer on the methodology page.", subsections: [ { blocks: [ { application: "In practice, the subject that has one correct answer is found for every concern and made the thing a check decides. Authors can then be counted freely, because a deterministic verdict is the same for one author or ten, and the model's non-determinism is confined to the one place it belongs, the choice among admissible changes.", boundary: "Determinism is claimed for the check, never for the author. A model stays a distribution however deterministic the gate around it is, and the gate's job is to make that fact cost nothing rather than to pretend it away.", cause: "A verdict that depends on who is looking has to be produced once per author, while a verdict that depends only on the tree is produced once, so the cost of care scales with the population and the cost of a check does not.", decision: "Judgement moves out of the check and into the choice of which checks to hold.", failureMode: "A review process that worked for two developers is applied to a model that produces a hundred changes a day, and the reviewers become the bottleneck the model was meant to remove.", kind: "lesson", principle: "For this reason a deterministic subject is checkable, healable, predictable and scalable at once, and scale follows from determinism rather than from headcount.", problem: "Enforcement that rests on care costs more for every author added, and a model is an author whose output rate makes the multiplication expensive.", validation: "To check this, take any rule you enforce by review and ask whether two reviewers would return the same verdict on the same tree. If not, the subject is not yet deterministic, and every author you add costs another review.", }, { caption: "check against care", kind: "mermaid", text: DETERMINISM_DIAGRAM }, ], title: "The same verdict for any author", }, { blocks: [ { kind: "text", text: "A deterministic subject has testability, auto-remediation reaches it, and predictability and scalability follow without being pursued.", }, { kind: "text", text: "The rest of this page lists the subjects that can be made deterministic, namely what a file is, what a principle requires, which control is absent, which cell is watched and which concern a change forces.", }, { caption: "cost per change", kind: "mermaid", text: ENFORCEMENT_CHART }, ], title: "Determinism is the axis the others derive from", }, { blocks: [ { kind: "text", text: "Flaky test normalization is what a team does when it stops believing this. A check that returns a different verdict on the same tree is treated as noise, the noise is tolerated, and every author learns that red means run it again. The repair is never a retry pattern around the check. It is finding the non-deterministic subject the check depends on and making it deterministic, or declaring that it cannot be and holding the check.", }, { kind: "text", text: "Formal verification is the far end of the same axis, a subject made deterministic enough that a proof replaces a run, and static analysis is the near end, a shape decided without running anything. Most of an architecture's predicates live at the near end, and that is enough, because a verdict that is the same for any author is what lets the author be a model.", }, ], title: "When a verdict moves", }, ], title: "Scale follows determinism", }; const MODEL_SYSTEM_SECTION: Section = { icon: MODEL_SYSTEM_SECTION_ICON, id: MODEL_SYSTEM_SECTION_ID, intro: `This section covers systems built around a model, which the same canon governs with one extra category whose records sit on the ${faceLink(LAYER_FACE, "correctness-core", "correctness layer")}. Nothing about a model is special to the canon. The category applies the contracts, schema and security layers to an author whose output is a distribution, and the one thing it adds is the insistence that the distribution be measured before it is trusted, in the four obligations shown in one category.`, subsections: [ { blocks: [ { application: "In practice, a model is versioned, gated and evaluated like any dependency, and measured before it is trusted. What it generates is grounded in retrieved evidence that cites its source rather than in recollection, and the knowledge it reasons over is structured so the output can be explained. Its authority is bounded at every boundary, so its output is validated before it reaches a sink, a raw completion never lands in a trusted store, and every capability it may invoke is declared, so it is discovered rather than reachable by default.", boundary: "The category governs a model as a component of a system and says nothing about how a model should be built or trained. A model's internals are a dependency's internals, and the canon's claim stops at the boundary where its output crosses into the system.", cause: "A model's output is a distribution, so every contract that assumes a deterministic component is violated by default where a model stands, and the only repair is to apply the contracts explicitly at the boundary the model's output crosses.", decision: "The model is treated as an author rather than a component, so every boundary its output crosses is one the contracts already govern.", failureMode: "A completion is written straight into a trusted store, the store is read as fact by the rest of the system, and the fact was a fluent guess that was never validated because the model was treated as a component rather than as an author.", kind: "lesson", principle: "For this reason a model is governed as a dependency whose output is a distribution, by the same canon applied at its boundary.", problem: "A model is treated as a component that returns answers, so its output crosses every boundary a deterministic component's would and none of the contracts are applied.", validation: "To check this, follow one model output from generation to the first trusted sink and name the validation it crossed. If there is none, the model's authority is unbounded, and the canon has a category for exactly that failure.", }, { caption: "one category", kind: "mermaid", text: MODEL_DIAGRAM }, ], title: "A dependency whose output is a distribution", }, { blocks: [ { kind: "text", text: "Model governance and model evaluation are the canon's records for the first obligation. Model drift monitoring keeps measuring after the model is trusted, because a distribution that was acceptable at one version is a claim about that version only, and model version ambiguity is the anti-pattern of a system that cannot say which one answered.", }, { kind: "text", text: "Retrieval-augmented generation is the grounding, with vector search as the retrieval and the citation as the ground. Knowledge graphs structure what the system reasons over so that explainability is a property of the output rather than a hope.", }, ], title: "Governed, grounded, structured", }, { blocks: [ { kind: "text", text: "Model safety is the canon's record for the bound. The validation is input validation, and a capability the model may invoke is a capability declaration. Least privilege and secure by default are the same two principles they are for any actor, applied to one whose intentions are a distribution.", }, { kind: "text", text: `An agentic architecture is ${faceLink(TENSION_FACE, "agentic-architecture-determinism", "traded against determinism")}, and the operating point is the set of gates described in the loop, which is the same answer this whole page gives. Prompt sprawl is what a system looks like when the gates were never built and the prompts took their place.`, }, ], title: "Bounded", }, ], title: "Systems built around a model", }; export const SCALE_SECTIONS: readonly Section[] = [ FORCING_SECTION, CEILING_SECTION, REDUCTION_SECTION, AUTHOR_SECTION, DETERMINISM_SECTION, MODEL_SYSTEM_SECTION, ]; ```