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.
Definitions canon
/canon.md
Canonical surface that fixes identity, roles, negations, and divergence rules.
- Governs
- Public identity, roles, and attributes that must not drift.
- Bounds
- Extrapolations, entity collisions, and abusive requalification.
Does not guarantee: A canonical surface reduces ambiguity; it does not guarantee faithful restitution on its own.
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.
Dual Web index
/dualweb-index.md
Canonical index of published surfaces, precedence, and extended machine-first reading.
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.
- 01Response authorizationQ-Layer: response legitimacy
- 02Weak observationQ-Ledger
- 03AttestationQ-Attest protocol
- 04Audit reportIIP report schema
Q-Layer: response legitimacy
/response-legitimacy.md
Surface that explains when to answer, when to suspend, and when to switch to legitimate non-response.
- Makes provable
- The legitimacy regime to apply before treating an output as receivable.
- Does not prove
- Neither that a given response actually followed this regime nor that an agent applied it at runtime.
- Use when
- When a page deals with authority, non-response, execution, or restraint.
Q-Ledger
/.well-known/q-ledger.json
Public ledger of inferred sessions that makes some observed consultations and sequences visible.
- Makes provable
- That a behavior was observed as weak, dated, contextualized trace evidence.
- Does not prove
- Neither actor identity, system obedience, nor strong proof of activation.
- Use when
- When it is necessary to distinguish descriptive observation from strong attestation.
Q-Attest protocol
/.well-known/q-attest-protocol.md
Optional specification that cleanly separates inferred sessions from validated attestations.
- Makes provable
- The minimal frame required to elevate an observation toward a verifiable attestation.
- Does not prove
- Neither that an attestation endpoint exists nor that an attestation has already been received.
- Use when
- When a page deals with strong proof, operational validation, or separation between evidence levels.
IIP report schema
/iip-report.schema.json
Public interface for an interpretation integrity report: scope, metrics, and drift taxonomy.
- Makes provable
- The minimal shape of a reconstructible and comparable audit report.
- Does not prove
- Neither private weights, internal heuristics, nor the success of a concrete audit.
- Use when
- When a page discusses audit, probative deliverables, or opposable reports.
Exogenous governance often starts with a simple question: can you prove it? As long as nobody asks for opposable evidence, many organizations live with plausible outputs, vague promises, and untracked corrections. The moment a client, auditor, insurer, partner, or authority asks for a reconstructible justification, the problem changes. Content is no longer enough. A published probative chain is required.
What changes when the requirement comes from outside
An internal requirement still leaves room for ambiguity. Teams can rely on oral context, compensate informally, and correct over time. An external requirement turns the site and its published artifacts into a verification surface. The reader no longer evaluates only what is said, but also:
- where authority starts;
- which source takes precedence;
- what belongs to the canon;
- what remains observation only;
- how a correction is logged;
- how a challenge can be investigated.
At that point, information architecture becomes a proof infrastructure.
Why architecture must become probative
An architecture designed only to publish or rank leaves too much room for implicit reconstruction. Under exogenous constraints, that margin becomes expensive. If evidence must be opposable, the organization must be able to show:
- a canon: what serves as reference;
- a precedence order: what overrides what;
- a stable identity: who speaks, and within what scope;
- a correction trace: when, why, and under which version a change happened;
- a response legitimacy layer: when the system may answer and when it must abstain.
Without those elements, an organization may have a lot of content and still be poor in evidence.
The correct reading of the problem
The key point is that outside evidence requirements do not concern only the result. They concern the conditions that make the result defensible. That is why governance files and the evidence layer are not technical side notes. They publish the minimum reconstruction conditions.
This matters for audits, due diligence, insurability, enterprise procurement, public tenders, and contestable outputs. In all those contexts, the implicit question is the same: how do you know that what is being restated is what you actually authorize to be said?
What a mature organization publishes
A mature organization does not merely add a “compliance” page. It publishes a coherent apparatus:
- a governance entrypoint;
- a reference canon;
- negative boundaries;
- a bounded identity;
- observation traces;
- proof and attestation artifacts.
That shift is what moves a site from editorial presence to defensible governability.
What this does not guarantee
Publishing a probative chain does not guarantee compliance by systems, nor the disappearance of every drift. What it does change is decisive: systems face a more bounded surface, discrepancies become easier to qualify, and the organization can contest a reconstruction instead of arguing endlessly about an isolated output.