Governance artifacts
Governance files brought into scope by this page
This page is anchored to published surfaces that declare identity, precedence, limits, and the corpus reading conditions. Their order below gives the recommended reading sequence.
governed-context-runtime.json
/governed-context-runtime.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
governed-context-runtime.json
/.well-known/governed-context-runtime.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
intent-registry.json
/intent-registry.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
Complementary artifacts (1)
These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.
intent-registry.json
/.well-known/intent-registry.json
Published machine-first governance surface.
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 artifactattested-interpretive-units.json
- 02Evidence artifactcontent-digests.json
- 03Evidence artifactdoctrine-glossary.json
attested-interpretive-units.json
/attested-interpretive-units.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.
content-digests.json
/content-digests.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.
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.
Governed Context Runtime
The Governed Context Runtime is infrastructure whose contracts remain proposed, not a doctrinal layer. It serves a precompiled artifact for a canonical intent token already selected by an external agent.
The runtime does not select intent from a free request. It does not generate an answer, recommend a service, measure output fidelity or modify the published governance package.
The intended sequence is closed: the site declares intents, CI precompiles packs, CAI attests units, then an isolated runtime serves the exact requested pack.
v0 boundary
v0 composes nothing at request time. Admissible inputs are closed identifiers such as intentToken, lang, version, packId, unitId and digest.
Prompts, conversations, answers, personal identities, raw IPs and cookies are out of scope. The instance’s ledger is limited to technical distribution events.
Relation to doctrinal layers
CCL and SAL declare context and applicability. CPI and CAI control source weighting and integrity. Q-Layer adjudicates response legitimacy. The runtime replaces none of these layers: it only distributes a precompiled view of the governed corpus.
See also the canonical intent registry, governed context packs and runtime vs generative agent.
Laboratory projection
This page remains the canonical doctrinal source. The public governed-context-runtime program separately bounds the research question, protocol, and evidence state. The program’s existence is not a result.
Implementation status
The October 11, 2026 production release, completed on October 12 UTC, includes an HTTP resolver and a separate MCP adapter. A producer-run check of the public endpoints on October 12 at 02:18 UTC confirms their accessibility and identical bytes for a French pack retrieved through both transports. The interface declares version 0.3.0-proposed; the contracts remain proposed, without changing this page’s doctrinal rank.
The service distributes precompiled artifacts selected through closed identifiers. It does not generate an answer. The consumer selects context, verifies the snapshot and its archives under its local policy, then decides on use. A read may produce a technical distribution event; that event establishes neither use of the content nor answer fidelity.
The integration path and dated observation appear below. The four-condition comparative model pilot is prepared but has not been run (NOT_RUN). It remains separate from the local MCP Apps trials, including T3, documented below.
Governed agentic website criteria.
Choose context inside a conversation
Updated October 27, 2026. The MCP Apps companion provides a local journey to choose a whole Runtime pack, inspect its declarations, conditions and archived sources, then explicitly supply that context to an assistant. The first example, Boreal Workshop, is fictional and available in French and English.
Runtime serves and verifies precompiled context. MCP exposes tools and resources. MCP Apps adds an interface inside a compatible client. WebMCP concerns tools exposed by a web page to the browser. These mechanisms can complement each other; their presence does not establish correct interpretation of the context.
The companion reuses the public verifier on the server with an expected root supplied separately for the exercise. The selected pack, its conditions, exclusions and archived sources remain together. A declared source link does not establish current retrieval.
After inspection, “Have the assistant read this pack” prepares a request with the four exact selection fields. The person sends the message; the assistant then invokes the read_gcr_pack text tool, which returns the complete projection. Context stays attached to an identifiable selection without granting business-action permission.
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.
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.
Discover contracts and interpret versions
The Runtime declaration is the entry point to contracts and the service. Its historical specification path identifies a source layout; it must not be appended to the public repository address. The prepared 0.4.0 declaration contract adds pinned links to raw schemas, their mapping and FR/EN guides. Check the version actually received: preparation does not establish publication, and a strict consumer limited to 0.3.0 rejects the new shape.
The public reference, hosted software, each document format and packs have separate versions. corpusVersion names a family; corpusRootDigest identifies one exact snapshot. The source commit declared by the service belongs to its implementation, not the public repository. A Worker version’s creation timestamp establishes neither its first traffic nor documentation lag. A matching digest proves neither truth, permission nor answer fidelity.
Read the contracts, versions and provenance limits · Read the declared service state · Read the current snapshot.
Inspect public reference edition 0.2.1
The 0.2.1-proposed reference prerelease provides proposed contracts, verifiers and an offline consumer walkthrough. The fictional kit lets you inspect a complete pack with its sources and boundaries. Its root and trust policy are supplied for the exercise, without establishing production trust.
Try the offline consumer kit · Understand the pack’s semantic scope · Inspect the producer’s local qualification
Local qualification documents the producer’s checks on retained assets, without making the private corpus publicly reproducible. Version 0.2.1 identifies the offline reference, separately from the conceptual version and the hosted-service version.
Byte integrity, permission to use the context and answer fidelity remain distinct. The comparative model pilot is prepared but has not been run (NOT_RUN). This publication is neither a new observation of the hosted service nor a turnkey deployment for other domains. The October 12, 2026 check presented below retains its historical scope.
Separating context distribution from response evaluation
An experiment runner separate from the Runtime can execute the four-condition protocol on seven fictional cases in French and English. It retains exact messages, completed responses, technical errors and eligible retries under one shared budget. Two distinct automatic judges apply the same rubric and retain separate annotations. An empty, refused or truncated completed response is not replaced by another attempt intended to improve it.
Pack transport, execution of a request and acceptance of a judgment remain three different facts. Descriptive counts and inter-rater agreement retain their denominators, missing judgments and non-applicable cases. Private status binds the campaign to its manifest and runner version without exposing responses. This instrumentation establishes neither general fidelity, a causal verifier effect nor architecture superiority.
Inspect the execution protocol and its controls and the November 7, 2026 implementation record. Synthetic qualification, a provider request and a completed campaign require separate evidence. The NOT_RUN labels in earlier observations and editions describe their historical state.
A qualified recovery keeps the original inputs, deadlines and spending ceiling. An archived provider response can be revalidated without another request; its uncertain cost remains reserved. A pinned amendment links the corrected executable to the original evidence.
Context you can inspect before answering
An assistant explaining a doctrine needs access to its sources and boundaries. The gautierdorval.com instance serves precompiled packs for a declared intent and a selected language. An integrator can inspect the received version before supplying it to the assistant.
A producer-run technical check on October 12, 2026 at 02:18 UTC confirmed HTTP access, eight MCP tools and identical French pack bytes across both transports. The observed registry contains six intents and twelve FR/EN packs.
Explore the available intents · Follow the REST/MCP integration guide · Browse the public reference repository
- Select an exact intent from the registry, then the pack language and version. Selection belongs to the consumer.
- Retrieve the pack and its manifest through HTTP or MCP. The interface serves the precompiled artifacts matching the requested identifiers.
- Verify the complete snapshot and its archives under a separately pinned corpus root, then make a local decision about using the context.
HTTP access starts at https://context.gautierdorval.com/. The separate adapter accepts POST requests at https://context.gautierdorval.com/mcp. Its MCP 2026-07-28 profile uses server/discover and per-request metadata. The guide provides PowerShell commands and explains client compatibility limits.
Read the technical status · Inspect the corpus snapshot · Read the dated observation
These checks establish observed technical behaviour, without guaranteeing future availability. They measure neither spontaneous adoption nor an effect on a model answer. Context integrity, permission to use it and answer fidelity remain three distinct questions. An isolated v0 unit requires verification of its complete record within the snapshot: its historical digest does not cover every field. The guide includes a consumer example that preserves this scope at the point of use. Keys remain test-only, and archived roots are not a deployment history.
Learn verification with a fictional example
The local demo brings together a receipt, snapshot and archives to follow the verification path without an account or network request. Its data and test keys remain separate from the hosted-service observation. Inspect the runnable demonstration.
Finding these analyses useful?
Add to my Google sources