Appendix C — Landscape 2026: A Living, Dated Registry
The durable chapters teach mechanisms. This appendix records moving facts.
That separation is an engineering control. If a chapter says that a particular model is “best,” the claim can become false without a code change. If it instead teaches how to select a model and points here for a dated candidate roster, the method survives. The same applies to inference engines, agent frameworks, protocol revisions, accelerator specifications, benchmarks, and regulation.
This appendix is therefore not a prediction market, leaderboard, or shopping guide. It is a small, reviewable database plus a protocol for changing it. It is also not a duplicate index of every dated sentence in the book. Chapter-local Landscape callouts own teaching-local snapshots; this machine registry retains the smaller set of cross-chapter, deployment-sensitive, high-stakes, and operational pins that need coordinated maintenance. Every entry says exactly what was observed, what kind of claim it is, what artifact was pinned, when the source was checked, which file maintains or consumes it, and what must happen when the entry changes.
The checked snapshot in this edition is 2026-07-19. Verify live: every linked release, specification, model card, benchmark harness, product page, and government source before using it in a production decision.
C.1 A claim needs a lifecycle
A current fact is not ordinary prose. It is an asset with an owner, source, review clock, and exit path. Treating it as a sentence hides those properties. The lifecycle in Figure C.1 turns “I saw this online” into evidence that can be reviewed.
flowchart LR C["Candidate claim"] --> Q["Classify + scope"] Q --> V["Verify primary source"] V --> P["Pin artifact + date + owner"] P --> U["Declared owner consumes claim"] U --> L["Lint + scheduled audit"] L -->|"unchanged"| U L -->|"changed"| M["Migrate dependents"] L -->|"superseded"| R["Retire with reason"] L -->|"not verifiable"| X["Remove claim"] M --> P R --> H["Historical record"]
flowchart LR
C["Candidate claim"] --> Q["Classify + scope"]
Q --> V["Verify primary source"]
V --> P["Pin artifact + date + owner"]
P --> U["Declared owner consumes claim"]
U --> L["Lint + scheduled audit"]
L -->|"unchanged"| U
L -->|"changed"| M["Migrate dependents"]
L -->|"superseded"| R["Retire with reason"]
L -->|"not verifiable"| X["Remove claim"]
M --> P
R --> H["Historical record"]
Figure C.1: How does a moving fact enter, serve, and leave the book?
The important transition is not publish; it is migrate. Suppose an agent protocol changes its event discriminator. Updating the version string is insufficient. Readers may have copied fixtures, parsers, telemetry fields, or state-machine assumptions from the owning chapter. The migration note identifies those dependents and tells the maintainer what to retest.
Each change follows five moves:
Scope the atomic claim. One entry should support one decision-relevant statement. Do not combine a model’s parameter count, context window, price, benchmark score, and license into one row.
Classify the evidence. A measured result is not a vendor specification, and neither is an illustrative assumption. The label controls how strongly a reader may generalize.
Pin the referent. A project homepage is not a reproducible dependency. Prefer a release tag, specification revision, model-card checkpoint, paper identifier, benchmark snapshot, statute, or dated government notice.
Name the maintenance owner.owner_chapter is the .qmd file responsible for maintaining or consuming the row. A teaching chapter owns a row it directly uses. Appendix C owns a registry-only roster or control-plane pin. It does not silently assign an unused fact to a nearby chapter.
Write the migration before the change arrives. A useful migration note names the compatibility tests, measurements, artifacts, or counsel review that a future maintainer must repeat.
No automated fetcher edits the registry. Web pages can change structure; model cards can be rewritten; a “latest” release can introduce a breaking change; summaries can erase legal status. Automation may detect age or missing fields. A person remains responsible for reading a primary source, constraining the claim, and reviewing its dependents.
C.2 The schema makes uncertainty visible
The source of record is data/landscape-2026.json. Its top-level as_of date describes the published snapshot. Every entry has the following required fields.
Field
Question it answers
Failure it prevents
id
What stable record is this?
duplicate or silently replaced claims
claim
What exactly may a reader repeat?
generalization beyond the source
class
Is this measured, vendor-reported, or illustrative?
treating unlike evidence as equivalent
pin
Which release, revision, checkpoint, or artifact?
irreproducible “latest” dependencies
checked
On which ISO date was the source read?
timeless-looking stale prose
source
Which primary HTTPS source supports it?
citation laundering through aggregators
owner_chapter
Which .qmd file maintains or consumes the row?
ceremonial ownership and orphan facts
migration_note
What must change or be retested?
cosmetic version bumps that break systems
category, status, and owner_anchor are optional indexing and control fields. An owner is grounded when its file contains the exact source URL. If the owner consumes a pinned record without repeating that URL, owner_anchor must equal landscape-ref-<id> and identify a visible, row-specific span in the owner. The linter checks both directions: every row reaches a real owner, and every such marker reaches exactly one row owned by that file. A retired entry remains in the database when its historical role matters. Its claim must explain the retirement signal, and its migration note must route readers to a replacement strategy. Deleting every superseded benchmark would erase why old scores should not be compared with new ones.
The three evidence classes have deliberately narrow meanings:
Measured means the source reports an experiment under a stated setup. It does not mean independently replicated, representative of production, or causally explained.
Vendor-reported means an organization or official body states a specification, release property, status, or timeline. The label does not accuse the source of being wrong; it prevents a reported ceiling or status from masquerading as an independent measurement.
Illustrative means the number or scenario exists to exercise a method. It must be self-contained and must never be presented as a quote, market price, or measured workload.
Classification follows the claim, not the domain. An accelerator’s advertised memory capacity is vendor-reported. Throughput observed by the book’s pinned harness is measured. A hypothetical hourly cost in a capacity exercise is illustrative. One physical product can therefore have several entries with different classes.
The schema also sets a limit on what belongs here. Durable definitions, derivations, algorithms, design patterns, and failure models stay in the chapters. Private production telemetry stays in the system’s evidence store. A local dated teaching example stays in its chapter when no coordinated migration depends on it. Appendix C holds only public, change-prone facts that help readers locate the 2026 frontier, operate a current example, or coordinate a high-stakes change.
WarningA fresh source can still support a weak claim
Freshness is not validity. A page checked today may report an unrepresentative benchmark, a theoretical peak, a proposal that is not law, or a model family without a reproducible checkpoint. Scope and classification matter before date.
C.3 Model profiles are candidates, not rankings
The model registry records architecture profiles because systems engineers must reason about memory, communication, active compute, routing, tokenizer compatibility, multimodal input, and serving support. It deliberately does not copy fast-moving quality leaderboards.
The 2026 snapshot contains several mixture-of-experts profiles drawn from official model cards or announcements:
Pinned profile
Reported total parameters
Reported active parameters
Engineering use
DeepSeek-V4-Pro
1.6T
49B
reason about weight residency versus per-token expert compute
Kimi K2.5
1T
32B
test large-MoE serving and communication assumptions
Qwen3.5-397B-A17B
397B
17B
compare a lower active fraction under the same workload
GLM-5
744B
40B
expose runtime and expert-parallel compatibility constraints
gpt-oss-120b
117B
about 5.1B
examine local or smaller-cluster MoE deployment boundaries
Llama 4 Maverick
400B
17B
connect multimodal architecture claims to a deployable manifest review
These rows are not directly comparable performance results. “Active parameters” can be counted differently, and per-token activation does not describe attention cost, KV cache, vision encoders, speculative decoding, quantization, expert imbalance, interconnect traffic, or kernel quality. Total parameters do not say how many replicas fit. Neither number predicts tool-use reliability.
Use a profile to create a candidate, then bind the actual experiment to a version bundle:
Selection then becomes multi-objective. For the target task distribution, measure final-state success, policy compliance, calibration, tool arguments, latency percentiles, throughput under concurrency, memory headroom, cost per successful task, and operational failure modes. Run enough repeated trajectories to expose stochastic variance. A model that wins a static question set may lose after tool timeouts, long conversations, or strict structured-output validation.
Closed provider models belong in the same decision process even when their parameter counts are unavailable. Pin the provider model identifier and dated API behavior; record region, retention controls, tool schema, context policy, latency, rate limits, retirement policy, and price separately. Missing architecture disclosure changes the available evidence, not the need for evaluation.
When a model profile changes, do not edit downstream arithmetic blindly. Recreate the capacity worksheet from Appendix B, confirm that the runtime supports the exact architecture, and repeat the release suite. The correct migration may be “no chapter change” because the profile was illustrative. It may instead invalidate quantization, expert-parallel, tokenizer, or context assumptions.
C.4 Local inference begins with fit, then measurement
Local inference spans laptops, workstations, single accelerators, on-premises clusters, sovereign installations, and disconnected edge systems. “Runs locally” says nothing about acceptable quality, prompt length, concurrency, thermal stability, or security posture.
Begin with three feasibility questions:
Can the pinned artifact fit? Account for quantized weights, KV cache at the allowed context and concurrency, runtime workspaces, multimodal encoders, draft models, adapters, and fragmentation.
Can memory move fast enough? Decode for small batches is often bandwidth-sensitive, while prefill and larger batches can become compute-sensitive. Published bandwidth is a ceiling, not delivered tokens per second.
Can the operational envelope hold? Measure time to first token, decode rate, tail latency, sustained temperature/power, failure recovery, output compatibility, and the exact workload distribution.
The current registry includes three deliberately different hardware views. AMD reports 288 GB HBM3E and up to 8 TB/s for one MI350X. NVIDIA reports rack aggregates for GB300 NVL72: 72 GPUs, 20 TB GPU memory, and up to 576 TB/s aggregate GPU-memory bandwidth. Apple’s 2025 Mac Studio specification allows up to 256 GB unified memory with M3 Ultra and reports 819 GB/s bandwidth. A per-accelerator line, a rack total, and a unified-memory workstation must not be placed on one bar chart without normalizing scope.
The training-cost registry also pins one price observation: Google Cloud listed a3-highgpu-8g at $88.490000119 per eight-H100 VM-hour, or $11.061250014875 per GPU-hour, on 2026-07-19. It is a workbook input example, not a reusable market price; region, contract, capacity, services, and interruption terms still require a current quote.
The runtime pin matters just as much. The snapshot records vLLM 0.21.0 because its release notes include breaking build and dependency signals, and llama.cpp build b9637 because it provides a concrete multi-platform commit and binary set. Neither pin means “preferred.” They demonstrate two maintenance patterns:
semantically versioned engines may still change supported compilers, transformer libraries, kernels, parsers, and scheduler behavior;
commit-oriented local runtimes move so frequently that an exact build and quantized artifact hash are necessary for reproduction.
A sound local benchmark uses the same prompt corpus and acceptance predicates as hosted candidates. Report model-quality deltas introduced by quantization alongside speed. Separate prefill from decode, warm from cold start, and single request from production concurrency. Include rejected outputs and retries in cost and throughput. A fast invalid JSON response has not completed useful work.
Local deployment can improve data control and disconnection tolerance, but it does not automatically provide privacy. Prompts can leak through logs, crash dumps, desktop telemetry, swap, shared model servers, or plugin processes. Apply the data-flow, least-privilege, observability, patching, and incident controls from Chapters 24 through 28 to the local boundary too.
C.5 The training stack is pinned as examples, not a recommended build
Chapter 6 teaches the durable arithmetic of a frontier run — the memory ledger, ZeRO sharding, tensor and pipeline parallelism, model-FLOPs utilization, and the cost model that ends in megawatts. The volatile pieces that arithmetic sits on top of are registered here, dated, so a rewritten chapter never carries a silently stale reference stack. None of these rows ranks a component; each locates one and says what must be re-tested when it moves.
Four rows pin the assembly. PyTorch’s FSDP2 fully_shard documents the per-parameter-sharding API a ZeRO-3 run depends on; TorchTitan and MaxText are the PyTorch and JAX reference platforms that compose those features end to end; and DeepSeek’s DeepEP is a current mixture-of-experts dispatch-and-combine communication library. All four are vendor-reported interfaces that move quickly: pin the commit, then revalidate layout, checkpoint portability, throughput, and fault recovery before adopting them.
Two rows record low-precision and optimizer recipes as measured results under their authors’ setups — NVIDIA’s NVFP4 training paper and the Kimi K2 report that introduced MuonClip. Three more record operations at scale: MegaScale’s model-FLOPs-utilization and restart figures, the Llama 3 report’s 466-interruption training snapshot, and Decoupled DiLoCo’s decentralized-training study. Treat each number as a dated existence proof, never a target to transfer to a different model and cluster.
The accelerators those runs land on are procurement inputs, not durable mechanisms. Google’s Ironwood TPU and NVIDIA’s announced Vera Rubin platform quote peaks under sparsity and precision conventions that are not comparable across vendors; benchmark the target model, precision, topology, collective mix, and power envelope before trusting a spec sheet. Finally, compute-threshold governance is a dated legal status rather than settled law: Executive Order 14110’s 10^26-operation reporting trigger was revoked in January 2025 and has no active general successor, per the Congressional Research Service summary. Qualified counsel must recheck federal, state, export-control, and sector obligations; the broader governance surface is registered below and taught in Chapter 25.
C.6 Tokenizer-free modeling is a frontier, not a foregone conclusion
Subword tokenization compresses common strings into fewer model steps, but it creates a fixed vocabulary and segmentation procedure outside the learned model. That boundary can behave unevenly across languages, spelling noise, code, identifiers, and unseen byte sequences. Byte-level models remove the fixed vocabulary but initially pay with much longer sequences and more autoregressive steps.
The active research question is not simply “tokens or bytes?” It is where segmentation and multiscale computation should live.
Frontier line
Core move
Pinned evidence
Question still open
MEGABYTE
fixed multiscale byte patches with global and local models
NeurIPS 2023
how far fixed patching scales for general assistants
BLT
entropy-guided variable byte patches
arXiv:2412.09871
full lifecycle efficiency and independent large-scale replication
H-Net
learned content- and context-dependent hierarchical chunking
arXiv:2507.07955, ICLR 2026
stability, tooling, and behavior at broad frontier scale
EvaByte
efficient byte-level architecture and decoding
6.5B project release
comparison under common hardware and measurement protocols
These projects establish that tokenization is an architecture choice rather than a law of nature. They do not establish that every production system should discard tokenizers in 2026. A production decision must compare end-to-end quality and resources: bytes processed, training FLOPs, sequence memory, decode steps, serving bandwidth, robustness, multilingual slices, code and identifier fidelity, streaming behavior, and compatibility with constrained decoding and tool protocols.
Units are a recurring trap. A trillion bytes is not a trillion tokens. Bits per byte, token-level perplexity, task accuracy, FLOPs, and wall-clock throughput answer different questions. The owner chapter keeps the representation theory; this appendix records papers and releases so the reader can rerun the comparison as the frontier moves.
The most valuable migration test is adversarial, not ceremonial. Include malformed UTF-8, mixed scripts, combining characters, long identifiers, spacing-sensitive code, spelling noise, binary-like payloads, and languages underserved by the existing tokenizer. Then include ordinary clean text. A frontier representation should improve the weak slices without silently degrading the dominant workload or multiplying serving cost.
C.7 Frameworks and engines should sit behind owned contracts
An agent framework can accelerate checkpointing, streaming, human review, graph execution, and adapters. It does not own the product’s invariants. The system must still define state transitions, effect authority, idempotency, cancellation, budgets, telemetry, evaluation, and recovery in terms the organization can test without the framework.
Figure C.2 separates five layers that are often collapsed into “the agent stack.”
flowchart TB P["Product contracts<br/>state · effects · budgets · evidence"] F["Orchestration framework<br/>graphs · messages · adapters"] R["Durable runtime<br/>checkpoint · replay · queues · workers"] X["Protocol adapters<br/>MCP · A2A · AG-UI"] E["Model serving engines<br/>provider API · vLLM · llama.cpp"] P --> F --> R F --> X R --> E O["Observability + policy"] -. "cross-cutting" .-> P O -.-> F O -.-> R O -.-> X O -.-> E
flowchart TB
P["Product contracts<br/>state · effects · budgets · evidence"]
F["Orchestration framework<br/>graphs · messages · adapters"]
R["Durable runtime<br/>checkpoint · replay · queues · workers"]
X["Protocol adapters<br/>MCP · A2A · AG-UI"]
E["Model serving engines<br/>provider API · vLLM · llama.cpp"]
P --> F --> R
F --> X
R --> E
O["Observability + policy"] -. "cross-cutting" .-> P
O -.-> F
O -.-> R
O -.-> X
O -.-> E
Figure C.2: Which layer owns each kind of compatibility?
The registry pins LangGraph’s 1.x LTS lane and AutoGen’s 0.4 stable documentation lane as examples, not as a complete market survey. LangGraph documents checkpointing, persistence, streaming, and human-in-the-loop in a graph runtime. AutoGen separates AgentChat, an event-driven Core runtime, extensions, and Studio. Their abstractions differ; the evaluation questions do not:
Can an interrupted run resume without repeating an external effect?
Is persisted state versioned and migratable?
Are cancellation and deadlines propagated to model, tools, and queues?
Can one trace connect user event, model call, tool proposal, policy decision, effect receipt, and final state?
Can the application export its domain state and leave the framework?
Keep tool schemas, policy decisions, receipts, and domain events in owned types. Wrap framework messages at the boundary. Store a version with serialized checkpoints. Maintain replay fixtures across the oldest supported version and the candidate version. If a framework upgrade changes scheduling, streaming order, or retry semantics, run fault injection—not only a happy-path unit test.
The same rule applies to serving engines. Use a stable internal request/response contract and adapt provider-specific or engine-specific fields. Pin structured-output behavior and chat templates. A runtime upgrade that improves throughput but changes reasoning tags or tool-call parsing can reduce end-to-end success.
C.8 Protocol versions form a compatibility matrix
MCP, A2A, and AG-UI address different edges. MCP connects an application to tools and context. A2A connects independently described agent services and task lifecycles. AG-UI connects an agent backend to an interactive user interface through events. OpenTelemetry GenAI conventions describe telemetry; C2PA describes signed provenance manifests. They complement one another and should not be forced into one universal envelope.
Surface
Snapshot pin
Negotiation or state
2026 migration watch
MCP
2025-11-25
date revision negotiated during initialization; capabilities exchanged
deprecated feature lifecycle, authorization, elicitation, and transport behavior
signed manifest, assertions, trust chain, hard/soft bindings
conformance tooling and trust-list policy; provenance is not truth
Version support is a matrix, not a Boolean. For each pair of client and server versions, test initialization, capability negotiation, unknown fields, unknown event types, cancellation, timeouts, authentication failures, streaming disconnects, duplicate delivery, and recovery. A tolerant reader should ignore safe unknown optional data; it must reject ambiguous authority or invalid required state.
Protocol conformance does not grant trust. A schema-valid MCP server can describe a dangerous tool. A signed A2A Agent Card can advertise capability without proving quality. An AG-UI event can carry untrusted content. OpenTelemetry attributes can exfiltrate secrets. A valid C2PA manifest can preserve a false claim from a signer. Authentication, authorization, sandboxing, policy, validation, provenance, and evaluation remain separate controls.
The practical thin waist is a typed internal event model. Adapters translate external messages into proposals and observations. Deterministic policy grants or denies effects. Receipts record committed outcomes. This lets an organization replace protocol libraries without making their classes the source of truth.
C.9 Retrieval policies need capability pins
“Advanced RAG” is not a reproducible dependency. It can mean a fixed hybrid retriever, a learned decision to retrieve, a corrective evidence evaluator, a graph index, a model that issues several searches, or a complete research workflow. The registry therefore records policy capabilities and evidence, not one ranking of retrieval products.
The 2026 snapshot adds five retrieval landmarks. Microsoft’s GraphRAG documentation exposes local, global, DRIFT, and basic query modes; that entry is vendor-reported because the claim is about the documented interface. Search-R1 and ReSearch are separate measured research entries that both study reinforcement-learned interleaving of reasoning and search under their own training and evaluation contracts. SPARKLE presents a structured adaptive retrieval policy. PoisonedRAG is a measured security result about corpus knowledge corruption. None of these records says that the named policy wins on the reader’s corpus.
Changing any term can move quality, cost, or exposure. A new graph extractor can alter entity identity and invalidate deletion lineage. A new search policy can issue more calls while improving an answer metric. A retriever upgrade can change which hostile documents reach the model. A larger context window can change the best routing decision without changing the index.
Security terminology is pinned separately to NIST AI 100-2e2025 and OWASP LLMSVS v2. Those documents make indirect prompt injection a current review concern; they do not supply a perfect detector. The owner chapters retain the durable controls: authorization before ranking, provenance through transformations, least-privilege tools, independent effect gates, typed abstention, and adversarial evaluation.
When a retrieval-policy entry changes, rerun direct, one-shot, iterative, graph, structured-store, and required-abstention slices under equal budgets. Report retrieval recall, supported-claim rate, citation correctness, latency, calls, cost, permission violations, and attack influence separately. Migrate only when the complete system improves at an operating point the product can sustain.
C.10 Benchmarks need retirement rules
A benchmark is a measurement instrument with a task distribution, environment, harness, scorer, policy, and contamination history. Naming only the dataset discards most of the experiment.
The 2026 registry illustrates a portfolio rather than a single score:
OmniDocBench paper 2412.07626v2 plus Real5 paper 2603.04205v2
element metrics, page types, capture conditions, semantic checks
Static leaderboards decay for predictable reasons: training contamination grows, tasks become saturated, harnesses are optimized, dependencies rot, labels prove wrong, and the public score becomes a marketing target. OpenAI’s 2026 rationale for no longer using SWE-bench Verified is recorded as a retirement signal, not as proof that the original benchmark was useless. Historical scores can describe historical systems. They should stop driving frontier launch decisions when the instrument no longer separates or accurately measures candidates.
flowchart LR N["New instrument"] --> V["Validate tasks + harness"] V --> A["Active decision signal"] A --> D{"Periodic audit"} D -->|"healthy"| A D -->|"repairable"| U["New revision + crosswalk"] D -->|"contaminated · invalid · saturated"| R["Retire from launch gate"] U --> V R --> H["Historical use only"] R --> N2["Validate replacement"]
flowchart LR
N["New instrument"] --> V["Validate tasks + harness"]
V --> A["Active decision signal"]
A --> D{"Periodic audit"}
D -->|"healthy"| A
D -->|"repairable"| U["New revision + crosswalk"]
D -->|"contaminated · invalid · saturated"| R["Retire from launch gate"]
U --> V
R --> H["Historical use only"]
R --> N2["Validate replacement"]
Figure C.3: When should a benchmark move from launch gate to historical record?
Define retirement triggers before a favored model scores well. Useful triggers include a high rate of invalid tasks, uncontrolled environment drift, evidence of answer leakage, performance near the human or harness ceiling, low variance among relevant candidates, weak correlation with production outcomes, or a change in the product task distribution.
Never replace an old benchmark silently. Run a crosswalk on representative systems, publish task-level differences, and mark which historical comparisons remain valid. Keep internal shadow evaluations fresh and access-controlled. Use production incidents to add permanent regression cases, while preventing the training path from consuming release holdouts.
C.11 Legal and governance entries are counsel-owned signals
This appendix is not legal advice. It records official signals so engineers know when governance artifacts, lineage, disclosure, or counsel review may need to change. Legal applicability depends on jurisdiction, role, system purpose, user population, risk classification, dates, amendments, and facts that a book cannot determine.
The registry separates four statuses that teams often blur:
an enacted requirement may have phased application dates and exceptions;
a proposal or consultation can change and is not a final rule;
official guidance or a voluntary framework can shape controls without itself being a universal legal duty;
a technical standard can support evidence or interoperability without deciding compliance.
The dated snapshot includes the European Commission’s AI Act implementation page, California AB 2013, NIST AI 600-1, the U.S. Copyright Office’s multi-part AI report, and an FTC June 2026 proposed policy statement. Their roles differ. The AI Act and AB 2013 are legal sources with scoped obligations and timelines. NIST AI 600-1 is a voluntary risk-management profile. The Copyright Office report analyzes policy and doctrine; Part 3 remained marked pre-publication on the checked page. The FTC item is explicitly a proposal open for comment.
An engineer should not translate those sources directly into “compliant: true.” Instead, maintain an obligations register with:
Field
Example of the required precision
source and status
enacted text, final rule, proposal, guidance, or standard
jurisdiction and role
provider, deployer, developer, importer, employer, public body
system and use scope
which model, workflow, population, and decision are covered
effective/application dates
date plus exception or transition basis
counsel interpretation
named reviewer, decision date, assumptions, open questions
amendment, final guidance, new release, jurisdiction expansion, incident
The technical chapters make counsel review possible. Dataset lineage supports disclosure and rights analysis. Model and system cards constrain claims. Evaluation contracts substantiate performance. Logs and receipts support investigation. Privacy maps enable retention and deletion. A safety case connects hazards to evidence. Those artifacts do not decide the law, but a team without them cannot answer precise legal or audit questions efficiently.
When a legal entry changes, freeze the source previously relied upon, record the new source, and open a change review. Counsel determines applicability. Engineering identifies affected datasets, model versions, interfaces, notices, controls, evidence retention, and launch conditions. Product owners decide rollout. The migration is complete only after affected evidence and system behavior are verified.
C.12 Run an annual frontier audit
Individual entries have freshness checks. Once per year, audit the shape of the registry so yesterday’s categories do not define tomorrow’s book.
Use this sequence:
Inventory every dated box. The linter covers the JSON registry; search all chapters for Landscape 2026, Checked, version strings, prices, leaderboards, and “current” claims. Every moving fact should either become a registry entry or be removed.
Challenge the taxonomy. Ask whether new model interfaces, learned representations, agent protocols, hardware classes, media formats, evaluation methods, or regulatory categories require a new row—not merely a new vendor.
Re-run representative builds. Execute the serving, protocol, runtime, evaluation, safety, observability, computer-use, multimodal, embodied, and capstone artifacts under pinned dependencies. Record breakages and changed results.
Audit primary sources and retirements. Replace redirected or secondary links. Mark proposals that became final, benchmarks that became saturated, versions that lost support, and model artifacts that disappeared or changed terms.
Publish a migration digest. Summarize changed entries, owner chapters, required reader actions, incompatible historical results, and intentionally unchanged durable lessons.
Assign owners by domain, not vendor. A serving owner tracks engines and hardware. An interoperability owner tracks protocols. Evaluation owners track benchmark health. Governance and counsel track official sources. Chapter maintainers approve explanation changes. One editor owns the cross-book consistency gate.
The audit should produce evidence, not a trend essay: linter output, link report, test and render results, dependency manifest, benchmark crosswalks, changed artifact hashes, reviewed legal-source status, and a signed editorial decision log. If a frontier claim cannot be verified or no longer helps a decision, delete it from the teaching path.
C.13 Keep an explicit open research agenda
The registry answers “what is pinned now?” The research agenda asks “which uncertainty should change an engineering decision next?” A useful agenda names a measurable gap and an owner rather than announcing that a topic is exciting.
C.13.1 Models and representations
Can tokenizer-free or learned-chunk models preserve quality while reducing total training-and-serving energy across multilingual, code, tool, and streaming workloads?
Which sparse architectures remain robust under quantization, expert failures, heterogeneous accelerators, and adversarial routing loads?
How should reasoning-time compute be budgeted and calibrated when longer traces can increase both quality and attack surface?
C.13.2 Agent systems
Which task properties justify planning, memory, multi-agent coordination, or world models over a simpler workflow?
Can effect-safe runtimes provide portable exactly-once intent over heterogeneous tools that lack idempotency?
How can long-lived agents update memory while supporting deletion, provenance, contradiction, temporal validity, and poisoning recovery?
C.13.3 Evaluation and observability
How do we build live, contamination-resistant evaluations without making them irreproducible or prohibitively expensive?
Which trajectory signals predict production harm before final-state failure, without storing sensitive reasoning content?
How should uncertainty propagate across retrieval, perception, planning, policy, tool execution, and user confirmation?
C.13.4 Security, governance, and society
What isolation and authorization primitives remain usable under long-horizon, multi-tenant, multimodal agents?
Which provenance signals survive editing and distribution while preserving privacy and avoiding false certainty?
How can organizations test disparate failure rates, accessibility, contestability, and human oversight in workflows rather than static model outputs?
C.13.5 Embodied and multimodal systems
Which world-model representations improve recovery under distribution shift instead of merely improving open-loop prediction?
How should simulation evidence transfer to physical safety cases, and where must real-world testing remain mandatory?
Can speech and video agents remain interruptible, low-latency, and effect-safe when perception is partial and asynchronous?
Review this agenda with the annual audit. Promote a question into a chapter only when it gains durable concepts, reproducible evidence, and a build. Remove questions that cease to influence design. The book should not grow merely because the news cycle does.
C.14 Build: audit the registry
The integrated build is intentionally small: a deterministic linter over the living database. It does not browse, summarize, or edit claims. Its purpose is to make missing pins, malformed dates, duplicate identifiers, non-HTTPS sources, invalid evidence classes, and stale checks impossible to overlook.
remove a pin from one entry and observe a hard error;
set a checked date beyond the allowed age and observe a warning;
open the primary source manually and determine whether the atomic claim still holds;
if it changed, update the pin, claim, checked date, and migration note together;
inspect the owner chapter and run the named compatibility or evaluation work;
rerun the linter, chapter tests, link checks, and full render;
review the diff as an evidence change, not a documentation typo.
The tests exercise the database itself plus missing fields, stale and future dates, malformed dates, duplicate identifiers, insecure source URLs, owner-path existence, source-or-anchor grounding, reverse marker ownership, and command exit behavior. --warnings-as-errors belongs in publication CI. A local audit may first run without it to print the stale work queue.
The linter cannot tell whether a source is primary, a benchmark is valid, a statute applies, or a vendor result generalizes. Those are review responsibilities. Its value is narrower and real: it makes the editorial contract executable and ensures every moving claim carries the metadata needed for human judgment.
C.15 Summary
The method endures even as every entry ages: separate durable mechanisms from moving examples, phrase one atomic claim per record, classify measured, vendor-reported, and illustrative evidence honestly, pin the referent and verification date to a primary source, give each row an owner that interprets it, and write migration and retirement rules before they are needed — automating consistency, never truth. The changing surface is everything else: model rosters, weights and licenses, framework and runtime APIs, hardware, prices, protocol revisions, telemetry conventions, benchmarks, and the status of statutes and proposals. Listing those facts here does not make them durable; their explicit dates make their instability visible, and the exercises below put the practice to work.
C.16 Exercises
Pick one model-profile entry. Split its vendor-reported architecture fact from a measured deployment result on your hardware. Create two records with distinct pins and classes, then explain which chapter decision consumes each one.
Build a client/server compatibility table for two MCP revisions or two A2A protocol lines. Add fixtures for negotiation failure, unknown optional fields, duplicate delivery, cancellation, and reconnect. Write the migration note before changing the adapter.
Reproduce one local-inference comparison with a pinned model artifact and runtime commit. Report weight format, prompt corpus, prefill and decode rates, time to first token, p95 latency, memory peak, quality delta, thermal duration, and successful-task throughput.
Audit a public agent leaderboard. Freeze the task set, harness, environment, scorer, model, agent, and budget. Identify at least three threats from contamination, invalid tasks, dependency drift, saturation, or selective reporting. Propose a retirement trigger and replacement signal.
Take the EU AI Act, California AB 2013, NIST AI 600-1, or another official source relevant to your system. Without making your own legal conclusion, create an obligations-register draft that distinguishes source status, possible role, assumptions, counsel question, mapped evidence, and update trigger.
Add one 2026 frontier entry that is absent from the registry. Use a primary source, make the claim atomic, choose the evidence class, pin an artifact, link an owner chapter, and write a migration note. Ask a reviewer to find where your language overgeneralizes the source.
Run a miniature annual audit. Search the book for dated facts, choose three stale or unpinned candidates, verify their primary sources, update or remove them, run affected builds, and publish a one-page migration digest that states which durable lessons did not change.
C.17 Notes and primary sources
The full, machine-readable source list lives beside each claim in data/landscape-2026.json. The following links are the principal anchors for this snapshot.