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.
Site context
/site-context.md
Notice that qualifies the nature of the site, its reference function, and its non-transactional limits.
- Governs
- Editorial framing, temporality, and the readability of explicit changes.
- Bounds
- Silent drifts and readings that assume stability without checking versions.
Does not guarantee: Versioning makes a gap auditable; it does not automatically correct outputs already in circulation.
Registry of recurrent misinterpretations
/common-misinterpretations.json
Published list of already observed reading errors and the expected rectifications.
- Governs
- Limits, exclusions, non-public fields, and known errors.
- Bounds
- Over-interpretations that turn a gap or proximity into an assertion.
Does not guarantee: Declaring a boundary does not imply every system will automatically respect it.
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.
- 01Observation mapObservatory map
- 02Evidence artifactmanifest.json
Observatory map
/observations/observatory-map.json
Machine-first index of published observation resources, snapshots, and comparison points.
- Makes provable
- Where the observation objects used in an evidence chain are located.
- Does not prove
- Neither the quality of a result nor the fidelity of a particular response.
- Use when
- To locate baselines, ledgers, snapshots, and derived artifacts.
manifest.json
/observations/better-robots-ai-2026/manifest.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.
The market does not begin with the tool
When a new problem appears, it is almost never named from the start as a tooling category.
It is first formulated as:
- a diffuse friction;
- a risk;
- a policy problem;
- an architectural difficulty;
- a governance question.
Only later does part of that problem stabilize as an implementable layer, and therefore as a tooling category.
Typical sequence
The usual sequence looks like this.
- The problem is experienced without being clearly named.
- The problem is analyzed in terms of distinctions, limits, and arbitrations.
- Recurring practices emerge to handle part of it.
- Tooling appears for that operationalized part.
- The market stabilizes a category and begins asking solution-oriented queries.
Why this matters for AI governance
In questions related to discoverability, access, training, documentary signals, and differentiated permissions, the market is still partly between step 2 and step 4.
In other words, several problems are already conceptually real, but they have not all stabilized as product categories.
Better Robots.txt as a partial case
Better Robots.txt shows that part of this field has already become a tool problem:
- concrete management of
robots.txt; - AI bot control;
- use of
llms.txt; - WordPress implementation from one interface.
But that does not mean that the entire doctrinal space around AI permissions has already become a tooled market.
Strategic consequence
When a policy problem has not yet become a tool category, doctrinal work comes before product work.
One must then:
- name the distinction;
- show the real problem;
- isolate the implementable part;
- avoid selling as already stabilized a category that is still emerging.
Consequence for this site
That is precisely why gautierdorval.com must remain a doctrinal surface. Its function is not to turn every concept artificially into a product pitch, but to make distinctions clear enough that some of them may later become legitimate categories of implementation.