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.
Interpretation policy
/.well-known/interpretation-policy.json
Published policy that explains interpretation, scope, and restraint constraints.
- Governs
- Response legitimacy and the constraints that modulate its form.
- Bounds
- Plausible but inadmissible responses, or unjustified scope extensions.
Does not guarantee: This layer bounds legitimate responses; it is not proof of runtime activation.
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 (1)
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.
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.
The moment an answer can be challenged, publishing has to change. A contestable output is not merely a possible wrong answer. It is an output that can trigger an appeal, objection, revision request, justification demand, or legal exposure. At that point, logging and traceability stop being technical options. They become design constraints.
Appeal changes the nature of the system
Many teams still think of traceability as a bonus observability feature. That is too weak. When an output influences access, a decision, a commitment, a regulatory interpretation, or a contractual perimeter, the possibility of appeal changes the nature of the system. The organization must be able to show:
- what was read;
- what prevailed;
- what was ignored;
- what was inferred;
- what should have led to abstention.
Without that, there may be a technical log, but not an investigable justification.
Why logging must be designed upstream
Most organizations discover this only after an incident. That is too late. A useful trace cannot be reconstructed easily afterward if the architecture does not clearly distinguish canon, observation, proof, and legitimacy rules. The issue is not merely to “keep logs.” The issue is to publish a system in which a contested output can be compared against an opposable base.
Observation, proof, attestation
Three layers must be kept distinct:
- observation: what was seen or measured;
- proof: what is published as an opposable surface;
- attestation: what formalizes a finding under a declared protocol.
That distinction avoids two common errors: taking observation for proof, or over-claiming attestation from a partial log.
What design must include
If contestability is real, design must include:
- response conditions;
- abstention thresholds;
- interpretation traces;
- a proof qualification protocol;
- a canon that makes discrepancy measurable.
Appeal is therefore not a downstream legal concern. It is an upstream exogenous governance force.