§02c Jupiter — Non-Language Bridge — The non-language-provenance anchor (inbound boundary)

Mars® Spec › §02c Jupiter — Non-Language Bridge › The non-language-provenance anchor (inbound boundary)

← What this layer covers · Section index · Analysis of lifted artifacts →

2. The non-language-provenance anchor (inbound boundary)

The inbound boundary closes the gap between a non-linguistic engineering signal and the typed linguistic predicate that enters the analysis gate. The architectural primitive is the non-language-provenance anchor: a cryptographically-signed typed record carrying seven structural invariants that travels with the predicate and is consumed at every downstream verification gate.

The inventive matter is the set of structural invariants, not a field count. A non-language-provenance anchor is defined by the co-presence of seven structural invariants — each independently required, none waivable. The canonical realization carries exactly these seven invariants as seven declared fields. An anchor that carries all seven invariants is conforming regardless of additional fields. An anchor missing any invariant is structurally deficient.

Invariant	Canonical field	What it requires
Engineering-program identity	Field 1	A record sufficient to identify what program produced the engineering result, in which form, with what integrity identifier, and with what certification of that program against its analysis specification
Input-data identity	Field 2	A record identifying the source and provenance of the non-linguistic signal on which the engineering program operated: source system identity, source authority, sensor or system identifier, timestamp, and measurement provenance
Engineering-result binding	Field 3	A content hash binding the predicate to the specific non-linguistic engineering result from which it was lifted, together with the canonicalization-procedure identity
Analysis-specification identity with bootstrap provenance	Field 4	The registered specification version plus bootstrap provenance: root identity, amendment sequence, originating authority
Interpretation-generation specification identity	Field 5	The registered interp-gen specification version plus joint-authority attestation hash
Causal-closure witness	Field 6	A recomputation record from which an independent inspector re-derives the predicate’s content hash from the engineering-result content hash under the named interp-gen specification
Faithfulness attestation	Field 7	A joint-authority signed record asserting the interp-gen specification does not introduce predicates unsupported by the engineering result

2.1 The four-step bridge sequence

Anti-flattening gate condition. A non-linguistic signal may not be ingested and treated as a typed predicate without executing all four steps of this sequence. Doing so produces a predicate without a non-language-provenance anchor; the downstream verification gate refuses such a predicate at condition 1 of §2.3 (anchor absent). This is not a different architecture — it is an unanchored predicate, which is refused at gate and may not transit any downstream analysis gate. No path exists to bypass the four-step sequence and produce a conforming anchored predicate: the anchor is a structural product of the four-step sequence, not a post-hoc annotation. A deployment that routes non-linguistic signals into the analysis pipeline without executing the four-step sequence for each signal cannot produce conforming anchored predicates and is refused at deployment registration.

Step 1 — Analysis specification. Identify or compile an analysis specification: the typed linguistic artifact governing how a non-linguistic engineering program operates on the signal. The specification declares input domain, output domain, scope of admissible operating conditions, declared falsifiers, and calibration constraints. It is bootstrapped from a natural-language source authority through parsing into typed quantified predicates, SMT discharge for well-formedness, and reviewer-attested faithfulness (declared inter-rater agreement statistic satisfying the five agreement-statistic properties of §01 §8, at or above the pre-declared threshold registered in the specification registry).

Step 2 — Engineering program execution. Execute a non-linguistic engineering program under the analysis specification. Three program forms are recognized (non-limiting):

Synthesized — produced from a synthesis-target specification; may carry a synthesis-correctness proof
Native — pre-built artifact; certified via classical formal verification, empirical characterization, or test-suite-backed validation
Interaction-mediated — interaction protocol against an external program; certification attaches to the protocol exchange, documented via interaction-protocol-conformance record

The program operates on a non-linguistic engineering signal from either a physical domain (sensor readings, laboratory results, biometric measurements, telemetry streams, transaction records, physical-process observables) or a digital-artifact domain (user-interface state, application-state objects, document artifacts, configuration files, log streams, scan results, structured-but-non-linguistic records, including semantically tagged structured and unstructured data in federated, unified, embedded, and non-embedded forms with potentially disparate embedding models).

Execution produces a non-linguistic engineering result: a structured value in the program’s native output domain, not yet linguistic.

