Representation Is Part of Context

Two bundles carry the same migration facts. The first is prose: the migration uses PostgreSQL, its identifier is 01947, it remains blocked by test suite A, the team rejected the SQLite fallback after the staging incident. The second is a labelled record with the same four facts in named fields. Asked which identifier belongs to the unresolved migration, the model answers from the record and fumbles in the prose — the digits sit mid-sentence beside another number and bind to the wrong noun. Asked why the SQLite fallback was rejected, the model answers from the prose and starves on the record, whose reason field kept the headline and dropped the causal qualification. Nothing was selected differently. Everything was represented differently. Selection finished, and the context still was not the same.

Information identity does not imply representation identity.

That sentence is the chapter’s first durable principle. Chapter 18 focuses on a single word of the book’s definition — represented — and asks what exact form admitted information should take when it enters the computation.

Information, representation, serialisation

Three concepts, kept apart because every confusion between them has a cost:

UNDERLYING INFORMATION

what facts, relations, constraints,
states, or evidence exist

        ↓

SEMANTIC REPRESENTATION

which structure and relationships
are made explicit

        ↓

SERIALISATION

how that representation is encoded
into model-visible tokens

UNDERLYING INFORMATION
          │
          ↓
 SEMANTIC REPRESENTATION
     ┌────┼─────┐
     ↓    ↓     ↓
   prose table triples
          │
          ↓
    SERIALISATION
   JSON / XML / text
          │
          ↓
      TOKENS
          │
          ↓
       MODEL

A semantic representation determines which distinctions, relations, groupings, and structure are made explicit: narrative prose, key-value state, typed records, tables, relation triples, adjacency, event sequences, outlines, reference plus anchor. No giant taxonomy is built; only forms that expose different properties earn a place. Serialisation is the concrete token-level encoding of whichever representation was chosen: a record structure may arrive as JSON, XML, YAML, TOML, or plain key-value text; a table as Markdown, CSV, HTML, or SQL-like rows. The distinction matters because changing JSON to XML while holding fields constant asks whether syntax affects cost or use, while changing prose to a table asks whether organisation affects reasoning. Those are different experiments, and the chapter runs both without confusing them.

One confusion is refused up front. A JSON object can be well formed and factually wrong; a paragraph can be unstructured and perfectly accurate. Syntactic validity is not semantic correctness, and a structured representation carries no higher authority for being structured. Chapter 19 owns authority. This chapter owns form, and form never votes.

Start with operations, not formats

A chapter that opens with a list of syntaxes becomes a syntax survey. This one opens with the operations the model must perform:

exact lookup
compare records
filter
aggregate
follow a relation
explain a rationale
apply an update
detect a contradiction
preserve provenance

Then it asks which representation makes each operation easiest or hardest. The canonical follows:

Representation utility is operation-relative.

A table makes comparing five deployment states easy and understanding why the architecture changed awkward. Narrative prose makes causal explanation natural and finding the exact migration identifier for row seventeen harder. A labelled record makes the update task surgical and multi-hop traversal clumsy beside triples. Neither observation generalises beyond its operation, which is why the chapter averages nothing across operations and forbids any conclusion shaped like JSON-beats-XML. The fixture sketch makes the point concrete before any run: one incident set rendered three ways, with lookup going to the record, explanation going to the prose, and the update going to whichever form flips one field without touching its neighbours. If those three splits do not appear, the fixture is too kind to one form and gets rebuilt. External research warns against that simplification independently: effects move with model, task, data scale, context length, operation, and schema complexity. The correct question is always what representation exposes the structure this computation needs at an acceptable cost — on this task, for this model, at this scale, under this serialisation.

Exact state favours explicit fields, as Chapter 7’s exactness requirements predict: identifiers, ports, versions, and statuses survive better where field identity is labelled. But the useful mechanism may be the labelled field rather than the curly braces, and the experiment is designed to tell them apart — key-value text sits beside JSON as a condition, so syntax and structure vary independently. Narrative resists aggressive structuring in the opposite direction. “The team rejected approach B because it fixed the immediate race but introduced an ordering dependency in recovery” compresses into a decision-plus-reason record that keeps the headline while losing the causal relationship or its qualification. Structure removes ambiguity and nuance together, and conversion into validating fields is never treated as lossless merely because it validates.

