Context Viewer pilot · viewer-v1.0

Chapter 1 — What exists is not what this computation receives

Scenario: constructed illustration: declared synthetic fixture of six sources, three admitted · Boundary: fixture boundary: declared source set versus assembled bundle for one invocation

Six declared sources exist; three are admitted to the bundle for this computation. What sits on disk but is not included is not context for this step.

Capacity: input allowance unknown (unknown allowance; fixture sets no token budget); no headroom invented

Units: fixture items (6 declared sources). not applicable; fixture counts items, not tokens

Timeline

• Available — Six declared sources exist, including session state carried between steps.
• Assembly — Runtime selects and renders three sources for this invocation.
• Context — Only the three admitted items can participate in this computation.

Diagnostics

• [i] Availability is not admission (status labelled) — Fixture declares 3 of 6 sources admitted; the rest are present on disk but outside the bundle.
  Status: informational
• [-] Behavioural effect (status labelled) — No task outcome is measured in this fixture.
  Status: not-evaluated

Lineage: Session state persists between steps; context is per-invocation. What is stored is not automatically what is received.

Does not establish: Prevalence of any admission pattern in real work; usefulness or behaviour of either bundle is unmeasured.

Renderer viewer-v1.0 · ch01-available-vs-context

Chapter 2 — An observer that records a zero and admits its gaps

Scenario: constructed illustration: synthetic capture with labelled measurement statuses · Boundary: observed at the host model-context hook; provider rendering below the hook is unobserved

A live observer records five declared fields by status, keeps a real zero as zero, and marks one span unobserved. An inactive observer records nothing, and a sequence gap marks incompleteness.

Capacity: input allowance unknown (unknown allowance; fixture sets no token budget); no headroom invented

Units: fixture items (5 declared fields). not applicable; fixture counts fields, not tokens

Timeline

• Live observer — Records zero tool results as observed zero (declared status: observed), not as absence of capture.
• Inactive observer — Records nothing; an empty store is unobserved (declared status: unobserved), never evidence of no activity.
• Sequence gap — Reserved numbers skip one value; session marked incomplete. The gap states incompleteness, not what was lost.

Diagnostics

• [!] Observed zero kept as zero (status labelled) — Fixture declares tool-result count 0 at the boundary; it is excluded from no calculation that needs it.
  Status: confirmed
• [?] Gap content (status labelled) — One reserved sequence number has no record; what it would have held is unobserved.
  Status: unknown
• [-] Below-hook rendering (status labelled) — Provider order and final rendering are outside this boundary and unmeasured here.
  Status: not-evaluated

Lineage: Joined values come from the host record after the call and are conditional on the join; they are not boundary observations.

Does not establish: What the provider finally rendered; what any gap contained; prevalence of gaps in real sessions.

Renderer viewer-v1.0 · ch02-measurement-status

Chapter 3 — What occupies one captured invocation

Scenario: recorded example: author-approved structural accounting of one captured invocation; sampling purpose unclassified · Boundary: opencode.v2.model_context (host model-context hook)

One captured invocation counted as canonical JSON bytes. Tool results are the largest share of the counted representation. Shares use captured input as denominator; the capacity bar uses the observed input allowance.

Capacity: input allowance 1000000 (observed model metadata)

Units: exact canonical bytes; tokens estimated as bytes / 4. approximation, not provider tokens

Timeline

• Single snapshot — One recorded representation at one observation boundary. No growth, removal or reintroduction is shown here; change over time belongs to later chapters.

Diagnostics

• [i] Large tool-result share is structural — 139,630 of 213,655 counted bytes (65.4%). Evidence of occupancy only.
  Status: informational
• [-] Relevance of the tool results — Size does not establish irrelevance. No task labels in this capture.
  Status: not-evaluated
• [?] Deferred definitions and compaction reservations — Unobserved at this boundary; shown as unobserved, not as zero.
  Status: unknown

Lineage: Transport role is not provenance: a user-role part may have been placed by the harness. Origin beyond captured form is unattributed.

Does not establish: Provider usage, usefulness to the model, or typical composition. One selected invocation, not a representative session.

Renderer viewer-v1.0 · ch03-composition

Chapter 4 — One synthetic session against two limits

Scenario: constructed illustration: synthetic worked budget from the chapter, not a measurement · Boundary: illustrative shared-capacity model (provider constraint modelled as one ceiling; runtime policy ceiling below it)

Standing context never changes while task and accumulated context grow. Turn 12 reaches 95 per cent of the 120,000-token usable ceiling while still well inside the 200,000-token hard capacity.

Capacity: input allowance 120000 (declared runtime policy ceiling (synthetic))

Units: illustrative tokens at turn 12 (total 113,800). declared synthetic values

Timeline

• Turn 1: 22,600 (19% of ceiling) — Standing 8,400; task 14,200; accumulated 0.
• Turn 6: 68,800 (57% of ceiling) — Standing 8,400; task 31,500; accumulated 28,900.
• Turn 12: 113,800 (95% of ceiling) — Standing 8,400; task 44,100; accumulated 61,300. Hard capacity 200,000 still looks abundant.

Comparisons

• Usable ceiling vs hard capacity — Turn 12 uses ~95% of the 120,000 policy ceiling but ~57% of the 200,000 hard capacity. Monitoring only the headline misses the binding limit.

Diagnostics

• [i] can fit != should admit != will help — Capacity remaining is not evidence value remaining. No behavioural claim is made.
  Status: informational
• [-] Cost in money or latency — Token counts are not prices. Caching and latency are unobserved here.
  Status: not-evaluated

Lineage: Classes describe lifecycle behaviour, not source or authority. A file edited mid-task can change class without changing origin.

Does not establish: Real-session growth rates, bills, cache behaviour, or whether any turn behaved badly. Behaviour is not shown here.

Renderer viewer-v1.0 · ch04-budget

Chapter 5 — A lean bundle beside a fuller one, behaviour unmeasured

Scenario: constructed illustration: two synthetic bundles at one scale; no behavioural comparison run · Boundary: fixture comparison at the assembly boundary; task outcome is not observed

A lean bundle of three fixture items sits beside a fuller bundle of six. The critical evidence is present in both by fixture declaration; whether the extra material helps is untested here.

Capacity: input allowance unknown (unknown allowance; fixture sets no token budget); no headroom invented

Units: fixture items in the lean bundle (3). not applicable; fixture counts items, not tokens

Timeline

Comparisons

