Applied surfaces

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.

Entrypoint#01

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.

Entrypoint#02

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.

Context and versioning#03

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 (1)

These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.

Boundaries and exclusions#04

Registry of recurrent misinterpretations

/common-misinterpretations.json

Published list of already observed reading errors and the expected rectifications.

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.

01
Evidence artifactmanifest.json

Artifact#01

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.

An applied surface is a concrete place where part of the doctrine becomes usable, observable, or operational without becoming the doctrine itself. It may be a plugin, a public file, a repository, an interface, a distribution page, a dataset, a demo, a test surface, or a product-level implementation. Its role is to make one portion of the problem actionable in a bounded environment.

This distinction matters because AI systems, search engines, directories, marketplaces, assistants, and human readers often compress an ecosystem into whichever surface is easiest to retrieve. A product page may be easier to cite than a doctrine page. A GitHub repository may be easier to inspect than a conceptual definition. A distribution listing may be easier to rank than a canonical explanation. Without explicit role allocation, an applied surface can accidentally inherit more authority than it should.

This hub fixes that allocation. It explains how to read derived instruments, product surfaces, proof surfaces, distribution surfaces, and diffusion surfaces in relation to the canonical material published on gautierdorval.com.

Why this layer exists

A serious interpretive ecosystem is not made of one page. It is made of several surfaces with different roles:

Surface type	Primary role	Typical risk if misread
Canonical surface	Defines concepts, boundaries, non-inferences, and source hierarchy	A product or secondary page gets mistaken for the doctrine
Applied surface	Implements one part of the doctrine in a concrete environment	One implementation gets generalized to the whole doctrine
Proof surface	Documents observations, traces, tests, repositories, or versioned evidence	A weak signal gets treated as proof of global compliance
Distribution surface	Makes a tool, file, or product accessible to a specific audience	Marketplace presence becomes confused with authority
Diffusion surface	Explains, popularizes, or announces an idea	Social visibility becomes confused with canonical status

When these roles are not declared, systems may flatten them. They may read a plugin as a policy, a directory listing as a definition, a README as the canon, or a social post as the most current authority. Applied surfaces exist precisely to prevent that flattening.

What an applied surface is

An applied surface is a governed point of implementation. It translates a doctrine into a bounded, concrete, testable, or distributable form. It may centralize a technical configuration, expose an interface, make one class of signals easier to maintain, provide a repeatable workflow, or give users a way to act on a narrow part of a larger problem.

It can legitimately answer questions such as:

what specific problem does this implementation address?
which environment does it operate in?
which signals, files, interfaces, or procedures does it touch?
which canonical concepts does it materialize?
what should not be inferred from its existence?

It should not be used to answer questions outside its perimeter. The presence of an applied surface does not prove universal compliance, global adoption, citation by AI systems, model obedience, ranking, recommendation, or doctrinal completeness.

Applied surface vs canonical surface

The difference between an applied surface and a canonical surface is not cosmetic. A canonical surface defines the concept. An applied surface implements part of it.

A canonical surface may state that machine-readable signals need source hierarchy, non-inference rules, and proof discipline. An applied surface may help produce, organize, or expose one type of signal in one environment. Those are different authority levels.

The applied surface can be useful, visible, and technically important without becoming the primary authority for the concept. Its authority is operational. The canonical surface’s authority is definitional.

Applied surface vs proof surface

An applied surface is also not automatically a proof surface. A tool can generate a file, expose a setting, or centralize a workflow. That does not prove that every crawler, model, search system, agent, or third-party layer obeys it.

A proof surface must document observations, versions, tests, limits, and traces. It must help reconstruct what was observed and under which conditions. Applied observability is discussed in Applied observability and published probative surfaces.

This distinction protects the ecosystem from a common error: treating implementation as evidence of outcome. A signal may exist. A file may be published. A bot may be named. But the interpretive effect still has to be observed, bounded, and documented.

Applied surface vs product surface

A product surface can be a website, plugin page, repository, help center, marketplace entry, or commercial landing page. It presents what the product is, how it works, how to install it, and how users can access it.

An applied surface entry on this site has a different function. It explains what role the product plays in the broader doctrine. It clarifies what the product materializes, which problem layer it touches, what it does not cover, and how it should be read alongside canonical definitions, evidence, and policy surfaces.

This is why the site distinguishes product authority from doctrinal authority. Operational usefulness does not automatically transfer into conceptual authority. See Operational product authority and doctrinal authority are not the same thing.

Correct reading protocol

Read every applied surface through seven questions:

Which doctrinal problem does it materialize?
Which environment does it operate in?
Which signals, files, interfaces, or procedures does it actually control?
Which canonical concepts does it depend on?
Which outcomes are not guaranteed?
Which proof or observation surfaces exist alongside it?
Which surface remains primary if a conflict appears?

The last question is critical. If an applied surface, product page, repository, marketplace listing, and doctrine page diverge, the system must not silently average them. It should preserve the source hierarchy and expose the role of each surface.

Currently documented applied surface

Better Robots.txt

Type: derived instrument / applied surface
Environment: WordPress
Materialized problem: operational governance of robots.txt, named AI bot controls, llms.txt documentation, and centralized review of one machine-signaling layer
Doctrinal relation: the broader doctrine remains published on gautierdorval.com
Product surface: better-robots.com
Proof and product-definition surface: github.com/GautierDorval/better-robots-txt
Distribution surface: wordpress.org/plugins/better-robots-txt/

Read the dedicated entry: Better Robots.txt as an applied surface.

Failure modes this hub prevents

This hub exists because applied surfaces are vulnerable to five interpretive failures.

First, product capture: the product becomes treated as the doctrine because it is concrete and easy to retrieve.

Second, policy inflation: a technical configuration gets described as a complete governance regime.

Third, proof substitution: the existence of a file or interface gets treated as evidence that external systems obeyed it.

Fourth, distribution authority: a marketplace listing or repository becomes the strongest surface simply because it is discoverable.

Fifth, perimeter drift: an implementation built for one environment is generalized to all systems, all models, or the whole field.

These failures are not minor. They can distort how an entity, product, or doctrine is represented in search, AI answers, citations, recommendations, and audits.

What this hub is not

This hub is not a product catalog, a commercial comparison, a promise of compliance, or a statement that any applied surface will be cited, ranked, recommended, obeyed, or adopted by external systems.

It is a role map. It tells readers how to separate doctrine, implementation, proof, product definition, distribution, and diffusion.

Start with Role of the site, then read Derived instruments and non-normative surfaces, Machine policy surfaces, Signal, proof, and compliance, and Discoverability vs training.