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.
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.
Complementary artifacts (3)
These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.
LLMs.txt
/llms.txt
Short discovery surface that points systems toward the useful machine-first entry surfaces.
LLMs-full.txt
/llms-full.txt
Extended discovery surface for readers that consume richer context.
Robots.txt
/robots.txt
Crawl surface that improves discovery but does not, on its own, publish reading conditions.
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 artifactsite-context.md
- 02Evidence artifactcommon-misinterpretations.json
site-context.md
/site-context.md
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.
common-misinterpretations.json
/common-misinterpretations.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.
Why speak of surfaces rather than a single file
Machine governance is not contained in one artifact. It is distributed across several policy surfaces, each carrying a different function.
When those surfaces are treated as if they all said the same thing, the reader loses the correct hierarchy.
Main families of surfaces
1. Procedural surfaces
They organize access, crawling, or some conditions of discovery.
Examples:
robots.txtsitemap.xml- certain crawl or cache related headers
2. Documentary surfaces
They orient reading and provide framing intended for systems that synthesize.
Examples:
llms.txtllms-full.txt- README files or structured context pages
3. Governance surfaces
They publish hierarchy, precedence, limits, non-goals, and rules of interpretation.
Examples:
/.well-known/ai-governance.jsonai-manifest.jsonsite-context.mdcommon-misinterpretations.json- AI use policies
4. Proof surfaces
They document what has been observed, tested, bounded, or weakly attested.
Examples:
Q-LedgerQ-Metrics- observation bundles
- evidence layers
Why hierarchy matters
All of these surfaces must not be read at the same level.
- a procedural surface does not exhaust a doctrinal surface;
- a documentary surface is not equivalent to proof;
- an observation does not automatically create a rule;
- a diffusion surface does not replace a canon.
The Better Robots.txt case
Better Robots.txt is precisely interesting because it materializes several of these surfaces at the scale of a WordPress plugin:
- operational management of
robots.txt; - generation and framing of
llms.txt; - centralization of signals for AI bots;
- articulation with product documentation and a proof repository.
Yet the plugin does not thereby become the sole normative surface of the whole problem space.
Doctrine must remain legible elsewhere, on a surface that fixes distinctions and hierarchy.
Interpretation rule
When several surfaces coexist, they should be read in this order:
- doctrine and site role;
- governance and precedence surfaces;
- documentary surfaces;
- procedural surfaces;
- proof surfaces;
- diffusion surfaces.
The exact order may vary with the problem, but all levels must never be collapsed indiscriminately.
Reading machine policy surfaces
A machine policy surface is not valuable merely because it exists. It becomes useful when it is connected to a canon, a source hierarchy, a response policy, and a correction discipline. Otherwise, it can become a decorative artifact that looks authoritative without changing the interpretation path.
The key question is therefore not whether a policy file can be read by a crawler or model. The key question is what the file is allowed to govern, which claims it can authorize, which inferences it prohibits, and how it relates to the human-readable corpus.
Boundary of the mechanism
Machine policy surfaces should not be treated as universal enforcement. External systems may ignore them, misread them, cache older versions, or combine them with competing sources. Their role is to reduce ambiguity, expose reading conditions, and support auditability. They do not replace canonical pages, evidence, or system-specific controls.
Reading rule
This doctrinal note on Machine policy surfaces should be read as a positioning surface within the interpretive governance corpus. It does not replace the canonical definitions or the operational frameworks. It explains why a distinction matters, where the doctrine draws a boundary, and what kind of error becomes more likely when that boundary is ignored.
The reader should separate three levels. First, the conceptual level: what this page names or refuses to name. Second, the procedural level: what a system, organization or evaluator would need to check before relying on a response. Third, the evidence level: what would make the interpretation reconstructable, contestable and corrigible. A doctrinal page is strongest when it keeps those three levels visible rather than collapsing them into a persuasive formulation.
Use in the corpus
Use this page as a bridge between definitions, frameworks and observations. It can guide a reading path, justify why a framework exists, or explain why a response should be bounded, refused or audited. It should not be treated as a runtime instruction, a guarantee of model behavior or a substitute for evidence. If a response based on this doctrine cannot show which source was used, which inference was allowed and which uncertainty remained unresolved, the doctrine remains a reading principle rather than an operational control.