Relations get their own family because prose hides what triples expose. “A depends on B; C replaces A; D was tested against C” becomes three typed edges with explicit endpoints, which may help traversal at the price of tokens and narrative. Graphs receive one precision cut: no text model receives an abstract graph unless the runtime genuinely supports one, so graph-as-semantics always arrives as edge lists, triples, or JSON — the chapter’s two-layer model applied to itself. Tables receive the symmetric cut. A table is conceptually two-dimensional and the model receives a sequence, so row order, column order, delimiters, headers, and repeated structure do the encoding work. No table preserves spatial structure magically; it spends tokens to describe it. That is exactly where the external table literature belongs.

What the table literature actually shows

Table Meets LLM, a WSDM 2024 full paper, built the SUC benchmark for structural understanding capabilities — partition and parsing tasks plus lookup and retrieval tasks — and varied input designs including serialisation across CSV, JSON, XML, Markdown, HTML, and spreadsheet formats, with and without partition marks, format explanations, and role prompting. On GPT-3.5-era models, markup languages outperformed separator-joined text, HTML led with explanations and role prompts attached, and delimiter-separated formats trailed HTML by nearly seven points in the authors’ reporting; downstream tabular tasks gained between roughly one and six points from their structural prompting. The chapter imports the narrow conclusion the design supports: performance on structured-table tasks can vary with how the same table information is presented, including content order and boundary marking. The model generation, the Wikipedia-table populations, and the absolute rankings stay in the paper. Nothing here generalises GPT-3.5 results to 2026 models.

LongTableBench, in the Findings of EMNLP 2025, scales the question to long contexts: 5,950 QA instances across seven real-world table formats and eighteen domains, inputs to 128,000 tokens, fifty-two tested models from general to table-specialised to reasoning-enhanced. Only the strongest models hold performance as length and format diversity grow, and end-to-end models beat compression-based approaches on tasks needing semantic integration. The chapter uses it for one interaction claim: format sensitivity moves with task, model capability, and context length together. No winning format is extracted, because the paper offers none that survives those interactions.

Format Matters, at LREC 2026, is handled with the care its design demands: it studies generated output representation — JSON, XML, and inline key-value for SLU and NER tasks across thirteen smaller models — not input-context representation. Its observed gaps are real and model- and dataset-dependent, with compact key-value forms often leading on harder sets and a dev-set selection policy nearly matching an oracle chooser. The chapter takes exactly one lesson across the input/output boundary: representation format can interact strongly with a model and task even when the semantic target is held fixed. Output-generation results are never cited as proof that any input format improves reasoning.

Provider documentation is graded lower still, and used accordingly. Anthropic’s current prompt-engineering guidance recommends XML-style tags for separating instructions, context, examples, and inputs, with nested document structures carrying content beside source metadata for long multi-document work. That is first-party engineering guidance for explicit boundaries and hierarchy — useful, bounded, and not evidence that XML beats JSON, Markdown, or prose anywhere outside the guidance’s own scope. OpenAI’s Structured Outputs documentation proves something adjacent and valuable: schema-constrained generation can be enforced at the API boundary, with type safety and explicit refusals as the payoff. It establishes machine-integration value for typed schemas. It says nothing about whether JSON input reasons better, and the chapter never asks it to. MCP’s structured content, already established in Chapter 17, returns as the practical illustration: the same tool observation available as text, schema-validated structured data, resource link, or embedded resource is one observation with several admittable forms, and the question is now which form enters model-visible context for which operation.

Lossless changes, engineered equivalence

Lossy transformation belongs to Chapter 11, so the main experiment prefers intended-lossless re-encoding: typed record to JSON, XML, or key-value text with all fields intentionally retained. But “same semantics” is engineered, never assumed. Asking a model to rewrite prose as JSON and treating the outputs as identical confounds the experiment with conversion quality — the rewrite can omit, mutate, add, or reinterpret facts before the representation question is even asked. The fixture inverts the pipeline:

