What the structure buys, and where it stops.
Six structural properties fall out of holding several independent contexts at once. Each is stated with the condition under which it weakens, because a property with no stated limit is a claim rather than a property.
Split-context architecture
Verification needs several independent nodes at the same time. No single node holds the full answer. If any required node is missing, stale, or wrong, the expected output does not match.
N-directional rotation
Instructions and content change on their own schedules. The same document under a new instruction yields a different correct output, which stops one frozen pattern standing in for the full context. In an N-node web there are N axes of rotation and each is independent.
Node leak resilience
If one node becomes public, the rest of the web still does not reveal the output, because the output depends on relationships the leaked node does not describe. Weaker, and sometimes worthless, when the answer string appears verbatim inside one content node.
Comprehension-alignment coupling
Producing the output requires following relationships between nodes rather than echoing surface text. An answer that sounds right but skipped a node fails. A pass indicates the expected output matched; it does not guarantee obedience to every behavioural rule.
Fabrication detection
When a model invents content or answers from partial context, the web structure breaks and the output stops matching. Fabrication and missing nodes surface before trust propagates downstream.
Layered application
Verification can run at several levels independently. A single-layer check catches obvious fabrication. Multi-layer verification catches the case where a surface check passes but deeper integrity does not hold, which is exactly what the Assembly incident showed.
The core guarantee
A method for verifying that a language model staged multiple logically independent context sources together, by requiring an output determined by the relationships between those sources, such that no single source defines both the verification rule and the expected answer, and the expected answer changes when any source is added, removed, or updated.
Implementation themes
- Boot
Verification before user-facing work
The check runs in the agent boot sequence, or the equivalent point in an orchestration layer, so downstream work only ever sees a checked context chain.
- Topology
Any number of nodes
The mechanism generalises to chains, networks and document stacks. Richer topology widens the verification surface.
- Rotation
Version attestation for free
Because the output depends on every node, a stale version of any one node produces an incorrect answer. One check attests currency across the whole web.
- Layering
Independent webs per level
A pass at one layer does not excuse a missing check at another. Independent verification belongs at every level where independent failure is possible.
- Embedded instruction
Content that governs
A node can function as operational instruction only when other specific nodes are present. Without them it reads as ordinary content, which deepens the structure of the web.
Combinatorial resistance
As the node count grows, the reachable combinations expand with both node content and the complexity of links between nodes. An agent that skips inputs tends to drift into detectable fabrication whenever the demanded answer stitches together facts that only appeared across several nodes.
Applications
Agentic orchestration
Instructions, profiles and doctrine load from different stores, so a session can begin with an incomplete chain. Boot-time verification catches it before user-facing work, including layered checks spanning instruction and corpus paths.
Retrieval pipelines
Chunks from a vector store must land in the window together with the instruction that defines how to use them. Treat each staged unit as a node so the output encodes cross-node relationships rather than one chunk.
Multi-document and multi-profile workflows
Several documents, profiles or skill files must be cross-referenced under a single instruction. Encode each as a node and let the topology express the cross-reference that matters.
Versioned policies and data
Instructions and content change on different schedules and stale mixes look plausible. Any stale node yields a wrong answer relative to the expected relationship.
Layered stacks
A high-level check can pass while a lower layer fabricates, if that layer has no verification of its own. Put an independent web at each level where independent failure is possible.
Embedded governance
Rules only govern behaviour if they actually load. Tying verification to loading the governing text couples the two, instead of leaving governance to a separate auth step.
Compared to what you already ship
Most tooling proves transport, signing, or leak detection. The question here is different: did the session actually compose every required instruction and corpus slice, so the output reflects real cross-context work rather than a shortcut across one artefact.
- Canary tokens
Rebuff, Vigil
Random strings embedded in prompts, to catch a system prompt appearing in model output. Leak detection, not comprehension. The signal here is activated by instructions held separately from the document, rather than by a context-free canary.
- Authenticated prompts
February 2026 paper
Cryptographic signing of prompts and context for provenance, and the closest academic work at the time of disclosure. It proves the integrity and origin of artefacts, not that the model read or related several of them.
- API keys and standard auth
Tokens authorise access to a system. They do not prove a document reached the context window, arrived paired with the right instruction, or produced the expected output. The question here is what happened after access.
- Checksums and hashes
A hash confirms a file arrived intact. It says nothing about whether the model read it, processed it, or related it to other loaded material.
- Prompt injection defences
Filtering tries to keep unauthorised instructions out of the window. It does not confirm that authorised content actually loaded and was understood together. One asks whether something bad got in; the other asks whether everything required was there.
On the older names
Semantic password was the working label while the shape of the mechanism stabilised. The shipped name is PassWeb.
A password proves possession of a secret and is freely shareable. A shibboleth proves origin and cannot be shared, because it lives in the body of the speaker. What this proves is narrower and stranger than either: that an expected output derived from several contexts was reproduced, where the instruction and the content can leak separately and the output still requires the configured relationship, unless the expected answer leaks too. A password fails to theft and guessing, and its historic example is the Roman watchword. A shibboleth fails to recording and coaching, and its examples are Judges 12 and the Parsley Massacre, which are an analogy rather than a security proof. What fails here is fabrication from training data, which is what the glossary calls FM-1 and what the Karl incident recorded on the day it happened.