§02c Jupiter — Non-Language Bridge — The actuation anchor (outbound boundary)
Mars® Spec › §02c Jupiter — Non-Language Bridge › The actuation anchor (outbound boundary)
← Analysis of lifted artifacts · Section index · Bidirectional boundary closure →
4. The actuation anchor (outbound boundary)
The outbound boundary closes the reverse-direction gap: from a verified linguistic predicate to the non-linguistic effect that predicate authorizes. The architectural primitive is the actuation anchor: a cryptographically-signed typed record carrying seven structural invariants that travels with the emitted effect and is consumed at the downstream actuation gate.
The inventive matter is the set of structural invariants, not a field count. An actuation 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 |
|---|---|---|
| Originating-verification-record identity | Field 1 | The conformance certificate (§02b §2) and verified predicate record from which this actuation originates |
| Consumer-bridging-program identity | Field 2 | The non-linguistic engineering program that executes the actuation, with form classification and integrity identifier |
| Consumer-bridging-program analysis-specification identity | Field 3 | The registered analysis specification for the consumer bridging program, with bootstrap provenance |
| Causal-binding witness | Field 4 | A recomputation record from which an independent inspector re-derives the emitted effect’s content hash from the originating predicate’s content hash under the named actuation-interpretation specification |
| Actuation-scope intersection | Field 5 | The typed intersection of the predicate’s certified scope and the consumer bridging program’s certified scope; the effect is admissible only within both |
| Procedural-confidence-at-admission | Field 6 | A structurally-derived confidence value; present for actuation classes declaring a confidence floor; derivation excludes model-internal signals |
| Named-human-authority co-signature | Field 7 | A co-signature by a named authority with declared standing for the actuation class; present for actuation classes requiring human co-authorization |
4.1 Registration-time versus invocation-time steps
The actuation sequence has two classes of step: registration-time steps performed once when a deployment is configured, and invocation-time steps performed per governed invocation. This distinction is material: an implementation specification that presents all steps as invocation-time operations misrepresents the architecture and creates unnecessary latency expectations.
Registration-time (performed once per deployment configuration):
- Consumer bridging program certification: the program is certified against its own analysis specification and the resulting conformance certificate is registered.
- Actuation-interpretation specification registration: the specification is co-attested by doctrine and engineering authorities and registered in the specification registry.
- Actuation class declaration: each actuation class declares its confidence floor (if any) and co-signature requirement (if any) in the specification registry.
- Named-authority standing declarations: registered once in the authority registry, subject to the delta-attestation lifecycle (§02b §5) on amendment.
Invocation-time (performed per governed invocation):
- Step 1 — Verified predicate retrieval. A typed linguistic predicate has passed the composition gate (§3) and arrives with a CertifiedBundle: gate identity, registered-specification identity, predicate content hash, certified scope, rule trace, verification-pass discharge profile.
- Step 2 — Actuation anchor construction. The anchor is constructed from the registration-time artifacts (Fields 2–3 from the registered consumer bridging program and analysis specification; Field 4’s actuation-interpretation specification identity from the registration) plus the invocation-specific bindings (Field 1 from the arriving CertifiedBundle; Field 5 from the scope intersection computed at this invocation; Field 6 derived from the PassRecord set in the CertifiedBundle; Field 7 obtained from the named authority if required).
- Step 3 — Actuation emission. Emit the non-linguistic effect accompanied by the actuation anchor.
- Step 4 — Downstream actuation gate. Admit or refuse the effect under the nine check conditions (§4.3).
4.2 Canonical field contents
Field 1 — Originating-verification-record identity. Contains: verification-record identifier; content hash of the verified predicate; gate identity; predicate’s certified scope; and, where the originating predicate carries a non-language-provenance anchor (§2), a reference to that anchor. This field is the consumption point of the conformance certificate (nine structural invariants, §02b §2): the conformance certificate is the verification record named here. The recomputation-witness invariant of the conformance certificate is the soundness anchor (§02a §3a) for the governed verdict this actuation authorizes.
Any governance form of the conformance certificate that satisfies the nine structural invariants of §02b §2 satisfies Field 1 — including federated joint-authority, differential, time-windowed, streaming, sidecar, and zero-knowledge forms defined in the governed taxonomy of §02b; the governance form does not alter the Field 1 requirement or the actuation gate’s structural conditions. These governance forms extend the base certificate’s structural invariant set with governance-form-specific structural requirements — each is a structural extension of the base certificate, not an independent artifact class:
- Federated joint-authority form: carries a federation hash recomputable by any independent inspector from the individual authority attestation records using a declared hash function and a declared canonicalization order, plus a declared federation policy registered as a parameter of the governing specification; the downstream gate refuses when the federation hash fails recomputation or any required attestation in the federation policy is withdrawn.
- Differential form: requires two independently-issued conformance certificates from verifiers confirmed distinct by the specification registry; the downstream gate admits only when both certificates present, both verify, and a concordance record declares concordance (same canonical verdict value); a non-conforming certificate and any other verdict are not concordant — the non-conforming result governs; the independence requirement is structural (specification registry confirms distinct registered entities), not merely declared.
- Time-windowed form: carries a rotation-unit declaration whose type is a registered parameter of the governing specification (not assertable per-certificate); the downstream gate refuses a certificate whose expiration has passed or whose rotation-sequence identifier does not match the current rotation.
- Streaming form: a single certificate whose coverage grows incrementally; each incremental record carries a running content hash computed by incorporating the sub-emission content hash into the prior running content hash via a declared incremental hash construction, and a running witness chain link; the gate refuses a streaming certificate in intermediate state for operations requiring a complete certified output.
- Sidecar form: certificate transmitted out-of-band as a sidecar artifact bound to the certified target artifact by the artifact’s content hash; admission requires retrieval of the sidecar from the declared delivery channel and verification of the binding hash against the artifact’s content hash; a sidecar whose binding hash does not match the presented artifact’s content hash is refused as if absent.
- Zero-knowledge form: attests satisfaction of the base certificate’s structural invariants without revealing field values; the full recomputation witness (Field 7 of the base certificate) is held by the issuing verifier and produced to an authorized inspector on demand; the ZKP form governs the transmission path, not the underlying witness obligation — the witness obligation is not reduced by the ZKP form.
All six governance forms are governed by the same structural invariant set as the base certificate (§02b §2); no governance form reduces or waives any structural invariant. A deployment implementing any governance form without satisfying all nine structural invariants is non-conforming and refused at deployment registration.
A Class A pipeline-composed certificate — whose target-identity field declares a pipeline-topology record comprising the stage graph, the composition rule, and a topology content hash, and whose recomputation-witness field carries a stage-level pipeline witness chain linking per-stage witness links through an aggregation witness link to a composed-output verdict link — equally satisfies Field 1 when the pipeline’s composed output is the certified artifact; certifying the final stage’s output alone does not constitute a valid originating verification record for a pipeline-composed actuation. The pipeline-topology record is the pipeline-composed target’s version identity; a change to any stage identity, stage version, stage governing-specification binding, or the composition rule produces a new topology content hash and a new pipeline-composed target identity subject to the delta-attestation lifecycle. The pipeline witness chain’s completeness (one stage-level link per stage node, aggregation link, composed-output verdict link) is verified at the actuation gate; a missing link is a structural deficiency causing refusal with a typed diagnostic. The governance form and target class are declared in the conformance certificate’s certification-path record and are consulted by the actuation gate when verifying Field 1 integrity.
Field 2 — Consumer-bridging-program identity. Contains: program_id, version, form classification (synthesized / native / interaction-mediated), and form-specific program-integrity identifier (same taxonomy as inbound anchor Field 1 in §2.2). Additionally references a per-execution verifiable actuation-execution record retained in an append-only execution log within the registered consumer-bridging-program execution environment. The record is addressable from Field 2 and carries at minimum: execution timestamp; execution environment identity and signature; consumer-bridging-program identity; actuation-interpretation-specification identity; originating-predicate content hash; and emitted effect content hash. The actuation-execution record attests that this specific execution actually occurred under the named actuation-interpretation specification on the named predicate and produced the named effect — not merely that the program is certified in general. A Field 2 record whose addressable actuation-execution record is absent from the execution environment’s log, fails signature verification, or attests execution under an actuation-interpretation-specification identity that does not match Field 4 does not satisfy the consumer-bridging-program-identity invariant. For an interaction-mediated consumer bridging program, where the effect is produced by the external interacted-with program, the actuation-execution record requirement is satisfied by an interaction-protocol-conformance record attesting that the protocol was executed and produced the received effect whose canonical content yields the effect content hash.
Field 3 — Consumer-bridging-program analysis-specification identity. Contains: spec_id and bootstrap provenance record (source-authority hash, attestation statistic under declared threshold, scope certificate hash).
Field 4 — Causal-binding witness (actuation-interpretation-specification identity and mapping-execution witness). Contains: spec_id; joint-authority attestation hash (recomputable from distinct doctrine-authority and engineering-authority signatures); and the mapping-execution witness.
The mapping-execution witness is a recomputation reference from which an independent inspector re-derives the emitted effect’s content hash from the originating predicate’s content hash under the named actuation-interpretation specification. This is causal binding — the effect must be the faithful image of the predicate under the named mapping.
Non-trivial transformation requirement. The witness must include: (i) the sequence of transformation steps defined by the actuation-interpretation specification that were applied to the originating predicate to produce the emitted effect, (ii) a structural difference record between predicate content and effect content, and (iii) the originating predicate content hash (matching Field 1’s content hash) explicitly embedded in the witness record. A witness recording a null or identity transformation is valid only if the actuation-interpretation specification explicitly classifies the actuation class as pass-through. In all other cases, a null or identity transformation witness is a gate-check failure under §4.3 condition 6.
Field 5 — Actuation-scope intersection. The typed intersection of the originating predicate’s certified scope (from its scope-of-applicability certificate, which is mandatory for any predicate routed to actuation) and the consumer bridging program’s certified scope. The effect is admissible only within both scopes. The intersection is computed at invocation time from the two registered scope certificates. A predicate lacking a scope-of-applicability certificate is not admissible for actuation; absence of the certificate is itself a gate condition 5 failure.
Field 6 — Procedural-confidence-at-admission (present for actuation classes declaring a confidence floor). A typed value derived structurally from the originating verification-pass discharge profile by the declared derivation function, declared in a registered procedural-confidence specification (§6, R4). The derivation function’s typed input domain consists of the PassRecord set and excludes by construction any signal derived from the internal state of an underlying machine-learning model. Field 6 is accompanied by a derivation-binding witness from which the actuation gate re-derives the value by applying the named derivation function to the presented, cryptographically-signed PassRecord set from the accompanying CertifiedBundle; a value that does not re-derive within the declared tolerance is refused regardless of its tag. An inspector verifies Field 6 by the same recomputation without access to model-internal state. Omitted for actuation classes declaring no confidence floor.
Field 7 — Named-human-authority co-signature (for actuation classes requiring one). A typed record containing: the named authority’s identifier, declared standing for the actuation class (verified against the authority registry, §6), and a signature by that authority computed over the concatenation of (originating predicate content hash ‖ proposed effect content hash ‖ actuation class). The human signs before the deployment anchor signature, so the deployment signature covers the co-signature. An effect lacking a valid human co-signature for a co-signature-required class is refused.
Fields 1–7 concatenated with the emitted effect’s content hash are cryptographically signed under the same EUF-CMA-secure scheme family as the inbound anchor (§2.2). The signature is an eighth field.
4.3 The downstream actuation gate — nine refusal conditions
The nine refusal conditions at the downstream actuation gate enforce the seven structural invariants, the integrity of the deployment cryptographic signature, and the per-execution actuation-execution record attestation. Each condition enforces one or more invariants:
| # | Condition | Invariant enforced |
|---|---|---|
| 1 | Anchor is absent | All invariants — no anchor means no governed actuation |
| 2 | Signature does not verify over Fields 1–7 and the effect content hash | Tamper-evidence of the anchor as a whole |
| 3 | Any declared identity field references an unregistered identity | Fields 1, 2, 3, 4 — originating-verification-record identity, consumer-bridging-program identity, analysis-specification identity, actuation-interpretation-specification identity |
| 4 | Joint-authority attestation hash on the actuation-interpretation specification (Field 4) fails recomputation from the two recorded distinct authority signatures | Causal-binding witness integrity |
| 5 | Actuation-scope intersection (Field 5) does not lie within both the predicate’s certified scope and the consumer bridging program’s certified scope | Actuation-scope intersection |
| 6 | Causal-binding witness (Field 4) does not re-derive the emitted effect’s content hash from the originating predicate’s content hash under the named actuation-interpretation specification | Causal-binding witness |
| 7 | Procedural-confidence-at-admission (Field 6) falls below the declared per-actuation-class floor; gate also refuses any deployment configuration naming model-internal confidence as the source | Procedural-confidence-at-admission |
| 8 | Named-human-authority co-signature (Field 7) is absent or invalid for an actuation class requiring one | Named-human-authority co-signature |
| 9 | Field 2 actuation-execution record is absent from the execution environment’s append-only log, fails signature verification, or attests execution under an actuation-interpretation-specification identity that does not match Field 4 | Consumer-bridging-program-identity invariant — per-execution attestation |
All conditions that apply to the presented anchor and actuation class 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. Conditions 6, 7, 8, and 9 are conditional on actuation class declaration; where the actuation class declares the corresponding requirement, the condition is applicable and may not be omitted.
Monotonic non-refusal prohibition. No deployment-declared configuration, operational override, or upstream declaration of monotonic non-refusal may permit the actuation gate to admit a non-linguistic effect failing any of the nine conditions above. A deployment configuration declaring monotonic non-refusal for any condition is refused at deployment registration with a typed structural diagnostic identifying the rejected declaration. This prohibition is not waivable by the operator. Its purpose is to close the design-around path wherein a deployment achieves de facto admission of unanchored effects by declaring non-refusal in configuration rather than by modifying the gate’s structural logic.
Generalized modality. The actuation anchor and gate apply to emitted effects of arbitrary modality: a non-linguistic effect into a non-linguistic substrate is the primary paired case, but a linguistic effect (a generated document, decision record, or instruction to another system) is equally governed by the anchor-and-gate mechanism under a declared actuation-interpretation specification. The effect modality does not alter the structural requirements on the anchor’s fields or the gate’s refusal conditions; it determines the content domain of the emitted effect and the consumer bridging program’s output type.
Persistent-state writes are output classes under this generalized modality: a certified output routed to any persistent store whose content can influence a subsequent governed invocation — agent memory, knowledge-base write-back, prompt-template or configuration mutation, or any other cross-invocation state — is an emitted effect subject to the actuation anchor and gate. An output-class routing declaration (§6.1) that routes certified outputs to persistent state without declaring that class is incomplete, and the resulting write is an ungoverned effect. This forecloses the cross-session injection path: content cannot enter a store that influences later invocations except as a gated, anchored, witness-bound effect.
4.4 The actuation-accumulation gate
The nine refusal conditions of §4.3 govern each proposed effect individually. The actuation-accumulation gate governs the composition of effects over time: it is the outbound symmetric counterpart of the multi-turn accumulation discipline at the pre-invocation boundary (§02e §4), and it exists because a sequence of individually-admissible effects can jointly constitute a macro-effect that no single effect’s evaluation reveals.
The accumulation record. For each actuation class declared accumulation-governed, the deployment maintains an order-structured accumulation record per declared accumulation scope. Each admitted effect appends an order-typed entry carrying: the actuation class, the order tags of the originating predicate, the effect content hash, the named target, the admission timestamp, and a reference to the effect’s actuation anchor. The record is hash-chained and witness-bound; its entries are append-only.
Joint evaluation. Before an effect in an accumulation-governed class is admitted, it is evaluated jointly with the accumulated record against the governing specification’s declared accumulation predicates — aspect-level bounds over sequences and aggregates of effects, including but not limited to: rate bounds, aggregate-magnitude bounds, coverage bounds (the set of targets or aspects an effect sequence may span), and combination constraints (effect kinds individually admissible but jointly foreclosed). A sequence of individually-admissible effects that is jointly out-of-bounds under a declared accumulation predicate is refused at the accumulating effect — the effect whose admission would cross the bound — with the typed refusal accumulation-bound-exceeded, identifying the violated accumulation predicate and the contributing accumulation-record entries. The joint evaluation runs in series with the §4.3 per-effect conditions: an effect must pass both.
Declared accumulation scope. Accumulation scopes — per subject, per named target, per session, per declared temporal horizon, or any declared combination — and their windows are registered parameters of the deployment manifest runtime configuration record. An actuation class for which the governing specification declares accumulation predicates must name its accumulation scope(s); operating such a class without the accumulation gate is non-conforming. Where the governing specification declares no accumulation predicates for a class, the accumulation gate is vacuously satisfied for that class and the accumulation record is not required — the obligation follows the declaration, fail-closed where declared.
Decomposition foreclosure. Decomposing a macro-effect into individually-admissible micro-effects in order to evade a bound is the foreclosed variant: the joint evaluation operates over the accumulation regardless of the per-effect admissibility of each contribution, so the decomposition changes which effect is refused, not whether refusal occurs. An implementation that gates effects only individually — with no order-structured joint evaluation over an accumulation record — does not practice accumulation governance, and post-hoc longitudinal analysis (§02f §6) is not a substitute for the gate: §02f consumes accumulation records as forensic inputs; it does not admit or refuse effects.
Relationship to temporal-chain forensics. The accumulation record is a first-class registered artifact consumed by the temporal-chain forensic layer (§02f §6) as per-interval input. The gate is preventive; the forensic layer is analytical; both operate over the same order-structured record, and neither substitutes for the other.
4.5 Reversibility grading and the persistent-state write journal
The actuation-class declaration (§4.1) declares, per class, a confidence floor and a co-signature requirement. This section supplies the declared basis on which those conditions are graded — the irreversibility of the class’s effects — and the journal mechanism that makes the intermediate grade operative.
Reversibility annotation. Every actuation class declared in the specification registry carries a reversibility annotation drawn from the enumeration {reversible, compensable, irreversible}, declared alongside the class’s confidence floor and co-signature requirement in the actuation-class declaration (§4.1). A compensable class co-declares a compensating-action reference resolvable to a registered compensating procedure — a registered artifact subject to the delta-attestation lifecycle (§02b §5). A compensable class whose compensating-action reference is absent or unresolvable is refused at deployment registration with a typed diagnostic. Amendment of a class’s reversibility annotation is a delta-attestation event: reclassification to a less stringent tier is scope-breaking; reclassification to a more stringent tier is scope-restricting.
Tiered admission floors. The reversibility annotation establishes minimum floors on the class’s declared admission conditions: a compensable class declares a procedural-confidence floor elevated above the deployment’s declared reversible-tier baseline; an irreversible class declares both an elevated procedural-confidence floor and a named-human-authority co-signature requirement (§4.2 Field 7, §7). The tier establishes a floor, not a ceiling — a class may declare conditions stricter than its tier requires; a class declaring conditions below its tier’s floor is refused at deployment registration with a typed diagnostic identifying the tier and the deficient condition. The gate’s refusal conditions are unchanged (§4.3 conditions 7 and 8); the tier governs what the class declaration must require for those conditions to be applicable.
Persistent-state write journal. For an effect in a persistent-state-write class (§4.3 — a write to a durable substrate whose content outlives the invocation, including any store whose content can influence a subsequent governed invocation), admission is additionally conditioned on the prior appending, to an append-only signed write journal, of an entry carrying: the effect content hash; a cryptographic commitment to the prior state of the written substrate (a content hash over the substrate region the write will alter, or a declared equivalent commitment); and, for a compensable class, the compensating-action reference. The journal entry precedes the write: the prior-state commitment and the compensating action are recorded before the effect exists, which is what makes a compensable write compensable in fact rather than by declaration. The write journal is a registered append-only artifact under the same content-addressability, append-only, and tamper-evidence requirements as the specification registry (§02b §3). A persistent-state write admitted without a corresponding journal entry is an ungoverned effect; a deployment configuration permitting such admission is refused at deployment registration.
Composition with the accumulation gate. Persistent-state-write classes compose with the actuation-accumulation gate (§4.4) on the same terms as any accumulation-governed class. A per-substrate accumulation predicate over the composed state-delta of admitted writes is a declared accumulation predicate in the sense of §4.4: a sequence of individually-admissible writes composing to a prohibited aggregate state change is refused at the accumulating write.
← Analysis of lifted artifacts · Section index · Bidirectional boundary closure →