Evidence layer
Probative surfaces brought into scope by this page
This page does more than point to governance files. It is also anchored to surfaces that make observation, traceability, fidelity, and audit more reconstructible. Their order below makes the minimal evidence chain explicit.
- 01Evidence artifactdoctrine-glossary.json
doctrine-glossary.json
/doctrine-glossary.json
Published surface that contributes to making an evidence chain more reconstructible.
- Makes provable
- Part of the observation, trace, audit, or fidelity chain.
- Does not prove
- Neither total proof, obedience guarantee, nor implicit certification.
- Use when
- When a page needs to make its evidence regime explicit.
Runtime vs MCP
Governed Context Runtime serves precompiled packs for a declared intent, language and version. MCP is a protocol for accessing tools and resources. It can carry reads as well as actions; “MCP for acting, Runtime for understanding” would be too absolute.
A separate MCP adapter already exposes read tools for the gautierdorval.com instance. The instance guide identifies its served profile and dated observations. The July conceptual proposal keeps its proposed status; this implementation description is updated on October 26, 2026.
This Runtime adapter’s boundaries are specific to the project: no writes, free-text intent resolution, on-demand pack composition, answer scoring or recommendations, or answer generation in the core. Runtime does not become an autonomous interpretive authority. These are not general prohibitions imposed by MCP.
Publishing, MCP Apps and WebMCP
Canonical publication makes sources available for consultation. MCP provides a tools-and-resources interface. MCP Apps associates interactive interfaces with those tools in compatible clients. WebMCP exposes tools from a web page in the browser. Runtime supplies identifiable context and integrity verification; it does not replace these layers.
An interface displaying a pack does not establish that the model received or used it. The consumer must admit a corpus root separately; a matching digest establishes neither truth, authority, permission nor semantic fidelity. Admission remains a local decision.
The MCP Apps companion exercises these separate roles
The local companion uses MCP to present a selector inside a compatible host, then reuses the Runtime verifier to inspect a whole fictional pack, its language, version, conditions and archived sources. Selection composes no new pack, and verification does not turn its contents into action permission.
“Have the assistant read this pack” prepares a message with the inspected selection. After the person sends it, the assistant invokes read_gcr_pack. MCP transports the complete text returned by the tool. This journey uses message.text without depending on updateModelContext.text.
On October 27, 2026, T3 completed the button-to-answer journey in Windows Claude Desktop 3.6556.2.0, displayed model Opus 5.5 Max, for the fictional French pack. The read returned 57,236 UTF-8 bytes matching the reference; the final answer, examined separately from the preview, reproduced all five lists and their 11 entries without additions or omissions. It preserved pack identity, boundaries for missing or conflicting evidence and the absence of action permission.
T3 reused the same private conversation after the T2 cancellation, whose cause remains unknown. T2 had triggered no effective text-tool call. A new inspection, one click and one send produced the only observed read across T2/T3. The direct text trial T1 had succeeded separately. These trials provide neither a reliability rate nor a guarantee of first-attempt success.
The interface and pack exist in French and English; this real-client qualification covers French only. The companion remains a local prototype, separate from the hosted service, with no deployed public MCP Apps service. The observation establishes neither general fidelity, business validation nor visibility effects. The comparative pilot remains NOT_RUN.
The native updateModelContext channel remains experimental and unqualified. On October 26, 2026, two journeys in the older client received acknowledgements after submission, but the model reported having only the catalogue and did not reproduce the pack conditions. These observations neither locate the failure nor establish its cause. The October 26 A/B diagnostics in the newer client are separate: blocked before submission, they remain NOT_RUN, with no submitted nonce.
On October 27, A/B answered NON_DISPONIBLE under an instruction forbidding tools, a possible confounder if the host uses an internal reader. H1 permitted that reader and received the same answer, without an observed effective invocation. Retrieving an unpredictable nonce through an isolated channel can establish availability; a negative answer does not symmetrically prove internal non-delivery. No cause is attributed to Claude, the SDK or the adapter. T3 did not retry this channel. The component itself does not read the conversation.
The retained answer and offline comparison are available: five lists of 2, 2, 2, 3 and 2 entries, compared exactly with the pinned fictional pack, without added, omitted or duplicated entries within those lists. Evidence, source and permission boundaries receive a separate editorial reading. The 57,236 bytes describe the tool projection; the retained answer contains 6,029. This file check neither replays the client nor independently authenticates the session. The displayed model name does not certify its internal identity.
Reproduce the local journey and read its limits; T3 result in the historical record. The Runtime page explains verification and its limits.
Compare two states before choosing context
A removed condition, added evidence requirement or changed source merits review before context is reused. The comparator shows differences in B relative to A, two explicitly selected states for the same intent and language.
Each input is verified with its complete snapshot and archives under a separately admitted root, then validated against the pack and manifest schemas. Additions, removals, changed values and order changes remain inspectable alongside originals and an exportable report. Rewriting a sentence in a list produces a removal and an addition; no continuing rule identity or semantic equivalence is assumed.
A French/English Web demonstration lets visitors choose the two fictional states, inspect their differences and export the complete report. The eight compatible pairs are computed with full admission at build time and checked when loaded. Diagnosis of retained real states remains offline. A and B establish no publication succession. Comparing sends no pack to a model. T3 remains a separate qualification; comparison establishes no business benefit or effect on an answer.
Inspect the local journey and exportable report · Read the dated qualification and its limits.
Sources for these distinctions: MCP Apps, Claude’s documented local journey and the WebMCP draft. Their documentation describes the mechanisms; it does not certify this prototype.
MCP does not validate the model’s answer
An MCP call can establish that a tool returned specific context. It does not establish that the model retained its conditions or avoided unsupported claims. Evaluating answers requires a separate protocol that retains the sent message, received response, errors and applied criteria.
The Runtime’s experimental runner prepares that assessment on seven fictional cases with two distinct automatic judges. Their annotations remain separate; a technical failure is not turned into a semantically incorrect answer, and agreement between judges does not certify truth. HTTP or MCP transport, the model’s response and its assessment therefore retain their own evidence.
Inspect the provider boundary and judgment rules · Read the dated implementation record. The NOT_RUN labels in the MCP Apps qualifications above describe those historical trials and remain separate from a provider campaign’s state.
MCP transport does not establish that a provider response was accepted. Revalidating archived bytes after an adapter correction requires a separate pinned record, preserved spending reservations and the identity of the corrected executable. It does not change the request or turn a preflight into a scientific result.
Finding these analyses useful?
Add to my Google sources