Step 3 — Interpretation-generation specification application. Apply an interpretation-generation specification governing how the engineering result maps to a typed linguistic predicate. The specification declares the result-to-predicate mapping, scope conditions, loss-of-information records, and citation linkage. It is co-attested by the engineering authority (owns the analysis specification) and the doctrine authority (owns the downstream linguistic specification); the co-attestation yields a joint-authority attestation hash recomputable from the two distinct recorded authority signatures.

Step 4 — Predicate emission with anchor. Emit the typed linguistic predicate accompanied by the non-language-provenance anchor.

2.2 Canonical field contents

Field 1 — Engineering-program identity. Contains: program_id, version, calibration parameters, form classification (synthesized / native / interaction-mediated), and a form-specific program-integrity identifier. Additionally contains the bridging program’s certification record against its analysis specification — the record establishing that the program is sound for its declared task:

Form	Integrity identifier contents	Certification record
Synthesized	synthesis-target-specification identifier; synthesis-procedure identifier; produced program content hash; synthesis-correctness-proof reference (where available)	Formal-verification discharge record under the analysis specification
Native	source-code hash or model-weight hash	Empirical-analysis report carrying: cross-architecture stability measurement, calibration record, falsifier-result record, and engineering-authority signoff; or formal-verification discharge record where available
Interaction-mediated	interaction-protocol-specification identifier; identity of the interacted-with program	Interaction-protocol-conformance record against the interaction-protocol specification

The certification record is a required structural element of Field 1, not an optional annotation. A Field 1 record lacking the certification record does not satisfy the engineering-program-identity invariant.

Per-execution verifiable execution record. Field 1 additionally references a per-execution verifiable execution record retained in an append-only execution log within the registered engineering-program execution environment. The record is addressable from Field 1 and carries at minimum: execution timestamp; execution environment identity and signature; engineering-program identity; analysis-specification identity; input-data identifier; and engineering-result content hash. The execution record attests that this specific execution actually occurred under the named specification on the named input — not merely that the program is sound in general (which is the certification record’s function). A Field 1 record whose addressable execution record is absent from the execution environment’s log, fails signature verification, or attests execution under an analysis-specification identity that does not match Field 4 does not satisfy the engineering-program-identity invariant. A downstream verification gate may verify the execution record by retrieving it from the execution environment’s log and verifying field consistency with Fields 1, 4, and 3.

Differential (concordant-execution) form. Where two independently-implemented engineering programs operate on the same non-linguistic signal, the anchor is emitted only when both programs produce concordant non-linguistic results. Field 1 in this form references both program identities, both certification records, and both per-execution verifiable execution records. The two programs may take the same form (e.g., two native programs) or different forms (e.g., a synthesized program cross-checked against a native program). Absence of concordance between the two results is a gate refusal condition; the non-concordance record is a typed refusal record identifying both programs, both results, and the divergence.

Hardware-attested execution environments. The execution record may be produced by a hardware root of trust — including but not limited to a Trusted Platform Module, an Intel SGX enclave, an Intel TDX trust domain, an AMD SEV trust domain, or an ARM CCA realm — producing a signed execution record verifiable against a declared hardware-attestation root. This is a recognized variant of the per-execution verifiable execution record; it satisfies the Field 1 execution-record requirement and additionally carries hardware-level attestation that the execution environment itself was not tampered with.

Field 2 — Input-data identity. A structured record identifying the source and provenance of the non-linguistic signal on which the engineering program operated. Required sub-fields: source-system identity; source authority (the organizational or technical authority responsible for the source system); sensor or system identifier; timestamp of the measurement or observation; measurement provenance (the chain from physical-world measurement to the presented signal, including any prior processing steps and their authorities). Field 2 is distinct from Field 3: Field 2 identifies the source and provenance of the raw signal; Field 3 content-addresses the engineering result produced from it.

Field 3 — Engineering-result binding. SHA-256 (or declared equivalent) of the canonicalized non-linguistic engineering result, where the canonicalization procedure is identified by the canonicalization-procedure-identity declared in the analysis specification (Field 4). The canonicalization-procedure-identity is carried in this field alongside the hash so that an independent inspector can reproduce the byte sequence before hashing. Content-addresses the specific result to which the predicate is bound.

Field 4 — Analysis-specification identity. Contains: spec_id, version, and bootstrap provenance record.