canonical truth
    ↓
deterministic renderer
    ↓
representation

Each fixture is built from a canonical ground-truth record of incidents, decisions, constraints, relations, and provenance. Deterministic renderers produce the prose, key-value, JSON, XML, table, and triple conditions with no model call anywhere in condition construction, and an evaluator-side fact manifest verifies every required atomic fact and relationship survived each renderer with no additional semantic claims. A format that cannot satisfy the manifest for a fixture leaves that fixture rather than faking equivalence, and task families are chosen so the same underlying state genuinely admits several sensible forms: state and record families across prose, key-value, JSON, XML, and YAML or TOML only where they add a distinct property; repeated-record families across prose lists, JSON arrays, JSONL, Markdown tables, and CSV; relation families across prose, triples, adjacency lists, and structured JSON. Causal narrative is never forced into a table to complete a matrix. The representation set stays bounded — prose, key-value, JSON, XML, Markdown table, triples where relational, CSV where tabular — because the fifteenth syntax teaches nothing the fifth did not.

What each form costs and keeps

Token cost is measured in bytes and characters first, with model-specific token counts where the tokenizer is available and explicitly labelled estimates otherwise — Project Context’s telemetry discipline, applied to punctuation. Structural syntax is priced without moralising: the delimiters and quoting around two JSON fields may buy machine parseability, nesting, and schema compatibility, or they may be pure overhead for this model and task, and the measurement tells which. Repeated field names get their own mechanism because the economics are concrete: a JSON array restates every key on every object while a table states column names once, which hands the table condition a real cost advantage at scale — just as CSV’s compactness trades away the explicit boundaries and types the table keeps. Count it once on a realistic shape: twenty incident objects with six keys each repeat one hundred and twenty key strings plus their quoting and punctuation, while the equivalent table states six headers once and pays only delimiters per cell. At small sizes the difference is noise; at hundreds of rows it decides the budget. The experiment measures both ends rather than asserting either. Hierarchy follows the same treatment. Nested XML or JSON expresses containment directly where flat forms pay in repeated identifiers, flattened names, and implicit grouping, so one nested-state fixture tests whether hierarchy itself matters rather than letting the whole chapter hinge on it.

Field names trade clarity against tokens in the open: a bare boolean hides what a descriptive key declares, and deliberately terrible names are excluded as unrealistic while sensible alternatives compete honestly. Explicit types get a fixture where the distinction decides the task — string against number, and above all the null family, where a null field means known-but-unavailable, an absent field means not represented, and zero means zero. The book’s unavailable-is-not-zero discipline becomes a representation test: any form that collapses those three fails the task that needs them, and no form earns advocacy for passing. Provenance travels structurally — claim beside source beside status — which prepares Chapter 19 without pre-empting it, and conflict is preserved rather than resolved: a summary cell reading one database erases what a two-source rendering keeps, and the representation-fidelity question ends exactly where authority begins. Referent ambiguity gets the same honest split: explicit records can disambiguate speaker, recipient, and owner where a pronoun blurs them, but in the deterministic fixture the mapping is exact while in production it would be a normalisation judgement — two situations, two risk profiles, never merged.

Edit, convert, normalise

Reading is half the chapter; the other half is writing back. The update task presents a state representation plus an observation — migration 01947 now verified — and asks for the updated state with everything unrelated preserved: target field changed, neighbours untouched, identifiers intact, status transition correct. Edit locality is scored as fields rather than characters, because rewriting a paragraph and flipping one key are different operations that textual edit distance cannot tell apart. Round-trip stability extends the question across one, three, and five successive edits on structured working state, watching unrelated information survive repeated read-update cycles. This is an explicit state edit, not a second compaction study, and Chapter 11 stays closed. Machine interoperability is measured on a separate ledger — deterministic parsability, schema validity, round-trip ability — so that an application can still choose JSON for integration value even where reasoning accuracy ties. Parseability never votes on comprehension.

