Chapter 6 – Context Architecture

FAIL test_calculate_income_tax_high_earner_scenario
expected: 42_750
actual:   43_500

The model receives one bounded slice rather than the whole repository:

• Anchor: start from the failing test.
• Expand: include the approved tax rule, the function under test, its direct helpers, and the checks needed to judge a candidate.
• Prune: exclude unrelated endpoints, documentation, history, and writable surfaces.

flowchart TB
    A[Anchor<br/>Failing case or target] --> E[Expand<br/>Authority + evidence]
    E --> P[Prune<br/>Scope + relevance + budgets]
    P --> S[Bounded input]

Part I established a bounded loop. Chapter 5 showed that useful refinement depends on feedback specific enough to guide a correction. This chapter asks what the loop should receive so it can act on that feedback without guessing. The answer is not the largest available prompt. It is the smallest reproducible input that contains the authority and evidence required for that change.

Long context can still be useful, but capacity does not imply uniform use. In controlled multi-document question-answering and key-value retrieval experiments, performance often declined when relevant information appeared in the middle of long inputs.¹ Those experiments establish positional fragility in those tasks. They do not establish that repository slicing prevents scope errors. The Software Development as Code (SDaC) hypothesis is narrower and must be tested locally: bounded, structured inputs should reduce irrelevant context, invented structure, and unauthorized effects compared with broad repository dumps.

Semantic Density, Correctness, and Relevance

A supporting semantic layer is any source a workflow can consult: documentation, a contract catalog, a knowledge base, an ontology, a retrieval index, a runbook, or structured operational memory. One goal is to concentrate meaning that can change the decision. The book calls that property Semantic Density, and it must be considered with two other qualities:

• Semantic Density: how much distinct, decision-bearing meaning the context carries.
• Correctness: whether claims are traceable to evidence current enough for the decision, with contradictions exposed rather than silently reconciled.
• Relevance: whether the material bears on the active task, governed property, and decision.

Dense falsehood is dangerous. Correct but irrelevant material is noise. Relevant material padded with repetition wastes attention. Context quality therefore cannot be reduced to token count or one universal score. A useful slice carries enough meaning to act, enough evidence to check the result, and little that invites unsupported work.

Authority remains separate from relevance. A retrieved incident report may explain an observed failure without authorizing a code change. A current implementation may show what the system does without defining what it ought to do. Every included source needs a declared role and provenance.

Semantic layers also preserve only what an organization makes explicit. They can retain contracts, decisions, incident findings, and provenance. They do not automatically preserve tacit judgment, apprenticeship, or the reasons people recognize a bad solution before a check does. Context Architecture should expose decision-bearing relationships without pretending that encoded context is complete institutional knowledge.

Build a Context Graph

The larger structure behind one slice is a versioned relationship graph from which the bounded input is selected. The book calls this structure a Context Graph. It can begin as a repository-local index over files, symbols, and their direct relationships; it does not require an organization-wide graph platform.

Its nodes are addressable sources such as files, symbols, documentation sections, schemas, policy clauses, test cases, runbook steps, or incident records. Typed edges record why one source relates to another—for example, calls, depends on, implements, is documented by, or is checked by.

Whatever its size, the graph needs stable identity, provenance, deterministic ordering, and explicit failure. Given the same source identities and extractor version named by the Mission, extraction outside candidate authority should produce the same graph snapshot or fail loudly.

Project identity and tooling should come from repository metadata outside candidate authority rather than model inference. Manifests, ownership records, registered schemas, and policy identify whether a target belongs to code, documentation, infrastructure, or data, and which extraction and checking rules apply. File extensions alone are weak evidence: the same Markdown format may contain approved policy, generated reference material, or untrusted background text.

Assemble a Context Packet

Slicing then applies the same three moves used in the tax example:

1. Anchor on a machine-addressable failing case, finding, symbol, interface, or contract.
2. Expand only across relationships needed to understand, change, and check the governed property.
3. Prune by read scope, write scope, denied surfaces, and finite context and effect budgets.

The result is a bounded input assembled for one run: a Context Packet. Its serialization is incidental. Its claims are not.

