§02b Jupiter — Certification & Attestation — The specification registry

Mars® Spec › §02b Jupiter — Certification & Attestation › The specification registry

← The conformance certificate · Section index · Certificate composition and N-hop certificates →

3. The specification registry

The specification registry holds certificates, delta-attestation objects, traversal witnesses (§02a §4b.4), bounded-analysis records, and pre-invocation signal source registration records, indexed by target identity, governing-specification identity, and certification-path record. Downstream gates retrieve certificates from the registry at operation time. Traversal witnesses are first-class registered artifacts subject to the same content-addressability, append-only, and tamper-evidence requirements as certificate records; a traversal witness that is referenced in a Field 7 chain but is absent from the registry is a registry conformance failure.

The registry must satisfy three properties regardless of embodiment:

Content-addressable — every registered artifact is reachable by a deterministic identifier derived from its content
Append-only — no entry may be modified or deleted after registration
Tamper-evident — any modification is detectable

Three admitted embodiments:

Embodiment	Mechanism
Content-addressed distributed store	Retrieval against the artifact’s content hash establishes membership
Cryptographic ledger	Distributed ledger providing append-only history with cryptographic linkage
Cryptographic transparency log	Append-only Merkle transparency log; inclusion proof verifiable from log root

Additional identifier schemes: URI, decentralized identifier, content-addressed identifier, W3C-Verifiable-Credential-wrapped identifier.

Downstream consumption. An upstream artifact names the certificate by reference. The downstream gate retrieves the certificate from the registry and admits the operation only if the certificate passes all seven checks. Seven refusal conditions:

Certificate absent from the registry, or registry unreachable with no locally-cached replica carrying a valid inclusion proof available
Tamper-evident cryptographic binding (Field 9) fails verification
Recomputation witness (Field 7) fails — re-derived verdict does not match the Field 4 verdict
Verdict is non-conforming, or the conditions of a conditionally-conforming verdict are not satisfied at the operation’s typed scope
Operation’s typed scope exits the certificate’s declared scope (Field 5)
A falsifier annotation (Field 6) has fired — a declared revocation condition has occurred and has not been resolved by a replacement certificate
Temporal validity window (Field 8) has expired without re-attestation within the declared cadence

Downstream consumers must evaluate all applicable conditions before accepting a certificate. No deployment configuration may waive these conditions. Any deployment configuration declaring monotonic non-revocation is rejected at registration.

Multiple valid certificates for the same target. The registry may contain more than one certificate indexed under the same target identity and governing-specification identity:

Temporal succession. The later-issued certificate supersedes the earlier for operations whose timestamp falls within its validity window. The earlier certificate remains valid for operations within its window. No retroactive invalidation occurs from temporal succession alone.
Multiple certification paths. Certificates under distinct certification paths are not in competition — they are independent attestations. Where two paths yield conflicting verdicts, both certificates are registered; Field 6 of each carries a cross-path-conflict falsifier annotation referencing the other certificate’s identity.
Concurrent same-path certificates. A registry conflict. The registry records both but flags the conflict. The licensee must resolve by: (a) revoking one via a falsifier annotation; (b) issuing a replacement superseding both; or (c) declaring differential certification if issued by distinct verifiers with concordant verdicts. An unresolved conflict causes downstream gates to apply the more conservative verdict.

Cascading revocation. Upon falsifier-condition occurrence, revocation cascades through the audit trail to downstream consumers that admitted operations referencing the revoked certificate within a declared retention window. Per affected operation: a typed cascade record naming the operation, the revoked certificate, the cascade timestamp, and the cascade outcome.

Refusal of self-attestation. Where the deployment policy declares independence between verifier and target, the system refuses certificates whose declared verifier identity coincides with the target identity. The refusal carries a structural diagnostic identifying the self-attestation condition.

Registry unreachability discipline. Where the registry is unreachable due to network disconnection or degraded connectivity (DDIL state), the gate does not admit the operation. If a locally-cached replica carrying a valid inclusion proof is available, the gate may evaluate against it. Where neither the registry nor a valid locally-cached replica is reachable, the deployment policy declares either fail-immediately (refuse the operation) or pause-and-retry (hold the operation pending registry recovery) behavior; in either case, the gate does not admit the operation until registry retrieval or inclusion-proof verification succeeds. Latent unreachability — where the registry was reachable at gate entry but becomes unreachable before the inclusion proof is verified — is treated as a retrieval failure and routes to the declared DDIL behavior. No deployment policy may treat latent unreachability as a successful retrieval.