• Fuller bundle (6 fixture items) — Same 1 critical plus 2 supporting plus 3 added: 1 topically related non-answer passage (fixture-declared distractor), 2 unrelated filler. Critical evidence is present in both; positions and total length differ.
• Structural difference only — Added items are 3 of 6. No task outcome, success rate, or latency was measured; present does not imply helpful.

Diagnostics

• [i] Presence in both bundles (status labelled) — Fixture spec declares the critical excerpt present in each bundle, checked by inspection of the fixture.
  Status: informational
• [-] Helpfulness (status labelled) — No controlled run compares outcomes with and without the added material; usefulness is unmeasured.
  Status: not-evaluated

Lineage: Task-relevant and distractor labels come only from the fixture specification, not from model behaviour.

Does not establish: Whether the fuller bundle helps or harms behaviour; transfer of any benchmark degradation to agent tasks is untested.

Renderer viewer-v1.0 · ch05-lean-vs-full

Chapter 6 — Same four items in two rendered orders

Scenario: constructed illustration: one fixture bundle shown in two orders; no behavioural test · Boundary: fixture rendered order at the assembly boundary; provider rendering and model behaviour unobserved

Four fixture items appear in two orders. The critical evidence moves from first to last by rendered slot; content is unchanged and importance comes only from the fixture task spec.

Capacity: input allowance unknown (unknown allowance; fixture sets no token budget); no headroom invented

Units: fixture items in each ordering (4). not applicable; fixture counts items, not tokens

Timeline

• Ordering A: evidence first — Rendered slots 1 evidence, 2 rules, 3 tool results, 4 request. Neighbours of evidence: rules.
• Ordering B: evidence last-before-request — Rendered slots 1 rules, 2 tool results, 3 evidence, 4 request. Same items and counts; neighbours and distances differ.

Comparisons

• Movement — Evidence midpoint moves from slot 1 of 4 to slot 3 of 4; request held last. Absolute and normalised slot reported, not just labels.

Diagnostics

• [i] Different layout, same set (status labelled) — Both orderings declare identical items and identical per-category item counts; only rendered sequence differs.
  Status: informational
• [-] Behavioural consequence (status labelled) — No outcome compared across orderings; no claim about use or weighting is made.
  Status: not-evaluated

Lineage: Rendered order is an assembly property; authority and scope are not encoded by position in this fixture.

Does not establish: Any behavioural effect of the move; attention, weighting, or use by a model is not inferred.

Renderer viewer-v1.0 · ch06-order-changes-layout

Chapter 7 — What pressure may do to each item

Scenario: constructed illustration: synthetic fixture applying the chapter's five declared policy states to its six illustrative items · Boundary: fixture mapping: six illustrative items to permitted transformations; no behavioural measurement

Six items under pressure carry different floors and recovery conditions, so each receives the permitted transformation its policy allows rather than one shared importance rank.

Capacity: input allowance unknown (not applicable to this policy mapping; no budget invented); no headroom invented

Units: declared fixture items (6) grouped by permitted policy state; illustrative. not applicable; policy comparison, not token accounting

Timeline

• Pressure — Session holds the chapter's six: safety rule, test summary (917 passed, 3 failed), 18,000-token log, architecture decision, source file, abandoned hypothesis.
• Two axes — Retention asks what forms an item may take; admission asks whether this computation needs it now. A preservation requirement does not itself establish an always-admit requirement.
• No single score — One importance rank cannot hold exactness, admission and recovery apart, so the fixture records floors and recovery obligations instead.

Diagnostics

• [!] Retention obligation distinct from admission — The safety rule may be PIN when admitted yet optional for read-only tasks under actual policy; absence must be permitted by policy, not inferred from irrelevance.
  Status: confirmed
• [i] Importance is not the primitive — Central material may live durably outside the window while a small exact value must survive verbatim; the fixture keeps exactness, residence and recovery separate.
  Status: informational
• [?] Recovery preconditions unmet — Decision and source file leave the window only with a tested pointer or version identity; writing a pointer alone would amount to deletion.
  Status: potential

Lineage: A compressed or externalised form changes the representation, not the source obligation. The floor and standing stay with the item.

Does not establish: That any item deserves its label in a live system, or that importance scoring predicts the mapping. Labels here are declared permissions with preconditions, not measured outcomes.

Renderer viewer-v1.0 · ch07-retention-states

Chapter 8 — What a larger window moves and what it leaves open

Scenario: constructed illustration: synthetic small-vs-large configuration comparison; theoretical possibilities kept apart from measured behaviour · Boundary: fixture comparison: configured capacity vs undecided runtime policy questions

A larger configuration lets more material fit and can ease cost, while authority, staleness, redundancy and scope still need runtime policy that the machinery alone cannot supply.

Capacity: input allowance unknown (unknown allowance in this fixture; comparison is structural, none invented); no headroom invented

Units: synthetic fixture units under the large configuration; illustrative. not applicable; structural comparison, not token accounting

Timeline

Comparisons

• What can move — Hard capacity, processing cost and state memory can move with the machinery. The fixture shows more material fitting.
• What stays open — Which source is authoritative, which material is stale, which duplicate is redundant and which scope applies still need external policy facts.

Diagnostics

• [i] Capacity moved, decisions remain — Fixture admits more material under the large configuration; admission, fidelity and recovery thresholds are still set by runtime policy.
  Status: informational
• [-] Effective behaviour at length — Whether required material remains usable at length is unevaluated here; it needs task, position and distractor evaluation.
  Status: not-evaluated

Lineage: A cheaper feasible region changes what may be presented, not what should be. Policy knowledge is not inferred from processing capability.

Does not establish: Any measured effective use at length, or that fitting material improves behaviour. Configured maximum and usable context remain distinct.

Renderer viewer-v1.0 · ch08-bigger-window

Chapter 9 — Where an edit moves the first divergence

Scenario: constructed illustration: schematic prefix geometry on the figure's declared 0-100 axis; structural eligibility only, not realised reuse · Boundary: structural common leading region at the observer boundary; provider eligibility and realised hits unobserved

A same-sized edit near the start leaves almost nothing structurally reusable after it, while the same edit at the end leaves almost everything before it reusable. Geometry describes candidacy, not cost.

Capacity: input allowance unknown (not applicable to this schematic; axis is positional, none invented); no headroom invented

Units: declared schematic positions on the 0-100 axis for the mid-row edit at 50; not measured. not applicable; schematic geometry, not provider tokenisation

Timeline