Normalisation receives the chapter’s strongest warning because it looks like plumbing. A compiler that converts tool output, memory, artifacts, and agent state into one common internal representation may drop fields, rename concepts, merge entities, change types, erase provenance, or resolve ambiguity wrongly — so normalisation is evaluated like any other context transformation, with source-native, canonical, and hybrid as the visible trade. Source-native keeps tool JSON as JSON and prose as prose: less transformation risk and higher source fidelity against heterogeneous, inconsistent operations. Canonical normalisation buys uniform operations, explicit fields, and consistent provenance against conversion loss, cost, and schema mismatch. The likely production shape is hybrid — typed state beside short rationale beside repeated-record tables beside relation references beside raw evidence where necessary — treated as a hypothesis about matching form to information type, never as a declared winner. Sketch what that bundle looks like on the migration fixture so the hypothesis stays falsifiable: four labelled fields for the exact state, three sentences of causal rationale for the rejected fallback, one five-row table for the deployment states under comparison, two triples for the blocking relations, and the raw compiler tail attached by reference rather than pasted. Any hybrid condition that cannot point at which part serves which operation is not a hybrid but a pile. An optional third experiment earns its place only if the first two leave room: deterministic against model-generated conversion of source-native context into canonical form, scored with Chapter 11’s omission, mutation, addition, provenance-loss, and type-loss metrics to show that representation creation itself can fail. If the chapter stands complete on two experiments, conversion waits for implementation.

Proposed experiments

Canonical fixtures, deterministic renderers, fact manifests, and fixed field and record ordering (Chapter 6 controlled, permuted only in a secondary robustness check) govern everything below. Task families run per operation, never averaged into a global winner: exact lookup rewarding labelled access without making prose hopeless; record comparison rewarding alignment; relation traversal over small graphs rewarding edge correctness and multi-hop results without becoming a GraphRAG study, since all facts are supplied; causal explanation rewarding required claims, unsupported-claim avoidance, and qualification survival so schemas cannot win by default; state update rewarding precision and collateral restraint. Irrelevant-field sensitivity grows controlled noise — four relevant fields against zero, ten, fifty irrelevant ones — as the representation-specific analogue of Chapter 5 interference, because structure does not abolish noise. Scale runs small, medium, and large with values fixed after fixture construction and before results, reporting accuracy, cost, and failure rate per size. The mechanism under test is explicit: verbose explicit forms may win small on clarity and lose large on repetition cost, while compact syntaxes pay parsing overhead that only amortises at volume. Averaging those regimes would hide exactly the crossover the policy needs. Model dependence gets a primary reader plus one bounded transfer reader for the serialisation experiment: stable rankings justify generic policy, reversals are reported as findings. Five engineered traps keep every condition honest: near-identical identifiers with leading zeros and coercible types; unknown against zero and not-run against failed; relation direction in both directions; dual-source identical facts answerable only by source attachment, with correctness explicitly deferred to Chapter 19; shared-outcome decisions with divergent rationales, so gist-only representations fail the why-question they deserve to fail.

Experiment 1 — semantic representation varies organisation with facts constant: narrative prose, labelled records, tables where naturally tabular, triples or adjacency where naturally relational, a task-shaped hybrid whose token cost and construction assumptions are measured rather than admired, and an oracle representation built with ground-truth knowledge as ceiling. It asks whether making structure explicit changes behaviour.

Experiment 2 — serialisation varies encoding with abstract structure constant: key-value text, JSON, XML, Markdown records where structurally valid, compact delimited or CSV forms for repeated records — never forcing tables onto hierarchies whose flattening changes semantics. It asks whether token-level encoding affects cost or use, at several sizes, across two readers.

Structured-output validity is never the success metric. A well-formed answer object proves nothing about whether the input representation was used; task correctness, exact-field use, relation correctness, update precision, and constraint adherence decide, with parseability kept on its own ledger.

What the laboratory records

