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.
governed-context-runtime.json
/governed-context-runtime.json
Published machine-first governance surface.
- Governs
- Part of the corpus reading conditions.
- Bounds
- An inference zone that would otherwise remain implicit.
Does not guarantee: This file does not, on its own, guarantee system obedience.
From doctrine to execution
A doctrine, a standard, a runtime, a test instrument, and an observatory do not produce the same kind of authority. They can participate in one ecosystem without becoming interchangeable.
This page connects those surfaces by function and evidence class. It does not turn an implementation into doctrine, a commit into deployment, or an observation into certification.
Bounded generation input: public registry version 2.3.0, SHA-256
410D456315EBA944C51D8211C088277BAE873E09B53E24F25674774D58C705D4, 16,318 bytes. Its temporal state is bounded to2026-08-19T17:16:22.921Z. This provenance establishes the bytes used to build the page, not a LIVE state.
The chain is not a single hierarchy
Authority is resolved by claim type. The identity repository owns identity and authorship attribution. The versioned doctrine owns SSA-E + A2 + Dual Web. The Interpretive Governance manifest owns the normative standard. The gautierdorval.com definitions registry owns public definitions. Runtime, measurement, producer, and interface contracts remain distributed among their respective components.
The topology controller tells readers where to find authority. It does not inherit all those authorities.
| Component | Role | State established by the input | Admissible evidence | Limit |
|---|---|---|---|---|
| Versioned doctrine | Defines SSA-E + A2 + Dual Web | versioned |
Pinned public release and source | Is neither a separate standard nor an implementation |
| Interpretive Governance standard | Defines the normative standard | versioned |
Pinned public manifest and release | A validator or public site cannot redefine it |
| Governed context runtime | Serves precompiled objects under a bounded contract | documented, implemented-in-source |
Contract and source implementation | Current deployment and observation are unknown in this campaign |
| Admission | Checks entry under an experimental contract | Not publicly projected in this campaign | Bounded private evidence, when authorized | Does not prove semantic fidelity, trust, or production readiness |
| InferensLab | Controls or measures under engine-local contracts | documented, implemented-in-source |
Exact baselines, judges, and local contracts | Is not the general doctrinal authority |
| Observatory | Presents an interface and read model | documented, implemented-in-source |
Its own source and provenance for derived data | Does not own upstream state, freshness, or causality |
| End-to-end delivery authority | Future integration link | not-established |
No integrated evidence in this campaign | No component can claim this authority by aggregation |
Read status on separate axes
Each component has distinct axes:
- specification, what is defined;
- implementation, what exists in source;
- deployment, what was promoted to an environment;
- observation, what was observed at a specific time and under a method;
- independent audit, what an external auditor examined;
- independent reproduction, what a third party reproduced.
A state on one axis never establishes the next axis automatically. A responding endpoint does not prove that a downstream system read it. Reading does not prove use. Use does not prove faithful restitution. An observation is neither an attestation nor a certification.
Moving from concept to bounded implementation
The safe transition follows four questions.
1. Which source defines the claim?
Start with the claim type, then consult the appropriate doctrine, standard, or definitions registry. Do not select the most technical or visible surface by default.
2. Which component implements it?
An applied surface materializes one part of the problem in a specific environment. Its operational scope must remain narrower than the doctrine or standard it consumes.
3. Which evidence class exists?
A commit and tree prove source state. A release proves a versioned object. Deployment evidence binds an artifact to a promotion. An HTTP or data observation must be timestamped, reproducible, and accompanied by explicit limits.
4. Which inference remains prohibited?
The joint existence of doctrine, runtime, ledger, engine, and observatory does not prove end-to-end governed delivery. That conclusion requires integrated evidence that is not established here.
Associated machine surfaces
/implementation-registry.json: filtered public roles, contracts, and status axes;/.well-known/implementation-registry.json: byte-identical mirror;/distributed-authority-map.json: authority resolved byclaimTypeId;/governed-context-runtime.json: public runtime contract.
The first three routes belong to the governance overlay and are not produced by the site repository’s standalone build. These files clarify interpretation. They do not absolutely constrain an external model’s behavior.
Continue reading
Read the governed context runtime for its technical boundary, then applied surfaces to distinguish implementation, proof, product, and distribution.
Laboratory projection
This page remains the canonical reading map. The public doctrine-to-execution program separately bounds the research question, protocol, and evidence state. The program’s existence is not a result.