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, and 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, and it is not new. Chapter 12 introduced it for one content offered in several fidelities, from a bare reference up to full text, each bounded below by a floor. This chapter generalises it from fidelity to organisation and encoding. It 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:

    flowchart TD
    U["Underlying information<br/>facts, relations, constraints, evidence"]
    S["Semantic representation<br/>which structure is made explicit:<br/>prose, records, tables, triples"]
    Z["Serialisation<br/>how it is encoded:<br/>JSON, XML, Markdown, CSV"]
    T["Tokens"]
    M["Model"]
    U --> S --> Z --> T --> M
  

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 but understanding why the architecture changed awkward. Narrative prose makes causal explanation natural while 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

The question. For a given operation, does the organisation of the same facts, or their serialisation, change what the model can do with them and what they cost?

The design, in brief. Build each fixture from a canonical ground-truth record and render every condition deterministically from it, with no model in the loop, so that the facts are the same and only the form varies. Verify every required atomic fact against a manifest for each rendering, and drop a form for a fixture it cannot render faithfully. Two experiments run separately. The first varies organisation with facts constant: prose, labelled records, tables where the data is tabular, triples where it is relational, a task-shaped hybrid, and an oracle. The second varies serialisation with structure constant: key-value text, JSON, XML, Markdown records and compact delimited forms. Task families run per operation and are never averaged: exact lookup, record comparison, relation traversal, causal explanation, and state update with a check that unrelated fields survive. Sizes run small, medium and large, because verbose forms may win small on clarity and lose large on repetition. Five traps keep the conditions honest: leading-zero identifiers, unknown against zero, relation direction, two sources with identical facts, and shared outcomes with different rationales.

The measurements that matter. Correctness by operation and size, exact-field use, edit locality scored by field and not by character, and cost in bytes and tokens with the kind of count stated. Parseability and schema validity sit on their own ledger, so structured output that parses is never mistaken for input that was used.

What would change the book. If labelled key-value text matches JSON, XML and tables across the project-state tasks, the format optimiser is deleted. If source-native tool results win, normalisation is deleted. A hybrid that wins one niche stays local to it. Nothing here has been run.

What the compiler renders, and what it does not

A form has to be chosen before it can be rendered, and the compiler of Chapter 23 makes neither choice about organisation. It is handed candidates whose content is already in a form, and it selects among the forms it is given. Its own renderer is deliberately plain: a header, the contents of the admitted items in order, separated by a fixed marker, and a closing line. It does not turn prose into a table or a record into prose.

That is a decision worth defending. Normalisation, converting tool output, memory and agent state into one internal representation, can drop fields, rename concepts, merge entities, change types and erase provenance, so it is a transformation to be evaluated, not plumbing to be assumed. Keeping it upstream, in whatever builds the candidates, means its losses are attributable to it and not to assembly. The likely production shape is a hybrid, typed state beside short rationale beside a table of repeated records beside relation references beside raw evidence by reference, but that is a hypothesis about matching form to information type, not a finding.

Two properties of the renderer do connect to this chapter. It is deterministic, so a rendering can be reproduced and compared, which is what the fixtures here rely on. And the rendered text is a distinct object from the bundle it renders, with its own cost and its own identity, which Chapters 23 and 25 use.

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/