Before final review and Activation, the Mission binds the source revision, graph snapshot, extractor, slicer, request template, selection rules, and read authority. Given those bindings, the extractor and slicer must produce the same ordered packet or fail. Once used, a packet instance is immutable. Later findings may justify a new packet instance only under the same bindings and existing read authority; record its new identity. Changing a binding, writable scope, budget, or required check requires a new Mission revision and Activation.

Give each Context Packet and referenced source a stable, verified identity, such as a Git commit for repository content or a content digest for a packet. Once used by a run, those versions remain immutable. Reuse their references across attempts instead of copying the same material into each attempt, and retain them long enough to reconstruct the run input later. If a bound context reference cannot be loaded and verified within read authority, preparation stops rather than silently widening the packet.

Before generation, preparation must establish that:

• the anchor and its source or evidence identity match the bindings named by the Mission;
• authority and evidence remain distinct;
• read, write, and deny boundaries are explicit;
• required checking surfaces are present;
• budgets are finite; and
• the packet can be reconstructed without hidden chat state.

A defect here is a context defect, not evidence that the model needs a broader prompt.

Retrieval Proposes; Policy Selects

Retrieval can propose relevant nodes, but it does not decide the slice. Apply read policy before retrieval, retain source provenance, and filter results through the same relationship, trust, and budget rules used for deterministic discovery. Summaries are lossy evidence; they cannot replace adopted intent, current findings, or authoritative contracts.

When Required Context Does Not Fit

If all required context cannot fit, split the work along a real semantic boundary instead of dropping a required contract. If the activated Mission already declares that decomposition, each smaller candidate uses the same baseline, ordering, and overlap policy, and the workflow validates the combined result. Otherwise, stop and propose split Missions. Local success does not establish that the combined candidate satisfies the required checks.

When the Slice Is Wrong

The opening tax case already shows why a concrete anchor matters. Two broader failure classes complete the picture:

Slicing cannot guarantee a good candidate. It makes the input boundary reproducible so a failure can be attributed more accurately to the candidate, the context, or the governing contract.

Skeleton-First

Chapter 2 demonstrated one use of Skeleton-First: deterministic extraction records structure already present in Terrain, and probabilistic generation supplies only permitted variable material around it. The broader rule is to fix the structural basis before variable work begins. Authority direction determines where that basis comes from and what it may do.

In Map-to-Terrain work that produces implementation, an adopted design, specification, or schema supplies a prescriptive minimum scaffold: it fixes invariants and declares where implementation may expand. In Terrain-to-Map work, deterministic extraction supplies descriptive structure for exact comparison, aggregation, and bounded Map candidates.

Typical skeleton surfaces include:

• signatures and interface contracts;
• schemas and route definitions;
• test names and assertion surfaces;
• file paths, imports, and allowed edit regions.

In one extension of the tax example, the adopted tax policy supplies a requirement hierarchy: the policy at the root, jurisdictions beneath it, and bracket and rate rules at the leaves. Those requirement nodes remain fixed authority for the run. The skeleton declares where permitted implementation and test children may be elaborated beneath them. Once each child is checked against its parent rule, the workflow can fold those results upward into derived jurisdiction summaries and then a policy-wide view. A changed rule or child result makes every dependent parent view stale. The same downward elaboration and upward aggregation may repeat at any depth allowed by the active specification.

The expansion contract may begin as an outline or schema. If recurring cases reveal a stable grammar, a separate Map change may adopt a domain-specific language (DSL) that expresses nodes, expansion rules, and checks more precisely. The active Workflow cannot promote its own successful convention into governing syntax.

The content hierarchy, Context Graph, and Workflow remain separate. The hierarchy relates content nodes. The Context Graph identifies sources from which policy selects bounded authority and evidence. The governed Workflow controls which operations may run, with what effects and checks. Their topologies need not match.

Preparation and validation enforce the direction. A prescriptive skeleton accepts only declared expansions. A descriptive skeleton traces aggregates to Sensor observations, while judgment-heavy summaries remain candidates. Traversal grants authority in neither case.

Skeleton-First protects structure, not correctness. Context Architecture makes the authority and evidence slice used to construct or check that structure reproducible. In the tax example, it establishes which rule, failing case, implementation surface, and direct dependency the generator received. The governed Workflow and its checks still decide whether the candidate satisfies the rule.

With drift, refinement, and bounded context established, Part III can package work as explicit authority and compose these loops across recurring tasks.