Nothing is implemented, and the assessment stays parsimonious: source and episode identity separated from representation identity, most plausibly as metadata on the existing immutable ContextItem rather than a new hierarchy — representation identifier, source reference, semantic kind, serialisation, version, token count, provenance. Stage 0 anticipated exactly this split, and the chapter confirms the anticipation without building on it. Representation lineage travels with the record — tool result to normalised record to table render — so later failures attribute correctly among wrong source, lossy normalisation, and confusing render. Future intervention experiments must carry the same triple the fixtures carry: underlying source identity, representation condition, serialisation condition, lest two renders of one source be mistaken for different evidence. The corpus position is one verified fact: Project Context holds zero genuine sessions, so no claim is made about how much real agent context is JSON, how often tables appear, or which representation dominates. Later captures may ask what forms dominate real context, how much prose is structured at the source, how often structured results are flattened, how much repeated syntax exists, and how often forms change mid-trajectory — subject to what the V1 boundary can distinguish, which the chapter does not overstate.

Falsification is stated per the usual rule that negative results remove machinery. Negligible behavioural effects on capable models, stable rankings favouring one default, small task differences, costly hybrids, lossy normalisation, source-native parity, parsing-only structured wins, economically negligible token gaps: each simplifies the compiler. Labelled key-value matching JSON, XML, and tables across project-state tasks deletes the format optimiser. Source-native tool results winning deletes normalisation for neatness. A hybrid winning one niche stays local to it. The objective was never a representation subsystem. It was discovering whether one is needed.

Structure makes relationships explicit at a price in tokens, and neither truth nor authority comes with the packaging. A polished record claiming one database does not outrank a plain user instruction naming another; a confidence score beside a memory claim creates no authority. Representation can carry the metadata governance needs — including the source boundaries a merged record set must not dissolve — but it cannot create what it carries. Once multiple well-formed sources share one bundle, form has done all it can do. What remains is disagreement, and disagreement needs a judge.

References

• Sui, Y., Zhou, M., Zhou, M., Han, S., Zhang, D. “Table Meets LLM: Can Large Language Models Understand Structured Table Data? A Benchmark and Empirical Study.” Peer-reviewed, WSDM 2024 (ACM DOI 10.1145/3616855.3635752). SUC structural-understanding benchmark; serialisation and boundary-marking effects with GPT-3.5-era models; downstream tabular-task gains. https://arxiv.org/abs/2305.13062
• Li, L., Tian, J., Chen, H., et al. “LongTableBench: Benchmarking Long-Context Table Reasoning across Real-World Formats and Domains.” Peer-reviewed, Findings of EMNLP 2025. 5,950 QA instances across seven formats and eighteen domains to 128K tokens; fifty-two models; format sensitivity interacting with task, capability, and length. https://aclanthology.org/2025.findings-emnlp.638/
• Lepagnol, P., Ghannay, S., Gerald, T., et al. “Format Matters: A Critical Evaluation of Output Formats for Prompting LLMs in SLU and NER.” Peer-reviewed, LREC 2026. JSON/XML/key-value output-format gaps varying by model and dataset; dev-set selection near oracle. Used strictly as output-format evidence; the input-side lesson is the narrow interaction claim. https://lrec.elra.info/lrec2026-main-593
• Anthropic. “Prompting best practices.” First-party documentation, current pages, verified September 2026. XML structuring for instructions, context, examples, and inputs; nested document structures with content beside source metadata. Used as engineering guidance for explicit boundaries, not as format-superiority evidence. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• OpenAI. “Structured model outputs.” First-party documentation, current pages, verified September 2026. Schema-constrained generation with type safety and explicit refusals. Used strictly at the application-interface boundary; never as input-reasoning evidence. https://developers.openai.com/api/docs/guides/structured-outputs
• Model Context Protocol. “MCP Overview” and “Tools” specification pages, draft revision, verified September 2026. Same observation admittable as text, schema-validated structured content, resource link, or embedded resource. https://modelcontextprotocol.io/specification/draft/server/