• Edit near the start (4) — Reusable prefix 4, edit 2, remainder 94 structurally recomputed. Small edit, large structural footprint.
• Edit part-way through (50) — Reusable 50, edit 2, remainder 48. About half the region stays reusable.
• Edit at the end (94) — Reusable 94, edit 2, remainder 4. Almost the whole region stays reusable.

Diagnostics

• [i] Structural eligibility only — Positions 4, 50 and 94 are figure-declared schematic values; they record where reuse stops structurally, not what any provider reused.
  Status: informational
• [?] Stable-first layout widens the prefix — Placing stable material before volatile material can enlarge the common leading region where semantic and policy constraints permit; hypothetical until tested.
  Status: potential
• [?] Realised economic effect — Unobserved in this schematic: availability, routing, expiry and pricing decide whether structural loss becomes realised cost.
  Status: unknown

Lineage: Rewriting history changes the rendered request, not the past computation. The earlier entry persists or expires by its own lifetime and routing.

Does not establish: Any realised cache loss, saving or latency change. A large structural radius can cost nothing if no entry was available; misses can come from routing or expiry.

Renderer viewer-v1.0 · ch09-mutation-radius

Chapter 10 — What a reduction keeps, removes, protects and defers

Scenario: constructed illustration: deterministic three-snapshot fixture demonstrating the comparison mechanics, not a validated pruning pass · Boundary: viewer-fixture.series-abc

Snapshot B accumulates tool output on top of snapshot A; snapshot C removes superseded output from the observed set while a compact summary and an anchor remain and the constraint record is protected. Every transition is derived from recorded item identities.

Capacity: input allowance 20000 (declared fixture policy)

Units: exact canonical bytes of the latest snapshot; tokens estimated as bytes / 4. approximation

Timeline

• Snapshot A: initial bounded context: 8,000.0 bytes (~2,000.0 est. tokens) — Bounded starting state: instructions, one request, tool surface, one result. 8,000 bytes against a 20,000 declared fixture policy.
• Snapshot B: tool activity accumulates: 19,300.0 bytes (~4,825.0 est. tokens) — Two turns of tool activity add requests, calls, reasoning and 8,300 further tool-result bytes. Nothing has been removed yet.
• Snapshot C: superseded output leaves the observed set: 13,000.0 bytes (~3,250.0 est. tokens) — Superseded outputs leave the observed representation while a compact summary and an anchor remain. The constraint record (Message 3) is protected and retained.

Comparisons

• Snapshot A: initial bounded context -> Snapshot B: tool activity accumulates: +11300 bytes — Transitions: added 8, changed 1. Category deltas (bytes): assistant +300; reasoning +1200; structure +300; tool_call +800; tool_result +8300; user +400. Growth only: +11,300 bytes. Standing definitions unchanged; accumulated tool results are the growth.
• Snapshot B: tool activity accumulates -> Snapshot C: superseded output leaves the observed set: -6300 bytes — Transitions: added 3, removed 2. Category deltas (bytes): compact +800; pointer +100; tool_result -7200. Net -6,300 bytes. Removed from the observed representation only: Message 7 (5,900, superseded output, retained in the session archive) and Message 9 (2,400, deferred, recoverable on demand). Added: compact summary S1 (derived, status labelled) and anchor P1 (unverified recovery). Message 11 (1,100) is newly observed, not reintroduced.

Diagnostics

• [i] Observed-representation change only — Absence from a later snapshot means removed from the observed representation, never deletion from storage.
  Status: informational
• [i] Protected material retained — Message 3 (constraint record, 1,500 bytes) survives the B-to-C reduction under the annotated protection; protection is declared in this fixture, not derived.
  Status: informational
• [i] Deferred, not deleted — Message 9 leaves the observed set as deferred with a recovery path; the fixture records deferral, not deletion.
  Status: informational
• [i] Pointer is not the artifact — Anchor P1 (100 bytes) names external material; recovery is unverified in this fixture.
  Status: informational

Lineage: Item identity is (category, location) as recorded. Equal bytes at different locations is unresolved identity, not continuity. Removal causes come from annotations only.

Does not establish: That any production pruning pass is safe, or that these reductions preserve what matters. This exercises the comparison instrument, not a validated operation.

Renderer viewer-v1.0 · ch10-pruning

Chapter 11 — A fluent summary that drops the decisive detail

Scenario: constructed illustration: deterministic synthetic fixture demonstrating preservation failure against a declared contract · Boundary: fixture comparison: declared source obligations vs compressed representation

A compact summary of migration material preserves the headline while dropping the version qualifier, mutating the identifier and softening the prohibition. Fluency is not fidelity.

Capacity: input allowance unknown (unknown allowance means unknown headroom; none invented); no headroom invented

Units: declared preservation obligations (4) and compressed-representation bytes are illustrative. not applicable; comparison is obligation-relative

Timeline

• Source — Four obligations: database is PostgreSQL version 18.2 (exact); migration identifier is 01947 (exact string); prohibition on modifying production migrations without explicit approval (exact force); qualification: claim of completion except one tenant (must travel with the claim).
• Compressed — Summary keeps the PostgreSQL headline; renders 18.2 as 18 (mutated); renders 01947 as 1947 (mutated); renders the prohibition as be careful with migrations (softened); drops the except-one-tenant qualification (missing).

Comparisons

• Obligation-by-obligation diff — Preserved 1 of 4. Missing: tenant qualification, exact prohibition force. Mutated: version digits, identifier digits. Compression ratio is reported alongside, never as fidelity.
• Recovery — Full text is retained outside the live window in this fixture, so the loss is recoverable through a validated pointer. The pointer is drawn as a reference, not as the evidence itself.

Diagnostics

• [!] Preservation failure — Declared obligations O2 (identifier), O3 (prohibition force) and O4 (qualification) do not survive in the compressed form. Assessed against the declared contract, not against fluency.
  Status: confirmed
• [OK] Headline claim — The PostgreSQL headline survives. That single survival is not global fidelity.
  Status: no-violation

Lineage: Changed representation does not imply changed source content. The source obligations are unchanged; only the representation lost them.

Does not establish: Prevalence of such failures, or any claim about a production summariser. Semantic equivalence is obligation-relative, not established by fluency.

Renderer viewer-v1.0 · ch11-compression-loss

Chapter 12 — One episode, several legal forms, one resident

Scenario: constructed illustration: one migration episode with four evaluated representations; residency and representation tracked separately · Boundary: fixture trace: which representation is resident now vs stored alternatives; legality checked against declared obligations

A migration episode keeps full text, dense rewrite, compact record and anchor as alternatives sharing one lineage. Policy selects the resident form for the current budget; stored forms cost management but not window space. An old anchor can remain exact while a recent log tolerates reduction.

