§02c Jupiter — Non-Language Bridge — Outbound enforcement constraints (NB3, NB4, NB5)
Mars® Spec › §02c Jupiter — Non-Language Bridge › Outbound enforcement constraints (NB3, NB4, NB5)
← Bidirectional boundary closure · Section index · Named-authority standing →
6. Outbound enforcement constraints (NB3, NB4, NB5)
Three structural refusals are native to the outbound boundary. They are co-specified with the actuation anchor because each directly enforces one or more of the anchor’s structural invariants. They are recorded in the deployment registry alongside NB1 and NB2 (§2.3, §3.6).
NB3 — No origination of decisions reserved for named human authority.
The named-human-authority co-signature invariant (Field 7) exists because certain consequence-bearing actuation classes require a named human authority’s recorded action before the actuation is admitted. R3 enforces this at the deployment level: no deployment configuration may route a certified output to a consequence-bearing operation of a declared co-signature-required class without the named human authority’s recorded action.
Enforcement artifact: an output-class router that checks each certified output’s actuation class against the declared co-signature-required classes; an attestation gate requiring a recorded authority action of accept before admission (dispositions {modify, reject, refer, revoke} are pre-anchor outcomes that abort the actuation before Field 7 is required and do not produce a co-signature over the proposed effect); downstream-consumer guards checking the recorded action. A deployment-registration check refuses any configuration lacking authority-action checks for declared co-signature-required classes.
NB4 — No model-internal confidence as gating signal.
The procedural-confidence-at-admission invariant (Field 6) is derived structurally from the PassRecord set — it explicitly excludes model-internal signals. R4 enforces this at the deployment level: no configuration may name a model-internal confidence class as the source of a gating signal for any downstream action.
Model-internal confidence classes (all refused), including but not limited to: softmax output, log-likelihood, self-consistency score, verbalized rating, calibrator score, hidden-state value, semantic-entropy measure, or any signal whose source is a language model’s internal computational state, whether produced in a single forward pass or by aggregation across multiple forward passes. The refusal is enforced at the typed interface: signal-class tagging at the interface boundary means no re-tagging or re-encoding admits a refused signal class as an input to the procedural-confidence computation.
Procedural-confidence derivation function declaration. The derivation function is declared per deployment in a registered procedural-confidence specification — a typed artifact cryptographically bound to the registered specification under which candidate predicates are discharged. The specification records: (i) the derivation_function_id and version; (ii) the consumed_record_fields (the subset of PassRecord fields the derivation uses: passed indication, falsifier-presence indication, tier provenance, abstraction-precision-loss record, refinement chain, scope-certificate-match indication); (iii) the derivation rule mapping those fields to a typed numerical or categorical signal; (iv) the signal type (a real in [0,1], a categorical from a declared enumeration, or a tuple with a declared aggregation rule); (v) the per-actuation-class interpretation thresholds; and (vi) a cryptographic signature binding the declaration to the registered specification. The declaration is not operative in isolation: a registered derivation function declaration without the derivation-binding witness enforcement at the runtime gate (below) does not constitute a conforming R4 implementation. A deployment that registers a derivation function declaration but admits gating signals without verifying the derivation-binding witness is a non-conforming implementation regardless of the declaration’s content — the declaration and the runtime witness check are jointly necessary and neither is sufficient alone.
Derivation-binding witness. A procedural-confidence signal is admitted as a gating input at the actuation gate only when it is accompanied by a derivation-binding witness — a recomputation witness from which the gate re-derives the signal’s value by applying the named procedural-confidence derivation function to a presented, cryptographically-signed PassRecord set and comparing the result within a declared tolerance. A signal is refused as a gating input when its value does not re-derive within tolerance from the presented PassRecord set under the named derivation function, irrespective of any tag the signal carries. A value derived from model-internal state and presented under a procedural-confidence tag is refused by this mechanism because it cannot re-derive from a PassRecord set under the named derivation function. Gating rests on re-derivation, not on a label.
Procedural-confidence audit record. The verification engine emits, alongside each certified predicate, a procedural-confidence audit record containing: the procedural-confidence signal value marked [GATING]; the per-pass discharge record set on which the signal was derived; the declared derivation-function identifier; and, optionally, the model-internal confidence signal value marked [AUDIT ONLY, NON-GATING]. The audit record is cryptographically signed over all fields. An independent inspector verifies the audit record by recomputing the procedural-confidence signal from the per-pass discharge record set against the declared derivation function and comparing against the recorded value within the declared tolerance. The recomputation requires no access to the weights or internal state of any underlying machine-learning model.
Drift indicator. The verification engine continuously emits a drift indicator computed as the magnitude of divergence between the procedural-confidence signal and the contemporaneously emitted model-internal-confidence signal. The drift indicator is surfaced for human-authority review when the magnitude exceeds a declared threshold. A high-procedural / low-model-internal divergence indicates the model was uncertain but the predicate is verifiable; a low-procedural / high-model-internal divergence is the confidently-wrong failure mode that R4’s exclusion is designed to prevent. The drift indicator is a continuous empirical falsifiability signal over the deployment’s gating behavior, independently auditable from the audit trail. The drift indicator is structurally dependent on NB4: its existence as a meaningful signal requires that the model-internal-confidence signal is emitted to audit-only emission (not admitted as a gating input) and that the procedural-confidence signal is derived from the PassRecord set under the derivation-binding witness. A deployment without NB4 enforcement has no structurally-derived procedural-confidence signal against which to compute divergence; the drift indicator cannot be independently implemented or independently claimed as a separable output of any deployment that does not enforce NB4 in full.
Enforcement artifact: a configuration-rejection module that refuses at load time any configuration naming a model-internal-confidence class, recording the rejection with a structural diagnostic identifying the rejected signal class; a runtime gating-decision module whose typed input interface enforces the derivation-binding witness mechanism above; and a procedural-confidence audit record emitted per certified predicate.
NB5 — No silent scope extrapolation.
The actuation-scope-intersection invariant (Field 5) bounds the admissible effect to the intersection of the predicate’s certified scope and the consumer bridging program’s certified scope. R5 enforces this at every re-use of a certified predicate: a predicate may not be silently re-used at a downstream consumer bridging program whose input range falls outside the predicate’s scope-of-applicability certificate.
Enforcement artifact: a scope-match discharge module verifying the consumer bridging program’s input range against the scope-of-applicability certificate at every re-entrance event; re-analysis triggered (not silent admission) on scope exit; a continuously-computed divergence-rate metric independently recomputable from the audit trail without internal inspection. The divergence-rate metric’s operative definition: two consumers of the same certified predicate under the same declared scope producing divergent downstream certifications is evidence that the predicate was either mis-certified upstream or used outside its declared scope. The rate at which this occurs is measurable and reportable from the audit trail and constitutes an empirical falsifiability test of the scope-match discipline.
Concurrent non-weakening property. NB3, NB4, and NB5 are mutually reinforcing:
- NB3 ensures that human authority is not displaced by automated actuation.
- NB4 ensures that the procedural-confidence signal gating actuation is structurally derived, not a black-box model-internal value.
- NB5 ensures that the scope within which the predicate was certified is the scope within which it governs actuation — no extrapolation beyond certified evidence.
NB4 is foundational to the other two: the procedural-confidence value that NB3’s attestation gate and NB5’s scope-match module rely upon is only meaningful if NB4’s exclusion of model-internal signals is enforced. Without NB4, the procedural-confidence invariant (Field 6) degrades to an assertion, and NB3 and NB5 lose their structural grounding.
Concurrent non-weakening as an architecturally-checkable property. The five enforcement constraints (NB1–NB5) operate concurrently. Activation of any one constraint’s emission does not disable, weaken, or pre-empt the refusal-emission capability of any other constraint. This concurrent non-weakening property is recorded in the deployment registry (§6.1) as an architecturally-checkable condition. A deployment configuration that declares, implies, or produces monotonic non-refusal for any mechanism, or that routes a refused candidate to a lower-priority mechanism for re-evaluation, violates this property and is refused at deployment registration. The concurrent non-weakening property is the structural basis on which the five enforcement constraints characterize the architecture as a unit rather than as five independent policies.
Priority order across all five enforcement constraints. The full deployment registry records NB1 through NB5 in priority order NB1 > NB2 > NB3 > NB4 > NB5. The priority order governs which refusal record is emitted when a candidate operation triggers more than one constraint simultaneously — the highest-priority triggered constraint governs the emitted record. It does not disable lower-priority mechanisms: each mechanism independently evaluates all candidate operations it governs; the priority order determines the emitted record in cases of multi-mechanism triggering, not the evaluation reach of any mechanism. Any audit record showing a lower-priority constraint admitting output that a higher-priority constraint would have refused is a conformance failure of the deployment registry. The priority order is invariant across all operating conditions, including DDIL states, load conditions, deployment tiers, and actuation class. No deployment configuration may produce a result inconsistent with this priority order under any operating condition. A result that a higher-priority constraint would have refused but a lower-priority constraint cleared is a conformance failure regardless of the operating condition under which it occurred.
6.1 Deployment registry typed schema
The deployment registry is a typed schema held in non-transitory memory. It is the structural primitive that makes the five-refusal architectural commitment concrete, checkable, and externally verifiable. Its architecture-identifier is a content hash computed over the concatenation of the five per-mechanism rows in declared NB1–NB5 order; modifying any field in any row produces a distinct architecture-identifier.
Per-mechanism row. The registry holds one row for each of the five enforcement mechanisms, recording:
| Field | Content |
|---|---|
| mechanism-name | The declared name of the enforcement constraint (NB1 through NB5 as named in this specification) |
| mechanism-kind | A value drawn from the typed enumeration {typed-module-interface-refusal, registry-membership-check-refusal, recorded-action-condition-refusal, configuration-rejection-module-refusal, scope-match-discharge-refusal} — one value per mechanism, fixed: NB1 = typed-module-interface-refusal; NB2 = registry-membership-check-refusal; NB3 = recorded-action-condition-refusal; NB4 = configuration-rejection-module-refusal; NB5 = scope-match-discharge-refusal |
| enforcement-artifact-signature | The refusal-emission response for this mechanism (§6.2), recorded as the mechanism’s externally distinguishable refusal record format — distinguishable from every other mechanism’s refusal-emission and from an admit-emission by black-box differential-behavior testing without inspection of internal implementation |
| bridge-form-applicability | A declaration of applicability to one or more of the three engineering-program forms: synthesized, native, and interaction-mediated; the declaration is bridge-form-specific where the mechanism’s refusal predicates differ across forms |
Registry-level properties. The registry additionally records:
- Concurrent non-weakening property — the architecturally-checkable declaration that the five mechanisms operate concurrently without weakening one another (§6)
- Versioning rule — modifying any per-mechanism row field produces a new architecture-identifier (a distinct content hash); downstream consumers verifying against a prior architecture-identifier do not transparently consume outputs from the modified architecture
The deployment registry is a registered typed artifact subject to the delta-attestation lifecycle (§02b §5). A scope-breaking amendment to any mechanism row produces immediate cascade; a scope-restricting amendment produces required cascade with re-discharge deadline. Downstream consumers carry the architecture-identifier of the registry version under which they were certified; a change of architecture-identifier requires re-certification of dependent artifacts. The versioned re-discharge module (§02b §5) is an additional enforcement mechanism of this deployment registry: the module is recorded as a per-mechanism row with mechanism-kind selected from the typed enumeration of enforcement-mechanism kinds and is subject to the same concurrent non-weakening property as R1–R5. The versioned re-discharge module is not independently operable outside this registry: its per-mechanism row carries the registered architecture-identifier of the deployment it is bound to, so a re-discharge module operating without a registered row in the deployment registry of the enclosing architecture is a non-conforming implementation.
6.2 Enforcement-artifact-signature and per-mechanism distinguishability
Each enforcement mechanism, on refusing a candidate operation, emits a structurally-typed refusal record carrying:
- A mechanism-name field identifying the refusing mechanism by its registered name
- A mechanism-kind field whose value is the mechanism’s kind from the typed enumeration (§6.1)
- A typed cause identifier drawn from a declared enumeration specific to the mechanism-kind
- A candidate-operation identifier identifying the refused candidate
- A refusal timestamp
This refusal record is the enforcement-artifact-signature for the mechanism — the record format registered in the deployment registry for that mechanism. Because the mechanism-name and mechanism-kind fields are distinct per mechanism, black-box differential-behavior testing observes a distinct refusal record per mechanism and a distinct admit record on admission. An independent inspector verifies conformance by presenting candidate violating operations and confirming that the observed refusal records match the enforcement-artifact-signatures registered in the deployment registry for each mechanism.
The enforcement-artifact-signature field is not a policy declaration; it is a structural commitment that makes the architecture’s conformance externally verifiable without inspection of internal implementation. A deployment whose refusal records do not match its registered enforcement-artifact-signatures is a non-conforming implementation regardless of whether the underlying mechanisms enforce the correct conditions.
← Bidirectional boundary closure · Section index · Named-authority standing →