§02c Jupiter — Non-Language Bridge — Scope-of-applicability certificates
Mars® Spec › §02c Jupiter — Non-Language Bridge › Scope-of-applicability certificates
← Named-authority standing · Section index · Interaction-protocol lift to order-typed form →
8. Scope-of-applicability certificates
8.1 Single-link certificate
A scope-of-applicability certificate is a typed, cryptographically-signed record bound to a certified predicate’s content hash. It declares three things:
(a) The certified scope. Expressed as typed scope conditions over the predicate’s certified input range: ranges, enumerations, and typed predicates over declared vocabulary fields.
(b) Domain and temporal annotations. Required subfields: (i) a temporal validity bound expressed as a not-before/not-after pair or version-epoch range; (ii) a domain restriction expressed as a typed predicate over declared vocabulary. An empty field (b) is not conforming; a positive assertion of both subfields is required.
(c) Falsifier annotations. Invalidation triggers including: upstream-anchor revocation, reviewer-attestation withdrawal, specification advancement classified scope-restricting or scope-breaking (§02b §5.3), scope exit, and falsifier-condition occurrence. Scope-extending amendments (§02b §5.3) are non-invalidating but require re-attestation notification to downstream consumers that relied on the narrower scope as the certified bound. Where the predicate carries a non-language-provenance anchor, additional triggers are tied to revision of the engineering program, the analysis specification, or the interpretation-generation specification referenced in that anchor, cascading invalidation to downstream consumers.
The certificate makes cache-the-meaning structurally enforceable: a downstream consumer re-uses a certified predicate only within the scope conditions under which it was originally certified. Outside those conditions, re-analysis is triggered — not silent extrapolation admitted.
Scope-match discharge module. At every re-entrance event — each instance where a downstream consumer presents a certified predicate for use — the scope-match discharge module executes the following five-check sequence in order: (1) signature verification: the certificate’s cryptographic signature is verified under the registered public key; (2) invalidation check: the certificate is confirmed absent from the invalidation log and all declared falsifier annotations (§8.1(c)) are confirmed not fired; (3) input-range containment: the consumer’s declared input range is confirmed a subset of the certified input range from the scope conditions; (4) domain match: the consumer’s declared domain is confirmed within the domain restriction from annotation (b); (5) temporal validity: the current timestamp or version epoch is confirmed within the not-before/not-after pair or version-epoch range from annotation (b). A failure on any check produces an immediate per-request refusal; the remaining checks are not evaluated. On passing all five checks, the discharge module emits a signed discharge record and admits the consumer for this request.
Discharge record. The signed discharge record is produced per admission and is recorded in the audit trail. It is signed over: the certified predicate’s content hash ‖ the certificate’s content-addressed identifier ‖ the consumer’s declared input range ‖ the admission decision (ADMIT or REFUSE). The discharge record makes the admission decision externally verifiable by any party holding the predicate content hash, the certificate, and the consumer’s declared input range.
Scope exit consequence. When the consumer’s declared input range exits the certified scope (check 3 above fails), the consequence is a per-request refusal for that consumer request only. The certificate itself is not persistently invalidated. The predicate remains certifiable for other consumer requests whose input ranges fall within the certified scope. A scope exit event is recorded in the audit trail as a typed scope-exit record but does not modify the certificate’s validity state.
Registered re-entrance participant. A downstream consumer that is admitted as a recurring re-entrance participant under a given certificate is required, as a condition of admission, to report the content hash of any downstream certification it produces from the admitted predicate back to the audit trail. This report is a registered re-entrance obligation: a consumer that fails to report a downstream certification content hash within the declared reporting window is recorded as a non-reporting re-entrance participant, and subsequent re-entrance requests from that consumer under the same certificate are refused pending resolution. The registered re-entrance obligation is the structural mechanism enabling computation of the divergence-rate metric.
Divergence-rate metric. For each scope-of-applicability certificate, a divergence-rate metric is computed over all registered re-entrance participants admitted under that certificate within the declared computation window. The computation proceeds as follows: (1) form the scope-match-equivalence class — the set of all registered re-entrance participants whose admitted input ranges are within the same scope cell; the scope cells are a finite partition of the certified scope determined by the certificate’s input-range annotations, domain annotations, and temporal annotations, such that two input ranges are in the same scope cell if and only if they satisfy the same subset of the annotation predicates; (2) for each pair within the same scope-match-equivalence class, evaluate whether the pair’s reported downstream certification content hashes represent agreement or disagreement under a declared typed-disagreement relation; (3) compute the divergence rate as the ratio of disagreeing pairs to total pairs within the equivalence class. The divergence rate is not computed across participants in distinct scope cells; range intersection alone is insufficient — scope-cell membership is the governing criterion. The divergence-rate metric is publishable and independently recomputable by any inspector with access to the audit trail and the certificate. A threshold-triggered alert is emitted when the divergence rate within any scope cell exceeds a declared threshold registered with the certificate; the alert is recorded in the audit trail and reported to the certifying authority.
Falsification direction and the sampled reference re-discharge. The divergence-rate metric operates in the falsification direction: a rate above the declared threshold refutes a soundness claim on the certified-predicate caching, but a low rate does not by itself establish soundness — two consumers may agree and both be wrong, a correlated-error condition that pairwise agreement cannot detect. The affirmative complement is the sampled reference re-discharge: under a declared sampling policy registered with the certificate (a per-scope-cell sampling rate or a per-interval quota), a sampled subset of admitted re-entrance events is independently re-discharged by a reference verifier — a verifier independent of the consumers being compared, deriving its verdict from the registered specification and the sampled event’s recorded consumer input range, not from any compared consumer’s output — and the reference downstream certification is compared against the sampled event’s reported downstream certification under the same typed-disagreement relation. The resulting reference-divergence rate is recorded per scope cell alongside the pairwise divergence rate; exceedance of its declared threshold triggers the same alert and authority-reporting path. The sampled reference re-discharge detects the correlated-error condition the pairwise metric cannot; the two measurements together bound cache-the-meaning soundness from both directions. Where a downstream certification transits a gate of the same deployment, the audit trail’s gate record of that certification satisfies the registered re-entrance obligation by observation; the reporting obligation remains operative for downstream certifications not otherwise observable in the deployment’s audit trail.
8.2 Boundary-closure attestation
Where a registered specification is lowered from a formal domain model (§01), the specification carries a version-bound boundary-closure attestation asserting that the lowered specification faithfully and completely captures the source model — across all three constitutive dimensions (order, perspective, variant) — across the informal-to-formal boundary.
The attestation is anchored to identified source elements. Each consideration in the domain model must be traceable to an identified source element in the specification — per-consideration traceability is the minimum required granularity. Completeness is auditable by enumerating which source elements are covered by which specification elements.
The attestation is bound to a specific model revision. A change of model revision requires re-attestation through the delta-attestation lifecycle (§02b §5). Coverage-narrowing produces at least scope-restricting delta-classification; model-revision re-binding or completeness withdrawal produces scope-breaking delta-classification (§02b §5.3).
The boundary-closure attestation is a first-class lifecycle object — registered, re-attested on amendment, classified under the delta-attestation lifecycle, and cascaded. It is distinct from the conformance certificate (§02b §2): the conformance certificate attests that a specific artifact conforms to a specific version of the governing specification; the boundary-closure attestation attests that the governing specification itself faithfully captures the source model. The versioned re-discharge module (§02b §5) consults the boundary-closure attestation’s version binding as a precondition of admission at the composition gate: a predicate whose associated analysis specification carries a boundary-closure attestation bound to a model revision that differs from the version currently registered in the specification registry is not admitted until re-attestation is recorded under the delta-attestation lifecycle. A boundary-closure attestation and a versioned re-discharge module are jointly necessary — a deployment that maintains boundary-closure attestations but does not consult them at the re-discharge gate, or that enforces the re-discharge gate without binding it to the boundary-closure attestation version, is a structurally incomplete deployment and is refused at deployment registration with a structural diagnostic identifying the missing binding.
8.3 N-hop composed scope-of-applicability certificate
When typed linguistic predicates are composed across multiple domain boundaries through a sequence of registered cross-domain typed interfaces, the N-hop composed scope-of-applicability certificate tracks the composition path, the accumulated scope intersection, and the accumulated loss-of-information record. The composed certificate is required for every multi-domain composition of N ≥ 1 registered cross-domain typed interface; the N = 1 case is the minimal composed certificate (singleton composition-path record, one per-hop scope-intersection entry, one per-interface loss record, one per-interface joint-authority attestation hash in the composed-attestation hash). For N = 0 (no interface traversal), the applicable certificate is the single-link scope-of-applicability certificate (§8.1). The N-hop composition discharge module is an enforcement mechanism registered in the deployment registry (§6.1) under the typed-module-interface-refusal mechanism-kind, bound to the same R2 registry row that governs the cross-domain composition module (§3); the discharge module is not independently operable or independently registered outside this binding — a deployment implementing the N-hop composition discharge module without a corresponding deployment-registry row in the enclosing architecture’s typed registry is non-conforming and refused at deployment registration.
Eight-field composed certificate: The inventive matter is the co-presence of all eight declared fields, not their count or labeling: a composed certificate carrying all eight fields is conforming regardless of additional fields; a composed certificate omitting any one field is non-conforming regardless of field count.
(a) Source-predicate identity. Content hash, scope-of-applicability certificate content hash, registered specification identity.
(b) Composition-path record. Ordered sequence [I₁, I₂, …, Iₙ] of registered cross-domain typed interfaces traversed. Each Iₖ identified by: registered identifier; joint-authority attestation hash (recomputable from distinct source/target doctrine-authority signatures); scope-of-applicability certificate content hash; source- and target-domain specification identities.
(c) Per-hop scope-intersection record. For each k ∈ {1, …, N}: Sₖ = scope(predicate_{k-1}) ∩ scope(Iₖ), where predicate₀ is the source predicate and predicateₖ is the intermediate-domain predicate at hop k.
(d) Composed scope field. scope(source predicate) ∩ scope(I₁) ∩ scope(I₂) ∩ … ∩ scope(Iₙ) — monotonically narrowing pairwise intersection. A long composition path cannot widen a predicate’s scope.
(e) Loss-of-information record union. loss(I₁) ∪ loss(I₂) ∪ … ∪ loss(Iₙ) — the accumulated vocabulary fields not preserved in the target-domain predicate.
(f) Any-link falsifier annotations. Invalidation conditions including: invalidation of any Iₖ; withdrawal of any joint-authority signature of any Iₖ; expiration or amendment classified scope-restricting or scope-breaking of any scope-of-applicability certificate along the path (§02b §5.3); falsifier-condition occurrence on any Iₖ; withdrawal of any reviewer attestation along the path. Scope-extending amendments to any scope-of-applicability certificate along the path are non-invalidating but require re-attestation notification to downstream consumers that relied on the narrower scope as the certified bound.
(g) Joint-authority composed-attestation hash. H(N ‖ H₁ ‖ H₂ ‖ … ‖ Hₙ) where N is the 4-byte big-endian hop count, Hₖ is the joint-authority attestation hash of interface Iₖ, and ‖ is canonical concatenation. All Hₖ within a single N-hop composed certificate must be computed under the same declared collision-resistant hash function (one of: SHA-256, SHA-512, SHA3-256, BLAKE3), which must be declared in this field and carried in the composition-path record. Recomputable from the per-interface hashes in the composition-path record.
(h) Cryptographic signature. Over Fields (a)–(g), EUF-CMA-secure. N is unbounded. The N-hop generalization holds for any N ≥ 1. For N = 1 (a single registered cross-domain typed interface), the composition-path record is a singleton sequence and the per-hop scope-intersection record has one entry; all eight fields are required. For N = 0 (no interface traversal), the applicable certificate is the single-link scope-of-applicability certificate (§8.1).
Multi-source convergence. Where the target-domain predicate is derived by N-hop composition from multiple source-domain typed linguistic predicates joined at an intermediate domain, the composed certificate declares multiple source-predicate identities (each a separate instance of Field (a)) and multiple composition paths converging at the join hop (each a separate composition-path record contributing to Field (b)). The joint-authority composed-attestation hash of Field (g) is recomputable from per-source-path per-interface joint-authority attestation hashes by canonical concatenation including a declared convergence marker at the join hop. A multi-source composed certificate that omits the convergence marker or conflates the per-source composition paths into a single path is structurally deficient; the discharge module refuses admission. A deployment admitting multi-source convergence outside the composed certificate structure — by merging source predicates before composition or by producing a composed certificate without declared convergence — is non-conforming and refused at deployment registration. The multi-source convergence variant is a structural extension of the N-hop composed certificate, not a separable architecture: it is governed by the same eight fields, the same discharge module, and the same deployment-registry binding, and cannot be independently implemented without the full composed-certificate structure.
Anchored re-entrance (composed-of-composed). Where a target-domain predicate produced by an N-hop composition is itself re-entered as the source predicate of a subsequent M-hop composition, the subsequent composition emits a composed-of-composed certificate whose composition-path record is the concatenation of the prior N-hop path and the new M-hop path, and whose composed-attestation hash is recomputable from the prior N-hop composed-attestation hash and the new per-interface joint-authority attestation hashes. The prior composed certificate’s content hash is carried as the source-predicate-identity field of the subsequent composed certificate, binding cryptographic continuity across both compositions. A composed-of-composed certificate is governed by the same eight-field structure, the same discharge module, and the same deployment-registry binding as any N-hop composed certificate; it is not a distinct artifact class and cannot be independently implemented or independently claimed as a separable output of any deployment that does not enforce the full N-hop composed certificate structure.
Composition discharge module — six refusal conditions:
| # | Condition |
|---|---|
| 1 | Composed certificate signature fails verification |
| 2 | Composed-attestation hash fails recomputation from the per-interface joint-authority attestation hashes |
| 3 | Any Iₖ is absent from the specification registry or fails its own joint-authority attestation hash recomputation |
| 4 | Composed scope field fails recomputation from the source predicate’s certified scope and each interface’s scope-of-applicability certificate along the path |
| 5 | Any any-link falsifier annotation has fired |
| 6 | Consumer’s input range exits the composed scope field |
When admitted, the composed scope becomes the predicate’s active scope-of-applicability certificate at the consumer.
Atomicity. A composed certificate is an atomic unit. Partial re-discharge is not permitted. Upon any-link withdrawal or any-link delta-attestation event, the entire composed certificate is invalidated and a new composition must be initiated from a live source predicate. The versioned re-discharge module (§02b §5.4) refuses any delta-attestation operation that references a composition path containing a withdrawn link identity, recording refusal type COMPOSITION-PATH-INVALID.
Interaction with the delta-attestation lifecycle. A scope-breaking amendment to any registered artifact in the composition path — an interface Iₖ, any scope-of-applicability certificate along the path, the governing specification of the source predicate — fires an any-link falsifier event on every N-hop composed certificate traversing that artifact, triggering the cascading invalidation sequence. A scope-restricting amendment fires an any-link falsifier event with a deadline: affected composed certificates are valid until the re-discharge deadline declared in the triggering delta-attestation object and refused thereafter. Scope-extending amendments are non-invalidating but require re-attestation notification to downstream consumers that relied on the prior narrower scope as the certified bound. Scope-preserving amendments produce no any-link falsifier event. These interaction rules are not separable from the eight-field composed-certificate structure: the any-link falsifier annotations in Field (f) are the structural mechanism through which delta-attestation lifecycle events propagate into composed-certificate validity.
Empty per-hop intersection. Where the per-hop scope intersection Sₖ = scope(predicate_{k-1}) ∩ scope(Iₖ) is empty at any hop k, the composition terminates at hop k and a typed composition-failure record is emitted identifying the hop number, the source scope entering that hop, and the interface scope that produced the empty intersection. The composed certificate cannot be issued for an empty intersection; the composition-failure record is registered in the specification registry.
Cascading invalidation upon any-link withdrawal. Upon withdrawal of any Iₖ, any joint-authority signature, any scope-of-applicability certificate along the path, or any falsifier-condition occurrence: (1) the audit trail is queried for all N-hop composed certificates whose path includes the withdrawn link within the declared retention window; (2) a typed cascade record is created per affected certificate; (3) downstream consumers are notified; downstream certifications are invalidated; (4) subsequent compositions traversing the withdrawn link are refused until re-attestation is recorded.
← Named-authority standing · Section index · Interaction-protocol lift to order-typed form →