Capacity: input allowance unknown (unknown allowance; resident costs are declared fixture units); no headroom invented

Units: one episode in four representations; bytes field carries declared relative resident cost, not measured tokens. not applicable; fixture ranks only

Timeline

• Generate — Alternatives built from the frozen original, each with lineage and obligation checks; generation is not selection.
• Demote — Pressure rises; policy demotes the resident form from dense to compact. Legal because the version conflict and constraint survive checks.
• Promote or retrieve — Later need promotes the stored dense form if resident; fetching from outside is retrieval with recovery obligations.

Comparisons

• Representation vs residency — The episode stays admitted while its resident form changes. Stored alternatives incur management cost without occupying the invocation window.
• Old vs stale — A six-month-old constraint stays exact; a one-minute-old deployment state can be stale. Age grants no transformation permission.

Diagnostics

• [!] Legality checked per representation — Compact is resident only because its checks pass every applicable obligation; producer claims are not proof.
  Status: confirmed
• [i] Pressure changes necessity, not permission — Budget pressure selects among legal forms; cache benefit cannot legalise an illegal one.
  Status: informational
• [?] Cross-representation disagreement — Coexisting forms can contradict; promotion across turns can change what appears true.
  Status: potential

Lineage: All four forms share one source lineage and obligation set; only the resident form consumes invocation capacity. Content identity is unchanged by the choice.

Does not establish: That more stages preserve more, or that age permits reduction. Each form needs independent obligation checks; tier count alone is not fidelity.

Renderer viewer-v1.0 · ch12-fading-representations

Chapter 13 — A pointer is not recoverability

Scenario: constructed illustration: tiny synthetic fixture with declared contract and frozen source · Boundary: fixture comparison: resident model input vs external store, plus recovery trace to a later invocation

Resident content leaves the model input and survives as an external artifact. A semantic cue carries usable meaning; an opaque pointer carries identity only. Only a validated recovery is recoverable.

Capacity: input allowance unknown (not applicable to this comparison; no window allowance invented); no headroom invented

Units: declared synthetic fixture items, labelled units. not applicable; no token measurement claimed

Timeline

• Resident — Payload present in model input; external store holds a frozen copy under a declared contract.
• Externalised — Payload removed; one semantic cue and one opaque pointer remain resident. Source retention alone proves nothing.
• Validated recovery — Cue identity resolved, version and integrity checked, payload admitted to a later invocation.
• Unverified recovery — Pointer rendered but never resolved; identifier and access unvalidated.

Comparisons

• Recovery contract (example) — Object identity, representation identity, version identity, locator, scope, horizon, integrity check; success means admitted to a later invocation, not merely found.

Diagnostics

• [!] Validated-recoverable item — Resolution, version and integrity checks recorded in the fixture trace; payload admitted to a later invocation.
  Status: confirmed
• [?] Unverified recovery — Opaque pointer rendered with no resolution, access or version check recorded.
  Status: potential
• [i] Source retention is not recoverability — Bytes surviving on disk with no tested resolution path; pointer drawn as reference, never as evidence.
  Status: informational
• [OK] Reference present, artifact unobserved — No claim treats artifact://incident-17 as observed content.
  Status: no-violation

Lineage: Departure changes residency, not source truth. Recovered content inherits the frozen version; a newer store state is a different representation.

Does not establish: That externalisation saves tokens or preserves behaviour; no cost, latency or prevalence claim is made.

Renderer viewer-v1.0 · ch13-externalise-working-set

Chapter 14 — Candidate miss is not admission failure

Scenario: constructed illustration: tiny fixture built around the chapter illustrative arithmetic (ten available, three needed, seven surfaced) · Boundary: fixture funnel: available vs pool vs retrieved vs admitted; rejections rest only on frozen fixture labels and recorded decisions

Ten available artifacts narrow to seven candidates, of which three are needed. One needed item never enters the pool, one stalls at recovery, one is rejected by policy: three separate locations.

Capacity: input allowance unknown (per-stage budget noted but unknown allowance invented for none); no headroom invented

Units: synthetic fixture items following the chapter ten/three/seven arithmetic. not applicable; occupancy reported as item counts, not token estimates

Timeline

• Available to candidate — Needed item N3 never enters the pool: candidate miss. Admission cannot repair it.
• Candidate to retrieved — Selected item N2 fails resolution under the recovery contract: retrieval failure.
• Retrieved to admitted — Recovered item N1 rejected by recorded policy rule R2 (over-budget extent): admission failure.
• Admitted — One needed item admitted as an exact section; extent judged against frozen obligations.

Diagnostics

• [!] Candidate-generation failure (N3) — Frozen fixture truth lists N3 as needed; pool record shows it absent. No inference from absence.
  Status: confirmed
• [!] Recovery-integrity failure (N2) — Resolution trace records version mismatch; payload never reached the assembler.
  Status: confirmed
• [!] Admission failure (N1) — Recorded policy decision R2 rejects the requested extent; assembler record confirms non-admission.
  Status: confirmed
• [-] Helpfulness of admitted item — No behavioural comparison run in this fixture; presence is not helpfulness.
  Status: not-evaluated

Lineage: Fragment identity is preserved: two excerpts from one artifact remain one source, not two corroborations.

Does not establish: That any policy improves behaviour or saves tokens; absence from the bundle is never read as evidence of irrelevance.

Renderer viewer-v1.0 · ch14-admission-funnel

Chapter 15 — A persisted guess is not an established fact

Scenario: constructed illustration: seeded-guess fixture with lineage to the originating tool observation · Boundary: fixture trace across a context reset: observation record vs generated note vs later invocation

A tool observation (migration test FAIL) prompts a guess (duplicated tenant IDs) recorded as root cause. After a reset the guess returns without its status or evidence and guides work as fact.

Capacity: input allowance unknown (not applicable to this lineage comparison); no headroom invented

Units: declared synthetic fixture records, labelled units. not applicable; no token measurement claimed

Timeline

• Observe — Tool reports FAIL with expected and observed values; recorded as observation with producer tool.
• Generate — Agent writes progress note Root cause: duplicated tenant IDs with status unverified hypothesis.
• Reset and readmit — Fresh invocation admits the note without status or evidence identity; test output no longer available.
• Propagate — Later work plans around the guess as fact; decisive contradiction not yet admitted.

Diagnostics

• [!] Status-preservation failure — Fixture note carries unverified status at write time and bare assertion at readmission; assessed against the frozen record.
  Status: confirmed