No bypass. No deployment-declared configuration, no operational override, and no upstream declaration of monotonic non-revocation may permit the downstream consumer to admit an operation referencing a certificate failing the structural conditions above. The registry unreachability discipline above specifies the only permissible deployment-policy variation in check 1; all other checks admit no policy variation.

Bounded-analysis records. A bounded-analysis record is issued when the entire analysis question posed under the governing specification is irreducible — the declared analysis battery has been exhausted and neither a conforming, non-conforming, nor conditionally-conforming verdict can be derived. A bounded-analysis record is not a certificate and does not carry a verdict in Field 4. It is a distinct first-class artifact registered in the specification registry alongside certificates.

This section is the canonical definition of the bounded-analysis record. §02a §5a.4 specifies the conditions under which the record is issued and the structure of the declared-irreducible entries it carries; the required field set is defined here and is not restated elsewhere. As with the conformance certificate, the inventive matter is the co-presence of the required fields, not a field count: a record carrying all ten fields is conforming regardless of additional fields; a record omitting any one is structurally deficient.

The ten required fields of a bounded-analysis record:

Field	Required content
(1) Record identity	A stable content-addressed identifier for this bounded-analysis record; used for registry storage and downstream reference
(2) Target identity	Same as conformance certificate Field 1; identifies what analysis was attempted
(3) Governing-specification identity	Same as conformance certificate Field 2, including bootstrap provenance; identifies the specification against which analysis was attempted
(4) Irreducibility basis	Typed declaration of why the analysis question is irreducible: declared battery exhausted without resolution; governing specification scope does not admit the target; target class has no applicable certification path; or analysis question structurally undecidable under the declared governing specification. Where the record is issued from the lift pipeline, this field carries the per-element irreducibility bases drawn from the declared-irreducible entry taxonomy of §02a §5a.4
(5) Declared-irreducible entries	The full set of declared-irreducible entries (§02a §5a.4 field table) for the analysis question; each entry identifies the element, the irreducibility basis, the best-available representation, and the scope impact
(6) Best-available aggregate representation	The probabilistic or partially-resolved aggregate form that is the best achievable representation of the analysis question’s answer; typed as `bounded`
(7) Analysis-effort record	The analysis battery record representing the full extent of analysis attempted, including all methods invoked, all partial results, and all inconclusive outcomes
(8) Gap referral	A typed referral record identifying the gap class and the registered gap-referral routing target declared for that class. Valid gap classes include all loci declared in §02a §7 — including traversal-surfaced loci `higher-order-analysis` and `cross-artifact-consistency` (§02a §4b.5) — and any operator-declared loci registered under the gap taxonomy
(9) Recomputation witness and temporal window	The multi-stage witness chain (§02a §5a.2) up to the point of irreducibility declaration, from which an inspector confirms that the declared battery was exhausted and the irreducibility basis holds; together with the issuance timestamp and the declared retention window within which the record is operative
(10) Authority attestation and tamper-evident binding	The declared authority that issued the bounded-analysis record and its attestation hash, with a binding computed over Fields (1)–(9) rendering the record tamper-evident; the same binding requirements as Field 9 of the certificate apply

Downstream gate treatment. A downstream gate that retrieves a bounded-analysis record in place of a conformance certificate treats it as a non-passing result. This is structurally distinct from a non-conforming verdict: a non-conforming certificate carries a derived verdict; a bounded-analysis record carries no verdict. Downstream gates must not admit operations on the basis of a bounded-analysis record. The refusal carries a diagnostic identifying the bounded-analysis record identity and its gap referral target. No deployment configuration may treat a bounded-analysis record as equivalent to a passing certificate.

Pre-invocation signal source registrations. The specification registry holds pre-invocation signal source registration records (§02e) alongside certificate records as first-class governance artifacts. The registry must treat source registration records with the same tamper-evidence, append-only, and content-addressability requirements as certificate records. Additional requirements:

Versioning. A source registration record carries a version identifier and an effective-date range. When a source’s registration is updated, the prior version is retained as a historical record and the new version takes effect from its declared effective-date.
Delta-attestation participation. A scope-breaking update to a source registration record triggers cascading revocation of all certificates issued under batteries that consumed signals from the prior-version source registration.
Cross-reference. Each certificate record carries a reference to the source registration record version that was in effect when the battery ran.

← The conformance certificate · Section index · Certificate composition and N-hop certificates →