Bootstrap provenance is a structured record containing: (i) the identity of the root specification in the derivation lineage, (ii) the ordered sequence of amendment identities traversed from root to current version, each identified by its delta-attestation object content hash (§02b §5), and (iii) the identity of the authority who originated the root specification. Bootstrap provenance allows an independent inspector to reconstruct the full derivation lineage without consulting the delta-attestation audit trail live. The composition gate (§3) verifies that the root specification identity is registered and that the amendment sequence is structurally consistent with the delta-attestation audit trail; inconsistency is treated as refusal condition 5. The versioned re-discharge module (§02b §5) operates at the composition gate as a required admission precondition: before the gate admits a predicate whose accompanying analysis specification identity corresponds to an amended version, the gate queries the specification registry for the delta-attestation object covering the amendment from the prior version recorded in Field 4’s bootstrap provenance to the current version; admission is refused absent a structurally valid delta-attestation object, absent a verified joint-authority attestation hash, absent a recomputable delta-classification, or absent a satisfied re-discharge schedule for this consumer. This re-discharge check is not separable from the composition gate: it is a structural precondition of Field 4 verification, not an optional post-admission audit step.

The Field 4 record also contains: source-authority hash, attestation statistic (declared inter-rater agreement statistic identity, computed value, and its declared threshold), and scope-certificate hash. The analysis specification referenced in Field 4 is a registered artifact subject to the delta-attestation lifecycle (§02b §5). The same lifecycle applies to every artifact class whose identity is carried in any anchor field — including the interp-gen specification (Field 5), the actuation-interpretation specification (Field 4 of the actuation anchor), the cross-domain typed interface (§3), the named-authority standing declaration (§7), and any formal domain model, data source, knowledge base, generation specification, benchmark, or model-behavior certificate whose identity is carried in a provenance field of this layer’s registered artifacts. Each such artifact class, on amendment, emits a delta-attestation object and cascades re-discharge requirements to downstream consumers in the same way as governing-specification amendment; the artifact-class-specific structural-difference record and cascade semantics are governed by §02b §5 and its extensions. A deployment that implements delta-attestation lifecycle enforcement for governing specifications but not for other artifact classes carried in anchor fields is structurally incomplete and is refused at deployment registration.

The cascade consequences of domain model amendment are specific to this layer’s registered artifacts. A scope-breaking domain model amendment immediately invalidates: (i) all conformance certificates issued under governing specifications derived from the prior model version where the amended orders or perspectives are in the critical path of the evaluated conformance predicate; (ii) all scope-of-applicability certificates bound to predicates derived under the prior model version; (iii) all non-language-provenance anchors whose analysis-specification identity (Field 4) references a governing specification derived from the prior model version — because the analysis specification’s scope conditions were expressed against the prior model’s order and perspective structure; and (iv) the boundary-closure attestation (§8.2) bound to the prior model version, with immediate cascade to downstream artifacts depending on that attestation. A scope-restricting domain model amendment fires falsifier annotations on affected anchors, conformance certificates, and scope-of-applicability certificates with a declared re-discharge deadline. The invalidation applies to the current validity of downstream anchors and certificates, not to the historical accuracy of derivation records.

For data source amendment: a scope-breaking data source amendment — defined as one that makes prior evidence gathered from the source non-comparable to evidence that would be gathered under the amended version (triggered by embedder change, schema change eliminating fields from which prior evidence was drawn, or coverage change eliminating aspect bindings) — immediately invalidates all analysis acts whose recomputation witness carries a reference to evidence drawn from the prior data source version; the cascade record identifies each affected analysis act and the specific evidence reference invalidated.

For generation specification amendment: a scope-restricting amendment triggers a consistency determination whose three outcomes (fully consistent, partially consistent, fully inconsistent) determine whether the governing-data-generation certificate is re-issued, narrowed, or invalidated; shim artifacts declared and enrolled in the delta-attestation lifecycle provide a resolution path within consistency determination; a scope-breaking amendment retires all items produced under the prior version without consistency determination.

For benchmark amendment: stale test cases — those whose derivation references amended governing specification clauses or domain model aspects — are identified by per-case content hash comparison; they are excluded from model evaluation until regenerated under the updated version and enrolled in the amended benchmark version; consumer verification results for affected aspects are marked stale pending re-evaluation.

