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.
Canonical AI entrypoint
/.well-known/ai-governance.json
Neutral entrypoint that declares the governance map, precedence chain, and the surfaces to read first.
- Governs
- Access order across surfaces and initial precedence.
- Bounds
- Free readings that bypass the canon or the published order.
Does not guarantee: This surface publishes a reading order; it does not force execution or obedience.
Public AI manifest
/ai-manifest.json
Structured inventory of the surfaces, registries, and modules that extend the canonical entrypoint.
- Governs
- Access order across surfaces and initial precedence.
- Bounds
- Free readings that bypass the canon or the published order.
Does not guarantee: This surface publishes a reading order; it does not force execution or obedience.
LLMs.txt
/llms.txt
Short discovery surface that points systems toward the useful machine-first entry surfaces.
- Governs
- Discoverability, crawl orientation, and the mapping of published surfaces.
- Bounds
- Incomplete readings that ignore structure, routes, or the preferred markdown surface.
Does not guarantee: A good discovery surface improves access; it is not sufficient on its own to govern reconstruction.
Complementary artifacts (2)
These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.
Causal context map
/causal-context-map.json
Machine-readable projection of the CCL layer connecting triggers, latent needs, canonical surfaces and intended consequences.
causal-internal-mesh.json
/causal-internal-mesh.json
Published machine-first governance surface.
Four entry points for this corpus
- Understand agentic websites.
- Distinguish conversation, resources and administration.
- Examine governance criteria.
- Read the governed-context protocol.
The Runtime page connects the protocol, the HTTP/MCP instance and a dated technical observation. The path below lets you inspect available contexts and open the integration guide.
The website as an action environment
The agentic web names a change of regime: a website is no longer only visited by a human, indexed by a search engine, or summarized by a model. It can become an environment in which an agent interprets an interface, plans a path, selects an action, and attempts to execute it.
This page is the personal entry point for my work on that shift. It does not replace Pagup service pages. It carries the thesis, distinctions, and doctrinal consequences: what changes when an interface becomes readable by systems that can act.
Why this hub exists
Classic technical SEO asked a central question: can a search engine discover, read, and understand a page? The agentic web adds another question: can an agent understand what it sees, identify the legitimate action, preserve context, and act without ambiguity?
That question reconnects topics that were often handled separately: semantic HTML, accessibility, visual stability, JavaScript hydration, CTA hierarchy, forms, structured data, internal linking, and machine-readable surfaces. Together, they form a grammar of action.
Agentic readiness
The current phase of the agentic web requires distinguishing document reading from interface use. Agentic readiness names that capacity: an agent should be able to find a surface, understand its role, identify the legitimate action, preserve context, and abstain when state, authority, or evidence is missing.
This layer prevents a market confusion: being visible in an AI answer does not mean that a site is ready to be manipulated by an agent. Likewise, exposing llms.txt is not enough to make a path reliable. Read the position Search visibility is not agentic readiness and the AI visibility, machine discoverability, and agentic readiness matrix to separate these regimes.
A WordPress application
How do we move from expressed intent to an authorized task and a verifiable result? The PAGUP Agent Control case shows how this question translates into a WordPress workflow. I present this Pagup product, which I designed, as a design case, not an independent validation.
Read the PAGUP Agent Control case
Canonical concepts
Start with these definitions:
- Agentic web: the website as an interpretable and actionable environment.
- Agentic navigability: the ability of an agent to traverse and manipulate an interface.
- Interpretable interface: coherence between visual intention, HTML structure, and machine exposure.
- Accessibility Tree: a programmable map of roles, names, states, and relationships inside an interface.
These terms should be read with agentic, agentic risk, execution boundary and agentic response conditions. The issue is not only to make a page understandable. It is to govern the conditions under which understanding can become action.
Doctrine and framework
The page Agentic web and Dual Web places this transition within the distinction between human surface, machine surface, and agentic surface. A human can compensate for a weak label, an ambiguous card, or a styled button. A crawler can ignore the interface and extract the document. An agent must connect document, interface, intention, and action.
The agentic web readability framework proposes a reading method: DOM stability, coherence between visual rendering and the accessibility tree, actionable semantics, hydration risk, interaction determinism, visual hierarchy, and governance of paths.
Text series
This series states the core implications:
- The agentic web: why websites will no longer only be read, but manipulated
- From crawler to agent: the new grammar of the web
- The Accessibility Tree as an interpretation map for the agentic web
- The return of HTML as trust infrastructure
- Why visual stability becomes a condition for machine action
- Why sober web architecture becomes strategic again in the agent era
Boundary with Pagup
On this site, I formalize the thesis: systems no longer only read documents, they reconstruct conditions of action. On Pagup, that thesis becomes an audit, design, and technical hardening method. The distinction is deliberate: here, the intellectual category; there, operational implementation.
Reading rule
Do not reduce the agentic web to an accessibility checklist, a machine-readable file, or an AI visibility promise. The deeper question is stricter: does the interface expose its intentions, limits, actions, and states clearly enough for an autonomous system to act without inventing the missing context?
Agentic surfaces and maturity
The Agentic Browsing layer now requires a more granular reading of the interface. It is not enough to say that a site is readable by agents. The agentic surface, action legitimacy, and Agentic Web Maturity Model must be separated.
This layer moves the vocabulary from general framing to diagnosis: which part of the site is only documentary, which part becomes navigable, which part becomes actionable, and which part must instead require confirmation, clarification, or legitimate non-action. Read also From browser to agent.
Choose context for an agentic journey
An agentic journey can offer a choice of information before requesting an answer or an action. The MCP Apps companion illustrates this step with a whole pack from the fictional Boreal Workshop service, in French or English: the person inspects conditions, exclusions and archived sources before explicitly submitting it.
This interface runs inside a compatible conversational host. It remains separate from WebMCP tools exposed by a page in the browser. The companion server verifies the complete snapshot under a separately admitted root for the exercise; it never automatically follows declared source links.
After inspection, “Have the assistant read this pack” prepares the read request. The person sends that message; the assistant then uses the companion’s text tool. This journey requires a connected client and a voluntary request. It does not measure spontaneous Runtime discovery on the open web.
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.
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.
From supplied context to an observed answer
Supplying identifiable context does not establish the quality of the answer that follows. Governed Context Runtime’s experimental runner can compare four conditions on a fictional service: question only, exhaustive text, canonical prose and a structured pack. It retains messages and received responses, together with technical errors and limited retries. Completed responses remain in the observations even when empty, refused or truncated.
Two distinct automatic judges apply a common rubric. Their annotations remain separate, and agreement is calculated only for paired judgments. Trials without a completed response are distinguished from received responses still missing a judgment. This journey is separate from the distribution service and the MCP Apps companion; it does not, by itself, measure a website’s usefulness to every agent.
Read the pilot protocol and its limits · Consult the dated implementation record. The NOT_RUN states of earlier local trials and editions retain their historical scope; they do not replace a provider-campaign receipt.
An interrupted run remains documented. Recovery must retain previous requests, the applicable inputs and the amount already committed, then identify the executable that continues it. The monitor follows that continuity without initiating a new model request.
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.