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.
Entity graph
/entity-graph.jsonld
Descriptive graph of entities, identifiers, and relational anchor points.
- Governs
- Admissible relations, receivable authorities, and conflict arbitration.
- Bounds
- Abusive merges, copied authority, and unqualified silent arbitration.
Does not guarantee: Describing a graph or registry does not make an exogenous source endogenous truth.
Complementary artifacts (2)
These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.
Identity lock
/identity.json
Identity file that bounds critical attributes and reduces biographical or professional collisions.
Definitions canon
/canon.md
Canonical surface that fixes identity, roles, negations, and divergence rules.
Multisite framework for distributed interpretive authority
This framework is used to classify, hierarchize, and connect the surfaces that belong to one ecosystem before a dedicated multisite artifact is published.
It does not yet create the specialized governance file. It provides the public structure that will later make that file unambiguous.
Objective
The objective is not to stack domains. The objective is to prevent several surfaces linked to the same actor from becoming competitors in machine reading.
A multisite framework must therefore answer six questions:
- Which surface carries the source doctrine?
- Which surfaces may adapt that doctrine without redefining it?
- Which surfaces are canonical only on a local perimeter?
- Which public repositories play an adjacent, specialized, or probative role?
- Which dependencies must be made visible through linking, graphs, and role pages?
- Which surfaces do not have the right to override certain others?
Minimum surface classes
1. Master doctrinal surface
Carries authorship, definitions, doctrine, precedence decisions, and conceptual boundaries.
2. Thematic doctrinal surface
Deepens a subfield without replacing the source doctrine.
3. Institutional or application surface
Frames a lab, organization, program, application, or collaboration context.
4. Commercial or operational surface
Adapts discourse to an offering, mandate, service, or conversion logic.
5. Product surface
Becomes canonical on product truth, but not on all of the general doctrine.
6. Probative surface
Exposes evidence, logs, attestations, validations, simulations, or test cases.
7. Adjacent public repository
Registry, manifesto, versioned documentation, specialized reference, simulation, or restricted implementation surface.
Fields to declare for each surface
Each surface should be qualified with a minimum set of stable fields.
- surfaceRole: doctrinal-master, doctrinal-thematic, institutional, commercial, product, probative, repository-adjacent;
- authorityLevel: primary, secondary, local, adjacent, archive, experimental;
- canonicalTopics: topics on which the surface may be read as source;
- dependsOn: upstream surfaces from which it conceptually derives;
- mustNotOverride: surfaces or topics it may not override;
- adaptationRights: what kind of adaptation is allowed;
- versionOwner: where the reference version is maintained;
- publicProofType: identity, manifesto, test, simulation, documentation, product, doctrine, or evidence.
These fields do not yet require one specific file format. They primarily require a classification discipline.
Minimum process
MS-1: inventory the surfaces
List every domain, subdomain, microsite, documentation center, and public repository that may be read as a source.
MS-2: designate the master doctrinal surface
Without that decision, everything else remains probabilistic.
MS-3: assign a role to every surface
No surface should remain in a vague status such as “part doctrine, part product, part offering, part evidence”.
MS-4: assign an authority level
A surface may be primary on a narrow perimeter and secondary on a wider one.
MS-5: declare canonical topics
It must be explicit where a surface is source, and where it is not.
MS-6: declare dependencies and non-override rules
This is the core of the framework. A surface may derive from another without having the right to redefine it.
MS-7: connect the surfaces for humans and machines
Role pages, definitions, doctrine, linking, graphs, and machine-first artifacts must converge toward the same hierarchy.
MS-8: prepare the dedicated multisite artifact
Once the classification is stable, it may be projected into a versioned specialized governance file.
Illustration of a multisite ecosystem
The following illustration is not normative. It simply shows how one actor may distribute roles without collapsing them.
Master doctrinal surface
gautierdorval.com
Thematic doctrinal surfaces
interpretive-governance.orgInterpretive-SEO.org
Institutional or application surfaces
InferensLab.orgInferensLab.com
Commercial or operational surface
Pagup.com
Product surfaces
Better-robots.comBialty.comWpstreetview.comAutolinksforSEO.comVidseo.dev
Adjacent public repositories
github.com/GautierDorval/gautierdorval-identitygithub.com/GautierDorval/pagup-identitygithub.com/GautierDorval/interpretive-governance-manifestgithub.com/GautierDorval/better-robots-txtgithub.com/GautierDorval/interpretive-agentic-referencegithub.com/GautierDorval/ssa-e-a2-doctrinegithub.com/GautierDorval/interpretive-governance-test-suitegithub.com/GautierDorval/authority-governance-simulation-reference
The reading rule is not that all these surfaces are equivalent. The rule is that each surface must be readable according to its status.
How public repositories should be read
Within this framework, public repositories may be grouped by family.
- Identity registries:
gautierdorval-identity,pagup-identity - Manifest or versioned doctrine:
interpretive-governance-manifest,ssa-e-a2-doctrine - Specialized reference:
interpretive-agentic-reference - Validation and tests:
interpretive-governance-test-suite - Simulation:
authority-governance-simulation-reference - Product or implementation-adjacent:
better-robots-txt
None of these repositories automatically receives the same precedence as a master doctrinal surface. Their authority depends on the role explicitly assigned to them.
Recommended internal-linking rules
- every derivative surface points back to the master doctrinal surface for source concepts;
- every product surface points back to the shared doctrine when it mobilizes a general framework;
- every commercial surface avoids silently reformulating the doctrine;
- every adjacent public repository is attached to a human-readable role or explanatory surface;
- evidence and test surfaces must not become substitutes for doctrine.
What this framework prepares
Once this framework is stabilized, the next step is to project the hierarchy into a dedicated multisite artifact. That artifact must not be the place where classification is invented. It must be the place where an already decided classification is published.