For model-behavior certificate amendment: a model version may receive delta classification only if it carries a declared modification record identifying the modification mechanism — a model version without a declared modification record is treated as a new model, not a delta, preventing undeclared optimization from bypassing the delta-attestation discipline; a scope-restricting or scope-breaking modification delta triggers cascade through downstream governed artifacts whose certificate paths reference the prior model version.

These artifact-class-specific cascade semantics are not independently operable as separate lifecycle mechanisms: they are extensions of the single delta-attestation lifecycle architecture of §02b §5, governed by the same four-valued delta-classification, the same cascade record structure, and the same deployment-registry enforcement. A deployment implementing artifact-class-specific cascade for any subset of these artifact classes without implementing the full unified delta-attestation lifecycle for all artifact classes carried in anchor fields is structurally incomplete and refused at deployment registration.

Field 5 — Interpretation-generation specification identity. Contains: spec_id, version, and joint-authority attestation hash (recomputable from the distinct recorded engineering-authority and doctrine-authority signatures).

Field 6 — Causal-closure witness (interpretation-execution record). A typed record attesting that the interp-gen specification named in Field 5, applied to the engineering result whose content hash is Field 3, yields the accompanying predicate. Contains: interpretation-generation engine identity and signature; execution timestamp; and a recomputation witness in one of two forms:

Deterministic lift: a re-derivation script from which an independent inspector recomputes the predicate’s content hash from the engineering-result content hash under the named interp-gen specification.
Non-deterministic lift: a verifiable lift-execution record containing at minimum: (i) interpretation-generation engine identity; (ii) engine signature over the record and output hash; (iii) execution environment identity; (iv) output hash algorithm. The inspector’s verification procedure is: verify engine signature; confirm output hash matches the accompanying predicate content hash.

Interaction-mediated execution. Where the execution form is interaction-mediated, the verifiable lift-execution record must additionally include: (i) the identity of any human participant(s) whose actions constituted non-deterministic steps, (ii) a timestamped content hash of each human-supplied input at the moment of ingestion, and (iii) an attestation co-signed by a named human authority distinct from the participant(s) confirming that the recorded inputs are complete and unaltered. The causal-closure check (§2.3 condition 4) verifies Field 6 against this co-signature. Absence of the co-signature on any non-deterministic step constitutes a causal-closure failure.

Field 7 — Faithfulness attestation. A structured record asserting that the interpretation-generation specification (Field 5) faithfully represents the engineering result (Field 3) without introducing predicates unsupported by the engineering result’s content. Signed by the same joint authority attesting Field 5. Contains: (i) the content hash of the engineering result, (ii) the set of predicate types the interpretation-generation specification is authorized to emit, and (iii) a boolean flag indicating whether the predicate set is exhaustive or representative.

Fields 1–7 together with the predicate content hash are cryptographically signed under an EUF-CMA-secure scheme. Verification fails if the presented predicate is not the one signed.

2.3 The downstream verification gate — five refusal conditions

A downstream verification gate refuses the predicate when any of the following conditions is met:

Anchor is absent — the causal-closure invariant (Field 6) is not present; no boundary closure exists.
Signature does not verify over Fields 1–7 and the predicate content hash.
Any identity field (1, 4, 5) references an unregistered identity — unknown program, analysis specification, or interp-gen specification.
Causal-closure check fails — the causal-closure witness (Field 6) does not re-derive the predicate’s content hash from the engineering-result content hash (Field 3) under the named interp-gen specification (Field 5). Co-presence of valid-looking parts is insufficient; the witness must reproduce the derivation.
Bootstrap provenance amendment sequence is structurally inconsistent with the delta-attestation audit trail — the ordered sequence of amendment identities in Field 4 cannot be verified against the registered delta-attestation objects.

All conditions that apply to the presented anchor and predicate must be enforced. Selective omission of any applicable condition — including by deployment configuration, operational override, or tier declaration — is a conformance failure regardless of how the remaining conditions are implemented.

When admitted, the anchor travels with the predicate through all downstream discharge passes. The gate’s admit/refuse decision is black-box testable without internal inspection.

