§02c Jupiter — Non-Language Bridge — Analysis of lifted artifacts
Mars® Spec › §02c Jupiter — Non-Language Bridge › Analysis of lifted artifacts
← The non-language-provenance anchor (inbound boundary) · Section index · The actuation anchor (outbound boundary) →
3. Analysis of lifted artifacts
The §02a analysis battery (§02a §3) and battery execution discipline (§02a §3a) apply to non-linguistic artifacts lifted through the inbound bridge on the same terms as to any other artifact. The same declared pass set, the same PassRecord structure, the same mechanical tri-state status rule, the same per-pass audit emission, the same pre-emission gates, and the same procedural-confidence derivation function govern analysis of a lifted predicate as of any linguistic predicate.
This section specifies only what is additional or different at the non-language boundary.
PV-gate anchor requirement (non-language boundary). The procedural-verification gate (§02a §3a.3) refuses emission of any predicate in a CertifiedBundle that arrived via the inbound bridge but lacks a complete non-language-provenance anchor (all seven structural invariants, §2), including the faithfulness attestation (Field 7). A predicate arriving via the non-language bridge without a complete anchor does not satisfy the PV-gate’s provenance requirement. Refusal results in verdict downgrade to REFER or no bundle emission.
NB2 — No implicit cross-domain ontology equivalence. Where the §02a battery processes predicates drawn from distinct domain specifications — through registered cross-domain typed interfaces — composition may not proceed by string match, vocabulary overlap, LLM-assisted equivalence judgment, or operator assertion. Cross-domain composition is a structural condition on what predicate combinations may produce a joint verdict.
Domain determination by governing source authority. The composition module determines each predicate’s domain by the source authority that governs its vocabulary — not by the predicate’s surface vocabulary strings. Two predicates governed by distinct source authorities are cross-domain and the interface requirement triggers even where their surface vocabulary strings coincide. Surface-string identity across domains is not treated as semantic equivalence. The governing source authority for each predicate’s vocabulary is recorded in the predicate’s provenance; the composition module consults that record, not the surface form.
Sole-channel enforcement. The cross-domain composition module is the sole channel through which the deployment admits composition of typed linguistic predicates governed by distinct source authorities. The deployment exposes no second composition channel that bypasses the module. No code path admits cross-domain composition by string match, vocabulary overlap, LLM-assisted equivalence judgment, or operator assertion. Configurations attempting to enable any such fallback path are rejected at deployment registration with a structural diagnostic identifying the rejected configuration. This enforcement is not a policy declaration; it is a structural property of the typed interface: there is no admission path for cross-domain composition that does not pass through the module.
Each entry in the cross-domain typed interface registry is a seven-field record. The inventive matter is the co-presence of all seven declared fields, not their count or labeling: an interface record carrying all seven fields is conforming regardless of additional fields; an interface record omitting any one field is non-conforming regardless of how many fields it carries or how they are labeled.
| Field | Contents |
|---|---|
| 1 | registered-identifier — unique content-addressed identifier for the interface |
| 2 | source-domain-specification-identity — spec_id and version of the source domain |
| 3 | target-domain-specification-identity — spec_id and version of the target domain |
| 4 | typed-translation-rule-set — ordered sequence of mapping rules, each of the form (source-aspect → target-aspect, loss-of-information-annotation), expressed in a decidable logical fragment; rules are applied in declared order and a downstream inspector re-verifies the translation by replaying the sequence |
| 5 | loss-of-information-record — set of {source-aspect, untranslated-content-description} pairs recording which source-domain vocabulary fields are not preserved in the target-domain translation |
| 6 | scope-of-applicability-certificate — typed, signed certificate bounding the conditions under which the interface is valid |
| 7 | joint-authority-attestation-hash — recomputable from the distinct recorded signatures of the source-domain and target-domain doctrine authorities |
Interface bootstrap. A cross-domain typed interface is admitted to the registry only through a bootstrap procedure with four stages, mirroring the single-domain bootstrap (§02a §2.2) with two additional cross-authority requirements:
-
Source identification. The natural-language cross-walk source is identified with full provenance: document identity, version, publication date, joint-authority identity. The source must be authored by an authority both domains recognize (joint publication, inter-agency memorandum of agreement, regulatory cross-walk, vendor data-model agreement, or inter-organizational framework). Sources authored unilaterally by one domain are refused at registration.
-
Compilation and ground-discharge. The source is compiled into typed translation predicates in a decidable logical fragment (e.g., QF_UFLIA). A satisfiability decision procedure discharges the predicates for well-formedness, internal consistency, and scope-of-applicability. Failure of any discharge property is a hard gate failure.
-
Cross-authority reviewer attestation. Named reviewers with declared standing in each domain attest per translation predicate. Attestation by reviewers of only one domain is refused. A declared inter-rater agreement statistic satisfying the five agreement-statistic properties (§01 §8) is computed per domain against a declared threshold registered in the specification registry before the attestation act begins; a statistic value below the declared threshold in either domain is a hard gate failure.
-
Emission. The interface emits as a bundle carrying: the source- and target-domain specification identities; the typed translation predicates; the SMT discharge record; the cross-authority attestation records including the joint-authority attestation hash (recomputable from the distinct doctrine-authority signatures); the bootstrap-provenance record (joint-authority source content hash, reviewer-attestation statistic, declared threshold); the scope-of-applicability certificate; the loss-of-information record; and a cryptographic signature over all foregoing fields. The source-authority content hash is one of the signed fields, so the signature binds the interface to its source and verification recomputes over the same fields. A bundle missing any of these components is refused at registration.
Composition-execution witness and causal binding. When the composition module admits a cross-domain composition, it applies the interface’s translation rules and emits a target-domain predicate accompanied by a cross-domain-provenance record carrying:
- The source-domain predicate’s identity and content hash
- The registered interface’s identity
- The translation rule applied
- The scope intersection of the source predicate’s certified scope and the interface’s scope-of-applicability certificate
- The loss-of-information record from the interface
- A composition-execution witness — a recomputation record from which an independent inspector re-derives the target-domain predicate’s content hash from the source-domain predicate’s content hash under the named translation rule; co-presence of a valid-looking interface identity and a target-domain predicate is insufficient — the witness must reproduce the derivation
- A cryptographic signature over the concatenation of
(source-domain predicate content hash ‖ interface identity ‖ translation rule identity ‖ target-domain predicate content hash)
The cross-domain-provenance record accompanies the target-domain predicate through all downstream verification. A downstream consumer refuses a target-domain predicate whose composition-execution witness does not re-derive the presented predicate’s content hash from the source predicate’s content hash under the named translation rule — this is causal binding, not associative co-presence. Where the source-domain predicate carries a non-language-provenance anchor (§2), the cross-domain-provenance record additionally references that upstream anchor, the engineering program’s bridge-form classification, and the signal domain classification, so that the target-domain predicate’s lineage to the originating non-linguistic engineering signal is preserved across the cross-domain composition.
Domain-authority directory. The system maintains a domain-authority directory — a registry held independently of any registered cross-domain typed interface — recording for each registered domain its governing doctrine authority and the joint-authority relationships the domain recognizes. When no registered interface exists for a source-target domain pair, the composition module consults the directory to identify the joint authority that would be required to author the cross-walk source, without reference to the absent interface. The directory is the structural primitive that makes knowledge-gap referral actionable: it identifies the routing target regardless of whether an interface has ever been bootstrapped for the pair.
Knowledge-gap referral. Unattributable cross-domain composition cases are routed to knowledge-gap referral; no fallback path to implicit equivalence is admitted. A knowledge-gap referral is emitted as a routing-with-trigger object — a typed cryptographically-signed seven-field record registered in the specification registry — not as an unstructured notification or audit-log entry. The routing-with-trigger object carries:
| Field | Contents |
|---|---|
| 1 — Upstream-context record | The refusal event: source-composition-event-hash; interface-pair-identity; the refusing enforcement mechanism’s identity and refusal diagnostic; a reference to the absent registered interface that would have admitted the composition; the joint-authority-identity required to author the corrective interface (identified from the domain-authority directory) |
| 2 — Attestation chain | The cryptographic signature of the refusing composition module; the verification-side deployment-identity signature |
| 3 — Routing destination | The upstream joint authority’s bootstrap-trigger intake module, identified from the domain-authority directory entry for the interface pair |
| 4 — Retention window | A declared duration after which the object expires and escalation is triggered |
| 5 — Trigger condition | Satisfied when (i) the joint authority records authority-acknowledged consumption of the referral object; (ii) the joint authority emits a bootstrap event for a corrective cross-domain typed interface; or (iii) the retention window expires (escalation trigger) |
| 6 — Downstream-effect specification | Bootstrap of a corrective cross-domain typed interface by the joint authority, registration of the corrective interface in the specification registry, and propagation of a closure record to downstream consumers affected by the original refusal |
| 7 — Cryptographic signature | EUF-CMA-secure signature over Fields 1–6 |
The trigger-occurrence discharge module at the joint authority’s intake refuses discharge when the object’s cryptographic signature fails, any attestation-chain signature fails, the retention window has expired, or the trigger condition is not satisfied. Upon trigger occurrence and discharge, the joint authority bootstraps the corrective cross-domain typed interface; a closure record naming the referral object, the corrective interface, and the closure timestamp is recorded in the audit trail and propagated to the downstream consumers affected by the original refusal event, enabling re-presentation of the originally refused composition.
The routing-with-trigger object transitions through the four-state gap machine (Open → In-resolution → Resolved | Declared-permanent) as an explicit field of its registration record. State-transition authority is the joint authority or a named doctrine authority declared in the governing specification. Re-composition is triggered upon transition to Resolved. Composition through the affected interface pair is prohibited while state is Open or In-resolution. The four-state machine is not a standalone artifact — it is a property of the registered routing-with-trigger object, and the object’s attestation chain and trigger semantics are jointly necessary for the gap machine to be actionable. Cross-domain typed interfaces produced by gap-machine resolution are registered artifacts subject to the delta-attestation lifecycle (§02b §5).
← The non-language-provenance anchor (inbound boundary) · Section index · The actuation anchor (outbound boundary) →