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. Model experiments remain a separate step and have not been performed to date.
Governed agentic website criteria.
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.
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