• [!] Evidence-lineage failure — Readmitted claim lacks the originating observation identity; reference alone treated as support.
  Status: confirmed
• [i] Observation vs interpretation kept distinct — Producer identities differ: tool for FAIL, agent for guess; producer is not truth status.
  Status: informational
• [-] Behavioural influence of the guess — No counterfactual removal run; mention is not proof the guess caused the plan.
  Status: not-evaluated

Lineage: Claim survival is not status or lineage survival. Persistence without readmission is available state, not context.

Does not establish: How often agents make such errors; this is a mechanism demonstration, not prevalence evidence.

Renderer viewer-v1.0 · ch15-generated-state-lineage

Chapter 16 — Correct memory can still be wrong context

Scenario: constructed illustration: tiny fixture with frozen present-task constraint and declared memory pool · Boundary: fixture trace: store vs pool vs bundle vs behaviour; helpfulness judged only by a controlled comparison

Current instruction forbids modifying the migration. Rich migration history is stored and surfaced, yet the present task needs none of it. Admitting it risks violating the binding present constraint.

Capacity: input allowance unknown (unknown allowance means unknown headroom; none invented); no headroom invented

Units: declared synthetic fixture items, labelled units. not applicable; no token measurement claimed

Timeline

• Stored — Four history items retained accurately; retention is not admission justification.
• Surfaced — Two items reach the candidate pool with source-kind and time metadata intact.
• Admitted — Empty memory contribution admitted; rejection recorded, store untouched.
• Positive control (not run) — A task genuinely needing history would have to fail under empty admission; unevaluated here.

Diagnostics

• [OK] Restraint shown — Frozen pool verified non-empty; recorded decision admits no memory for the present-only task.
  Status: no-violation
• [i] Stored, retrieved, admitted and used kept distinct — Fixture counters separate each stage; exclusion is not deletion.
  Status: informational
• [-] Helpfulness of any admitted memory — No matched with/without-memory behavioural comparison run; mention would not prove use.
  Status: not-evaluated
• [?] Present-constraint violation if admitted — History favouring modification conflicts with the binding current instruction; precedence belongs to later governance.
  Status: potential

Lineage: Memory enters through the common candidate interface with status and time preserved; retention never promotes an unverified item.

Does not establish: That memory helps or harms generally; any benefit claim here would need a matched behavioural evaluation.

Renderer viewer-v1.0 · ch16-memory-context-boundary

Chapter 17 — Tools charge context before and after execution

Scenario: recorded example: author-approved structural accounting of one captured invocation; sampling purpose unclassified · Boundary: opencode.v2.model_context (host model-context hook)

Exposed tool definitions occupy context before any call; admitted tool results occupy context after execution. In this capture the observation surface dominates the capability surface.

Capacity: input allowance 1000000 (observed model metadata)

Units: exact canonical bytes; tokens estimated as bytes / 4. approximation, not provider tokens

Timeline

• Before execution — 12 exposed definitions occupy 12,464 bytes regardless of use; one definition alone holds 2,638 bytes. Standing cost is paid before any call.
• Execution — Call representations add 12,046 bytes across many small items. Call size is not observation size.
• After execution — Admitted observations total 139,630 bytes, concentrated in a few large results. Concentration is structural only.

Diagnostics

• [i] Two-sided tool charge — Definitions 12,464 plus calls 12,046 plus results 139,630 of 213,655 counted bytes. Occupancy only.
  Status: informational
• [-] Relevance of the large results — Size does not establish irrelevance; a large result may carry the decisive fact. No task labels in this capture.
  Status: not-evaluated
• [?] Deferred definitions and compaction reservations — Unobserved at this boundary; shown as unobserved, not as zero.
  Status: unknown

Lineage: Transport role is not provenance: a user-role part may have been placed by the harness. Origin beyond captured form is unattributed.

Does not establish: Usefulness of any result, typical tool shares, or billing. One selected invocation, not a representative session.

Renderer viewer-v1.0 · ch17-tools-produce-context

Chapter 18 — Same facts, different representations, obligation-relative equivalence

Scenario: constructed illustration: deterministic fixture renderings of fixed migration facts, validated against frozen obligations before any model run · Boundary: fixture validation: each rendering checked against four frozen preservation obligations, not against model behaviour

Four renderings of the same migration facts preserve different obligations. A record omitting the SQLite rejection qualification is not equivalent to prose keeping it, even with the identifier intact.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: fixture obligations preserved (count of 4 declared obligations). not applicable; no token measurement in this fixture

Timeline

• Freeze — Four obligations frozen: identifier 01947 exact; backend PostgreSQL; blocked by test suite A; SQLite rejected after staging incident.
• Render — Deterministic renderers produce prose, record, compact note and locator from the same fixture state.
• Validate — Compact note fails the qualification obligation; locator fails three. Failure is recorded as transformation loss, not repaired silently.

Comparisons

• Equivalence is obligation-relative — Record and prose are equivalent under all four obligations; the compact note only under a three-obligation subset.

Diagnostics

• [!] Qualification loss in the compact rendering — SQLite rejection reason absent against the frozen four-obligation manifest. Identifier survival does not cure it.
  Status: confirmed
• [i] Pointer is not a carrying representation — Locator preserves 1 of 4 obligations; use requires a recovery contract, not shown here.
  Status: informational
• [-] Behavioural effect of each form — No model run in this fixture; preservation validation cannot predict lookup or explanation success.
  Status: not-evaluated

Lineage: All renderings derive from the declared fixture state; the fixture state is not a claim about any real migration.

Does not establish: Which representation any model uses best. No model ran here; this is preservation validation, not a behaviour result.

Renderer viewer-v1.0 · ch18-representation-obligations

Chapter 19 — Authority comes from outside the payload

Scenario: constructed illustration: synthetic deployment bundle with externally assigned standing; payload wording grants nothing · Boundary: fixture policy table: standing assigned from channel and policy, never inferred from item prose

Four fixture statements compete: an application constraint, a user edit request, a report carrying a version fact plus a hostile instruction, and a database disagreement. The hostile instruction is preserved as unauthorised data, not merged or obeyed.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: fixture statements under governance (count). not applicable

Timeline

• Detect and classify — Instruction conflict, attempted escalation, and factual disagreement identified as distinct kinds; nothing merged silently.
• Assign standing externally — Standing read from channel and policy table. Report prose claiming priority changes nothing.
• Resolve or preserve — Hostile instruction kept visible as unauthorised data; database pair kept as unresolved pending governing source and referents.

Diagnostics