NB1 — No cross-store score comparison (inbound enforcement constraint). Non-linguistic signals arriving at the inbound boundary may originate from federated data stores with distinct embedding models. Merging retrieval results by cross-store score arithmetic produces spurious orderings because scores are not comparable across stores with distinct embedders. This constraint is enforced at the inbound boundary as a structural condition on what inputs the bridge sequence may accept. The same constraint applies to governed traversal (§02a §4b): a traversal act that navigates positions across federated stores with distinct embedders is subject to NB1 on the same terms as retrieval score arithmetic — cross-store traversal position comparison is not admitted without a registered cross-store calibration mapping (Path B below) covering the embedder pair, and the traversal witness (§02a §4b.4) must record which store each traversal position was drawn from. A traversal that merges positions from distinct-embedder stores without a registered mapping is refused at the same gate as a retrieval act performing unregistered cross-store score arithmetic.

NB1 admits two compliance paths:

Path A — Typed-module-interface path. A federated-retrieval module executes per-store retrieval calls under each store’s native embedder, merges results by interleave of per-store ranks (round-robin or reciprocal-rank-fusion on disjoint sets), and preserves per-store provenance on each merged item (source_store_id, source_rank, source_score_in_native_embedder).

Path B — Cross-store calibration mapping. A registered calibration mapping is a typed, cryptographically-signed structurally-defined record carrying nine declared fields corresponding to nine structural requirements:

Field	Contents
1 — First-store identity	Store URI or content-addressed identifier; embedder name, version, model-weight hash, embedding dimensionality, and declared distance-metric specification
2 — Second-store identity	Analogous record for the second store and its embedder
3 — First-store calibration function	A typed, content-addressed declaration of a function f₁ mapping native scores of the first store into a declared canonical comparability space (e.g., unit-interval probability space, calibrated nonconformity space, joint relevance-probability space) registered in the specification registry
4 — Second-store calibration function	Analogous declaration of f₂ mapping native scores of the second store into the same canonical comparability space
5 — Empirical-evidence record	A typed record comprising one or more of: a paired-evaluation dataset (content hash, per-store calibration performance, agreement on canonical space); a cross-store inter-rater agreement statistic (Cohen’s κ, Krippendorff’s α, or equivalent) across reviewers evaluating matched queries in both stores; a divergence-rate measurement of calibrated comparison decisions against downstream certifications under the scope certificate; and a falsifier-rate measurement under declared adversarial inputs
6 — Joint-authority attestation hash	A hash recomputable from distinct recorded attestation signatures of the owner of the first store and the owner of the second store, each a distinct organizational entity, signing over Fields 1–5; a signature from only one store owner fails recomputation
7 — Scope-of-applicability certificate	A typed scope-of-applicability certificate declaring the input range over which the calibration is certified (admissible query types, document types, embedder version ranges, operational contexts)
8 — Falsifier annotations	Declared conditions under which the calibration is automatically invalidated: (a) embedder replacement (embedder identity change); (b) embedder re-training (model-weight hash change without embedder identity change); (c) embedded-data-store schema amendment; (d) joint-authority withdrawal by either store owner; (e) divergence-rate exceedance against the calibration’s declared threshold; (f) empirical-evidence record amendment without re-attestation; (g) scope-of-applicability certificate expiration or amendment
9 — Cryptographic signature	EUF-CMA-secure signature over Fields 1–8

When a valid calibration mapping is registered between two stores, score comparison across those stores is admitted within the scope-of-applicability certificate’s declared input range, with native scores mapped through f₁ and f₂ into the canonical comparability space before comparison; comparison on raw native scores is not admitted even under a registered mapping. The calibration mapping is subject to the delta-attestation lifecycle (§02b §5). The cross-store score-comparison discharge module refuses admission when: (i) no registered mapping exists for the (first-store, second-store) pair; (ii) the mapping’s cryptographic signature fails; (iii) the joint-authority attestation hash fails recomputation from the two distinct authority signatures; (iv) a falsifier annotation has fired; (v) the comparison’s typed scope exits the scope-of-applicability certificate; or (vi) the embedder versions in the request do not match those in Fields 1–2. Upon falsifier-condition occurrence, the verification system cascades invalidation through the audit trail to admitted comparisons performed under the mapping within a declared retention window.

A deployment relying on unregistered score arithmetic satisfies neither path and is refused at registration. A deployment registering a configuration that permits cross-store score comparison outside a registered calibration mapping is refused at registration.

← What this layer covers · Section index · Analysis of lifted artifacts →