• [!] Escalation attempt preserved, not granted — Report instruction to upload credentials classified as unauthorised data for this task by the external policy table.
  Status: confirmed
• [?] Standing of unattested report claims — Report origin unverified in this fixture; version 4.2.1 classified unknown, never inferred from assertive prose.
  Status: unknown
• [-] Database truth and instruction winner — Intended vs observed referents and the applicable policy rule are unfrozen here; no verdict is inferred from wording.
  Status: not-evaluated

Lineage: Payload text may describe a policy for inspection but cannot enact one. Rejected instructions and losing claims remain in the audit record.

Does not establish: Which database claim is true or which instruction wins in general. Resolution needs the governing policy, referents and observation times, frozen per task.

Renderer viewer-v1.0 · ch19-authority-inspector

Chapter 20 — A faithful capture that no longer licenses action

Scenario: constructed illustration: deterministic versioned fixture with explicit fixture truth (repository at C1 vs C5) · Boundary: fixture comparison: capture time C1 vs source version C5, validated by source-version mismatch

An observation faithful at C1 (backend SQLite, migration failing) is superseded by C5 (PostgreSQL, migration passing). Age alone does not decide; the source-version mismatch plus the operation's currency requirement does.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: fixture items under comparison. not applicable

Timeline

• C1: capture — Decision record read at C1: backend SQLite, migration failing, README agreeing. Observation time, source version and validity recorded.
• C2-C5: source moves — Decision record rewritten (PostgreSQL, migration passing); README rewritten twice. Admitted context unchanged.
• Action time: superseded — Agent configures SQLite against C5. Validator: source-version mismatch (C1 vs C5) against an operation requiring current state.

Comparisons

• Old but valid vs new but inapplicable — Kept visible in the viewer: a C1 item can remain eligible for a historical question while ineligible for a current-state action. Eligibility is operation-relative.

Diagnostics

• [!] Freshness violation for the current-state action — Source-version mismatch C1 vs C5 plus an explicit currency requirement for this operation. Fixture truth, not elapsed time.
  Status: confirmed
• [OK] Capture fidelity at C1 — The observation was faithful when taken. Staleness does not retroactively falsify the capture.
  Status: no-violation
• [?] Derived summary influence — The resident summary inherits C1 versions. Whether it influenced the action is unobserved in this fixture.
  Status: potential

Lineage: Derived state inherits versions: the summary reading all migration tests pass still points at the C1 run. A timestamp alone would not prove any of this.

Does not establish: A general time-to-live rule. Old material can remain valid; new material can be wrong. Staleness here rests on a validator, not on days elapsed.

Renderer viewer-v1.0 · ch20-freshness

Chapter 21 — Correct in Project B, wrong context for Project A

Scenario: constructed illustration: Project A/B fixture with explicit bindings, one shared contract, one transfer record and one unknown · Boundary: fixture compatibility check: candidate bindings against the Project A computation under a frozen sharing and transfer policy

The Project A task admits PostgreSQL, pytest and completed-migration facts. Project B material is excluded despite high relevance; the shared standard applies and one B incident is considered only under explicit transfer.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: fixture items by scope decision (count). not applicable

Timeline

• Bind — Computation bound to Project A; candidates carry attested or declared bindings, one explicitly unknown.
• Check — B backend and test command excluded as relevant but wrong-scope; shared standard admitted; B incident considered only as labelled transfer.
• Guard omission — Unknown item deferred under the frozen rule; the deferral is counted separately from a demonstrated mismatch.

Comparisons

• Transfer is not rewriting — The transferred B incident remains B evidence considered in A, not A state. Origin is retained.

Diagnostics

• [!] Wrong-world exclusion — npm test and SQLite bindings are Project B; excluded from the Project A computation despite vocabulary similarity.
  Status: confirmed
• [i] Shared and transferred crossings — Shared contract eligible in both; B incident eligible only under the explicit transfer record with origin retained.
  Status: informational
• [?] Unknown binding — One candidate binding unattested; held as unknown per policy, not inferred from path resemblance or prose claims.
  Status: unknown

Lineage: Bindings state asserted applicability; compatibility rules decide eligibility. A transferred item keeps its origin scope and does not gain authority or freshness.

Does not establish: A general scoping policy or a security boundary. This is correctness under non-adversarial contamination, not access control.

Renderer viewer-v1.0 · ch21-right-world

Chapter 22 — Assemble for the Task: ranking is not assembly

Scenario: constructed illustration from the chapter's own fixture numbers. No ecological or behavioural claim; prevalence unknown. · Boundary: Allocator boundary only: eligible pool, declared verdicts, relationships and budget in; selected set or structured failure out. Upstream verdict correctness and downstream behaviour are unobserved.

Mandatory material costs 4,600 against a 4,000 ceiling (excess 600), so no valid bundle exists and the correct output is a structured refusal, not a silent omission. Ranking cannot express gates, closure, coupling, alternatives or infeasibility.

Capacity: input allowance 4000 (declared fixture usable input budget, standing instructions included)

Units: fixture tokens (declared costs, not provider tokens). fixture-declared costs from the chapter opening pile

Timeline

• Unsatisfiable request — Mandatory closure 4,600 > budget 4,000 gives infeasible, excess 600, no bundle; at 4,600 feasible.
• Relevance vs legality — Wrong-project config at 0.99 and stale compact 100 tokens at 0.9 outrank legal options; current full form is 600 at 0.75. No penalty weight buys back legality.
• Dependencies price the closure — Reference 20 + resolver 650 = 670 first use, 20 for the second; a 100-token item needing a 900 dependency costs 1,000 vs a flat 500.
• Coupled groups — Claim 120 tokens admitted only with its 80-token qualification; one without the other states something false.
• One content, several forms — Full 900, compact 300, anchor 90, reference 20 plus resolver are alternatives with distinct obligations, not a fidelity ladder.
• Slack is valid — Used tokens are within budget; the ceiling is not a target and no filler is admitted.

Comparisons

• Ranking vs assembly — Naive top-K omits low-scoring mandatory material and emits a plausible invalid bundle; the assembler reports infeasibility instead.

Diagnostics

• [i] Infeasibility is the correct output here — Mandatory cost 4,600 exceeds budget 4,000 with excess 600 under the declared accounting. Emitting a truncated bundle would be the failure.
  Status: informational
• [?] Blended-score repair fails structurally — Unless the penalty is absolute it can be outbid by relevance; an absolute penalty is a constraint written as a number.
  Status: potential
• [-] Behavioural utility of any feasible bundle — Structurally valid is not behaviourally good; helpfulness needs behavioural evidence, none collected here.
  Status: not-evaluated
• [?] Production prevalence of assembly traps — Corpus of real sessions empty; constructible does not mean common.
  Status: unknown

Lineage: Selection consumes upstream eligibility verdicts without re-deriving them; ordering and rendering can change exact cost afterwards.

Does not establish: Optimality, behavioural benefit, upstream verdict correctness, or how often assembly traps occur in real work. Structural validity proves compliance with supplied verdicts only.

Renderer viewer-v1.0 · ch22-assemble-task

Chapter 23 — What the compiler admitted, rejected, and why

Scenario: constructed illustration: small synthetic candidate set in the chapter's vocabulary, demonstrating the decision record. Not a conformance run; historical 42-case results are unchanged and live elsewhere. · Boundary: compiler boundary: request, candidates and policy in; bundle and trace, or named refusal, out. No files read, no model called.

Seven candidates against a 4,000-token ceiling. Four admitted as a legal bundle; three rejected with named reasons (scope, freshness, authority). The claim-plus-qualification pair travels together or not at all.

Capacity: input allowance 4000 (declared fixture policy ceiling)

Units: fixture tokens; render cost is exact within the fixture, not provider tokens. fixture-declared

Timeline

• Validate before optimising — Hard gates first: scope, freshness, authority. Scoring never buys legality.
• Close dependencies — Incident reference admitted with its resolver definition; without it the reference would fail closed.
• Keep the group together — Claim migration completed (120) admitted only with its qualification except one tenant (80).
• Slack is valid — Bundle renders at 3,400 of 4,000. The ceiling is not a target; no filler is admitted.

Comparisons

• Ranking vs assembly — A 0.99-relevance item from the wrong project outscores the governing constraint under rank-fill, and is rejected under assembly. Same candidates, different rule.

Diagnostics

• [i] Admitted bundle is legal, not proven useful — Structural checks pass on the trace. Usefulness needs transport plus behavioural evidence, neither shown here.
  Status: informational
• [OK] Distractor check on this bundle — No labelled-harmful item admitted in this small fixture. The historical corpus still admits five distractors and two labelled-harmful items; that result is unchanged.
  Status: no-violation
• [?] Eligibility derivation — Scope, freshness and authority verdicts are supplied inputs here. Whether a resolver could derive them is not tested.
  Status: unknown

Lineage: One content, several representation options: the incident report ships as full text, compact form, anchor and bare reference. Each is a distinct candidate with its own cost; the compiler picks at most one.

Does not establish: Optimality, completeness, or correctness of the declared judgements. The compiler enforces supplied eligibility; it does not derive it.

Renderer viewer-v1.0 · ch23-compiler-trace

Chapter 24 — What a Compilation Proves: conformance, completeness, optimality, parity

Scenario: recorded result: finite-corpus structural evidence with named counterexamples. No behavioural or ecological claim. · Boundary: Compiler structural boundary only: fixtures, engine, validators and frozen outputs. Upstream verdict correctness, provider behaviour and model use are unobserved.

Fourteen families at three budgets give 42 compilations: 34 bundles, 8 refusals, each matching its fixture-expected status. The audit finds no false success or refusal inside the corpus, while a constructed case outside it demonstrates a false refusal, defeating completeness.

Capacity: input allowance unknown (per-stage fixture budgets (tight, medium, roomy); no single byte budget); no headroom invented

Units: compilations (finite-corpus outcomes; not bytes). not applicable; counts are corpus outcomes, budget fit checked in declared units

Timeline

• Finite corpus — 14 families x 3 budgets = 42 compilations; 34 bundles, 8 refusals, all match fixture-expected status.
• Exhaustive audit — All 34 bundles satisfy the stated model; none of the 8 refused cases has a feasible set in it.
• Completeness counterexample — Greedy picks the dearer standalone form, then cannot fit the required item plus resolver; the enumerator finds the shared-resolver set. False refusal under the declared model.
• Optimality counterexample — A 670-token reference where a 400-token full form exists already defeats cost optimality.
• 252-compilation construction run — Six strategies x 42 cases. Compiler: 42 expected-status matches, 0 illegal, 0 broken; top-K: 34, 15 illegal; hard-gated greedy: 34, 0 illegal, still 1 broken dependency and 1 broken group.
• Parity over frozen outputs — Second implementation reproduced all 42 frozen outputs with no semantic or serialisation mismatch and no budget violation; parity is agreement, not correctness.

Comparisons

• Hidden-label outcomes (not behaviour) — Distractor-labelled admitted: compiler 5, hard-gated 9, weighted 17, top-K and dump 18. Harmful-labelled: compiler 2, as do top-K and hard-gated. Labels are authored, not proof of harm.
• Authority gate never discriminates — Zero authority violations for every strategy including dump: implemented and respected, never shown to discriminate.

Diagnostics

• [!] No false success or refusal inside the corpus — Finite audit over the 42 cases under the shared cost and exclusivity assumptions. Inherits the one-form-per-identity assumption the chapter calls too strong.
  Status: confirmed
• [!] Greedy procedure is not complete — One constructed false refusal outside the corpus under the declared model. Frequency undemonstrated; the case remains exploratory until pinned in the register.
  Status: confirmed
• [i] Legal admits labelled distractors and harm — Compiler admitted 5 distractor-labelled and 2 harmful-labelled items, e.g. an in-scope 0.55-relevance 130-token note above threshold. Harmful-labelled is not demonstrated harmful.
  Status: informational
• [-] Behavioural benefit and real-world frequency — Synthetic counts are not prevalence estimates and prove no behavioural ranking.
  Status: not-evaluated

Lineage: Construction run (252 compilations) is historical evidence from the earlier implementation; parity (42 frozen outputs) must not be presented as a fresh benchmark of the newer one.

Does not establish: Universal soundness, completeness, optimality, input correctness, behavioural benefit or real-world frequency. Forty-two matches do not prove a forty-third.

Renderer viewer-v1.0 · ch24-compilation-proves

Chapter 25 — Correct compile is not correct delivery

Scenario: constructed illustration of the delivery distinctions (injection, observation, reconciliation, liveness). Historical wave outcomes are book results recorded in the research register, not reproduced here. · Boundary: host model-context boundary only. Provider-wire content and model-internal use are unobserved and never implied.

Two cases side by side. Verified case: render embedded unchanged, block injected once, live observer saw it, hashes reconcile. Failed case: observer never established liveness, so the comparison is inconclusive, not negative.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: fixture bytes across the three byte domains (render, transport block, observed text). not applicable; reconciliation is byte-exact within the fixture

Timeline

• Compile — Bundle rendered; render bytes fixed for the fixture.
• Inject (verified case) — Block injected once; idempotent single assignment; no conflict.
• Observe (verified case) — Observer registered after the injector; liveness established independently; expected block observed once.
• Observe (failed case) — Observer liveness never established. Missing observation is not observed absence; the run is inconclusive.

Comparisons

• Intended vs observed (verified) — Render embedded unchanged; hashes reconcile. Establishes hook-boundary equivalence only.
• Intended vs observed (failed) — Reconciliation not attempted: no live observation exists to compare against. Static checks passing would not repair this.

Diagnostics

• [!] Verified case reconciles at the host boundary — Injection succeeded, observer live, block observed once, bytes reconcile. Says nothing about provider-wire delivery.
  Status: confirmed
• [?] Failed case is inconclusive — Observer liveness missing. Silence is not proof of absence; the behavioural question is untested for this run.
  Status: unknown
• [-] Provider delivery — Unobserved. The viewer never describes the host boundary as provider-wire delivery.
  Status: not-evaluated

Lineage: Three byte domains stay apart: compiler render, transport block, observer text. Conflating any two manufactures a result.

Does not establish: Provider-wire identity, provider-side rewriting, cache decisions, or model internals. Only the host boundary is observed.

Renderer viewer-v1.0 · ch25-delivery

Chapter 26 — Did the Context Help? influence is not utility

Scenario: recorded result: six-task ladder plus a transport-verified live wave at the score floor. Reader identity unpinned in the ladder; no ecological claim. · Boundary: Ladder: prompt-condition comparisons in one harness with direct insertion, not runtime injection. Live wave: host-boundary transport verified separately. Model internals unobserved.

No-context vs compiler bundle: all six full responses differed, four of six actions differed, scores improved on two, worsened on one, unchanged on three. The second live wave verified transport on all 24 runs yet recorded no measured difference, all scores at zero.

Capacity: input allowance unknown (not applicable to this comparison); no headroom invented

Units: tasks (score movement, no-context vs compiler bundle; ladder of six). not applicable; movement counts

Timeline

• Ladder scale — 6 tasks x 7 conditions = 42 calls, plus 4 surgical variants and 8 repeats = 54-run main record; 46 matched first calls; separate 7-call transfer probe.
• Structural edge without behavioural edge — Compiler vs hard-gated greedy: 3 of 6 digests identical; other 3 differ with no action or score difference. Compiler vs oracle: 4 of 6 identical, 2 differ, no change.
• Calibration control invalid — Zero under every condition because the grader keys on an unnamed value field while the prompt asks for the target field; retained as instrumentation defect.
• Reader-transfer probe confounded — Second reader abstained in all 7 on the mixed-pool medium-budget rerun, but 5 of 7 bundles changed with the budget; only the no-context and oracle bundles match.
• Second live wave at the floor — 8 fixtures x 3 conditions = 24 planned, executed and transport-verified; scores zero everywhere, same two harm flags, all parsed, required content absent, evidence use zero. First wave of 24 contributed nothing: transport failed every run.

Comparisons

• Structural vs transport vs behavioural — Structural checks pass and transport verifies delivery, yet measured treatment effect is zero in the live wave: verified delivery is not measured effect.

Diagnostics

• [!] Bundle condition associated with decision and score movement — Actions differed 4 of 6; scores 2 up, 1 down, 3 tied as paired cases. Unpinned reader alias weakens causal attribution.
  Status: confirmed
• [?] Calibration control measures nothing — Uniform zero reflects the target/value contract mismatch, not extraction failure or interference. Failed measurement, not a negative result.
  Status: unknown
• [!] Transport-valid null on recorded measures — Second live wave: no difference among none, distractor and oracle on score, harm, parse, required-content and evidence-use; every score at floor zero. Valid negative on measured variables only.
  Status: confirmed
• [-] Compiler advantage, oracle benefit, candidate cause, generality — No decision or score distinction compiler-vs-greedy or oracle-vs-compiler here; surgical series began at floor; readers saw different bundles; no ecological evidence. Unsupported, not disproved.
  Status: not-evaluated

Lineage: Ladder bundles were frozen outputs from the construction experiment, digest-checked, with no compilation during inference; live waves are separate experiments and must not be merged.

Does not establish: Population effects, compiler behavioural advantage, candidate-level causation, cross-reader generality or production prevalence. One surplus of improvements is not an effect estimate.

Renderer viewer-v1.0 · ch26-did-context-help

Chapter 27 — The complete chain, with the evidence stops marked

Scenario: constructed synthesis: reuses the pilot scenes as linked cases. Ecological evidence remains empty; integration of separately collected records is display, not an end-to-end qualification. · Boundary: full chain: available information to behavioural evaluation; each stage names its own boundary

Follow one item across the recorded path: available, observed, candidate, eligible, selected, represented, assembled, rendered, transported, host-observed, evaluated. The viewer shows where the evidence stops at every stage.

Capacity: input allowance unknown (per-stage; see linked scenes); no headroom invented

Units: stages with recorded artifacts in the pilot (of 11 lifecycle stages). per linked scene

Timeline

• Available -> observed — Chapters 1-3. The inspector shows what one capture held; the corpus of real sessions remains empty.
• Observed -> candidate — Chapters 13-14. Retrieval supplies candidates; admission is task-relative and marginal.
• Candidate -> admitted — Chapters 19-23. Gates before optimisation; dependencies closed; groups kept; slack valid.
• Admitted -> rendered -> transported -> observed — Chapters 18, 24-25. Exact render cost; three byte domains; reconcile at the host boundary only.
• Observed -> useful — Chapter 26. Influence is not utility. Frozen behavioural results are referenced, never altered.

Diagnostics

• [i] Compiler decisions beside viewer diagnostics — Trace reason codes and gate verdicts render together; each keeps its own evidence status.
  Status: informational
• [?] Ecological prevalence — No genuine-session corpus. Every prevalence hypothesis in the book says not yet measured at the point it is made.
  Status: unknown
• [-] End-to-end qualification — Displaying separately collected records together does not qualify the pipeline end to end.
  Status: not-evaluated

Lineage: Move backwards along lineage from any admitted item: why it entered, what changed its representation, where it was observed, and where measurement stops.

Does not establish: That the current-version pipeline was qualified end to end. Separately collected records displayed together are not a joint qualification.

Renderer viewer-v1.0 · ch27-lifecycle