§02a Jupiter — Base Analysis — The analysis battery

Mars® Spec › §02a Jupiter — Base Analysis › The analysis battery

← The governing ground truth · Section index · The divergence signal →

3. The analysis battery

The analysis battery may employ one or more methods, usable singly or in any composition. The enumeration of methods is non-limiting and open to further and future methods and model classes, sizes, and generations.

Intermediate representation (IR). An IR is any order-typed artifact that exists between the raw input and the final analysis-ready discrete form. It is a first-class artifact — not an implementation detail — subject to the same structural requirements as the final form. An IR element may be fully order-typed (assigned to a single order with the order-shape contract satisfied), provisionally typed (candidate order assigned, pending disambiguation), or untyped-pending (awaiting order assignment). An IR in which all elements are fully order-typed is analysis-ready; all others are staging forms. The full specification of IR structure, multi-stage witness chains, convergence criterion, and irreducibly probabilistic cases is in §5a. A deployment whose pipeline never produces an intermediate form — where the raw input is directly promotable to a fully order-typed discrete form in a single transformation — satisfies the IR requirement vacuously: the single-stage output is both the IR and the final form; the witness chain has one link.

Battery methods are organized into three layers relative to the IR. A method’s layer determines what it operates over and what it contributes to the multi-stage witness chain. The layer classification is a structural property of the pipeline, not a constraint on which methods may be combined across layers:

Pre-IR methods — operate over raw or lightly-parsed input to produce or shape an IR; their outputs are IR artifacts, not verdicts
IR-level methods — operate over a fully or partially order-typed IR to produce analysis outputs (path verdicts, constraint solutions, scored evaluations); their outputs feed the aggregate verdict
Post-IR methods — operate over forms derived from a fully-typed IR (lowered formal specifications, constraint encodings, proof artifacts); their outputs are terminal verdicts or proof records

A deployment may use methods from multiple layers in sequence or in parallel. The witness chain (§5a.2) records which methods ran at which layer and what each produced.

Pre-IR methods.

Any method or discipline from any field of computer science, mathematics, statistics, or formal methods that satisfies the pre-IR layer precondition — operating over raw or lightly-parsed input to produce an order-typed IR artifact — is admissible as a pre-IR method. The admissibility condition is the precondition, not membership in any enumeration. The following categories and their non-limiting illustrative entries cover the known space; the category structure is itself non-limiting:

Category	Non-limiting examples	What the category produces
Language-model and neural analysis	LLM-based analysis, prompting strategies, paraphrase-perturbation, chain-of-thought decomposition, instruction-tuned classifiers	Semantic IR or probabilistic type assignments over input elements
Learned classification	Trained discriminative classifiers, multi-label classifiers, zero-shot and few-shot classifiers, ensemble classifiers	Type-state assignments or order-membership scores over input elements
Embedding and metric-space methods	Embedding-similarity scoring, embedding perturbation, nearest-neighbor retrieval, dense retrieval, cross-encoder reranking	Metric IR over input elements for order-proximity scoring
Symbolic and formal parsing	Formal grammar parsing, abstract syntax tree construction, symbolic mapping (representing domain concepts as formal symbols to generate a collection of representations eligible for symbolic execution), type-theoretic analysis, ontology-based concept mapping, regular-expression and pattern extraction	Symbolic IR with explicit structural typing; enables symbolic / microexecution at IR level
Probabilistic and statistical inference	Probabilistic graphical models, Bayesian inference, abductive reasoning, statistical hypothesis generation, Monte Carlo methods	Probabilistic IR whose elements carry posterior distributions over order assignments
Embedding-space traversal	Controlled embedding transformation (§4b.2): any declared, parameterized, recomputable operation on an embedding navigating the metric space under the domain model’s order structure; may be applied at pre-IR, IR-level, or post-IR wherever an embedding is present	Traversal-positioned artifact whose elements are located at domain aspects reached by the operation; traversal witness (§4b.4) carried in the witness chain regardless of layer
Abstract interpretation and program analysis	Abstract interpretation over input structures, data-flow analysis, control-flow graph extraction, taint analysis over structured input	Partially or fully order-typed IR with structural annotations suitable for IR-level or post-IR methods
Logic and constraint extraction	First-order logic extraction, constraint mining, dependency parsing to logical form, decompilation of structured content to logical predicates	Constraint-bearing IR suitable for SMT/SAT or theorem-proving post-IR methods

Any method not listed above that satisfies the pre-IR layer precondition is equally admissible; the tables do not limit the admissible set. A licensee implementing a pre-IR method from any CS, mathematics, statistics, or formal-methods discipline not represented above does not require a specification amendment; the method is admitted by the category structure’s non-limiting property.

IR-level methods:

Method	Family	Description
Symbolic / microexecution	Deterministic	Execution over symbolic rather than concrete values, operating over a fully order-typed IR; produces path condition records, symbolic state records, and path verdicts (§5a.5)
Deterministic rule/constraint evaluation	Deterministic	Rule and constraint checking over a typed IR; produces per-constraint verdicts
Model-as-judge scoring	Probabilistic	Scored evaluation via a learned model acting as judge over a typed IR; produces scored verdicts contributing to the aggregate

The Family column governs cross-method corroboration eligibility (§4): a battery that includes model-as-judge at the IR level alongside any deterministic IR-level method contains both families and satisfies the condition for a corroboration signal.

Post-IR methods:

Method	Description
Symbolic conversion (autoformalization)	Lowering a fully order-typed IR into a formal symbolic or mathematical specification for solver or prover consumption
SMT / SAT solving	Satisfiability modulo theories or boolean satisfiability over a constraint encoding derived from the IR
Theorem proving	Formal proof construction and verification over a specification lowered from the IR
Execution against sample data or an oracle	Empirical behavioral characterization over a specification or program derived from the IR
Test-suite validation	Declared test-suite execution against a specification or program derived from the IR

The enumeration of methods in each table is non-limiting. Methods not listed here are admissible provided they satisfy the layer precondition — operating over the appropriate form — and contribute their outputs to the witness chain.

Offline precompute. Because the analysis space is knowable in advance from the domain models, specifications, knowledge bases, and data sources, the system may precompute analysis artifacts (lifted forms, solver results, embeddings, divergence baselines, traversal positions, transformation sequences, surfaced-content records) offline and serve them at constant time. Offline precompute is an embodiment enabled by the knowability of the space; it does not alter the structure of the analysis, the verdict, or the recomputation witness. Precomputed traversal artifacts carry the same traversal witness requirements as live traversal acts (§4b.4); serving a precomputed traversal result without a conforming traversal witness is not a governed traversal act.

3a. Battery execution and verdict discipline

The analysis battery produces a verdict through a declared composition discipline — ordered pass execution, per-pass audit emission, and a mechanical status determination rule. The inventive matter is the composition discipline, not the count or labeling of passes. The battery’s declared pass set is non-limiting and open: additional passes may be registered with their soundness anchors and ordering constraints. The composition discipline applies identically to any declared pass set.

Soundness anchor (canonical definition). A soundness anchor is the structural basis on which a governed result is independently reproducible by a qualified inspector without access to internal deployment state. An anchor is a structural object, not an assertion of correctness: it names what an inspector re-derives the result from. Every governed result that carries a soundness claim declares its anchor. The term applies at three levels, each governed by this definition:

Pass-level — the anchor of a single declared battery pass, as used in this section. No declared pass may name a model-internal signal as its soundness anchor: a logit, token probability, or any value computed internal to a model’s forward pass is not independently reproducible by an inspector and therefore cannot serve as an anchor.
Composed — where a result is composed from constituent operations, it does not assert soundness at the composed level; it inherits the constituents’ anchors, order-indexed and traceable per discharged obligation (§01 §6 order-typed soundness inheritance, D43; the anchor-inheritance records of §3a.3 B9). A composed output that does not declare the anchors it inherits is structurally incomplete.
Chained across a boundary — where a governed result depends on acts performed on the other side of a structural boundary, the retained recomputation witnesses for those acts are the anchor segment the result inherits (§02e §5, §02e §10). Where no such witnesses are supplied, the anchor is the locally-retained recomputation witness alone: the chain is shorter but structurally complete for the segment it covers.

A result whose declared anchor cannot be re-derived by an independent inspector from retained records alone does not carry a soundness claim under this specification, regardless of how the result is labeled.

3a.1 Per-pass audit emission

Each pass result is recorded immediately upon completion to an append-only, hash-chained audit chain. The audit chain is the externally-verifiable record of the battery’s operation.

PassRecord {
  artifact_id, spec_id, spec_version,
  pass_name,
  battery_method_identity,        // §02a battery method (§3) invoked by this pass
  orders_acted_upon: list<order_identity>,  // order(s) this pass acted upon under the order-decomposition
  passed: bool,
  execution_stratum: ∈ {hot, warm, cold, continuous-async},
  cache_hit: bool,
  elapsed_ms: int,
  falsifier: dict | null,
  diagnostics: list<str>,
  ddil_state,
  substrate_version_tuple,
  emitted_at,
  prior_chain_hash,
  signature: <EUF-CMA-secure asymmetric digital signature over (payload ‖ prior_chain_hash) under the audit-chain authority's private key; verification key published in the specification registry>,
  chaincode_commitment: <optional; present when the ON_CHAIN_ANCHOR pattern (§02b §7) is
    active; declares target_chain_id, chaincode_or_contract_address, serialization_format,
    and txid (null before commitment, populated after a CERTIFY verdict is committed to the
    distributed ledger); a PassRecord carrying this field with a null txid after CERTIFY
    emission is structurally incomplete>
}

The chain is tamper-evident and independently recomputable: H(n) = SHA256(H(n-1) ‖ payload(n)). Tier provenance (hot/warm/cold/continuous-async) is material: it discloses whether a result was served from a hot path, a cold precompute, or a continuous asynchronous process.

Substrate-version tuple cache-rejection rule. A cache lookup that serves a PassRecord produced under a substrate_version_tuple that does not match the current substrate-version tuple is refused. The refused cache result triggers re-execution of the pass under the current substrate. A stale or cross-version cached PassRecord may not be admitted as a valid cache hit regardless of its other fields. This rule is enforced at each cache lookup; no deployment configuration may disable it.

The battery_method_identity field binds each pass to a specific §3 battery method entry in the multi-stage witness chain. An independent inspector can trace from any pass in the audit chain to the battery method that produced it.

The ddil_state field encodes the ordered sequence of (analysis-spec-identity, pass-name, execution_stratum) tuples on the active composition stack for the current session or transaction scope. It is used by the re-entrance discipline (§3a.4).

3a.2 Mechanical tri-state status-determination rule

After all required passes complete, the verdict status is determined mechanically from the multiset of per-pass (passed, has_falsifier) tuples — order-independent, no thresholds, no soft logic:

if any pass result has passed=False and falsifier ≠ null:
    status = REFUSE
    reason = "{failing_pass_name}_falsifier"
elif any pass result has passed=False and falsifier == null:
    status = REFER
    reason = "{failing_pass_name}_referral"
else:
    status = CERTIFY

CERTIFY — all passes returned passed=True.
REFUSE — affirmative evidence of non-conformance; a falsifier is present; dispositive under all operating conditions including load, execution stratum, and DDIL state.
REFER — a pass could neither confirm nor refute; routed for human or authority resolution.

Mapping to certificate-level verdict vocabulary. The mechanical tri-state status (§3a.2) maps to the certificate-level verdict enumeration ({conforming, non-conforming, conditionally-conforming}, §7) as follows: CERTIFY → conforming; REFUSE → non-conforming; REFER → conditionally-conforming (provisional). A REFER verdict does not directly produce a conditionally-conforming certificate entry — it opens a gap record in the canonical gap governance machine (§03-iii §2.0) at Open state. The gap record transitions through Open / In-resolution and resolves to one of: (i) CERTIFY on re-verification after the gap is closed → conforming; (ii) REFUSE on re-verification if the gap resolution reveals affirmative non-conformance → non-conforming; (iii) Declared-permanent if the governing authority declares the gap permanently open → no certificate issued for the affected scope; the certificate’s declared scope (Field 5) is narrowed to exclude the permanently-gapped locus. The term conditionally-conforming therefore names the provisional state of the open gap record, not a stable semantic quality of the artifact. A certificate carrying conditionally-conforming as its Field 4 verdict is co-required to carry a conditions record identifying the open gap record identity, the locus, and the resolution authority or process.

DDIL-state absoluteness. A falsifier returned by any pass under any execution stratum and any ddil_state produces REFUSE. No deployment configuration may down-rate a REFUSE to REFER when a non-null falsifier is present, regardless of operating condition (degraded, intermittent, disconnected, or otherwise constrained). The absoluteness of this rule is a load-bearing property: any softening of it destroys the falsifier’s function as affirmative non-conformance evidence.

The rule is reproducible: identical inputs produce identical output regardless of pass execution order, enabling audit-chain reconstruction by an independent inspector.

3a.3 Pre-emission gates

Before a CERTIFY verdict is emitted as a CertifiedBundle, an anchor-inheritance annotation step executes, followed by two gates.

Anchor-inheritance annotation. Before the pre-emission gates, the verdict is annotated with per-obligation soundness anchor records: for each discharged obligation, the per-pass soundness anchor(s) that obligation inherits are attached to the verdict, tied to the order-structure of the discrete representation or composed discrete program that was the subject of that pass. The anchor-inheritance records are co-required structural elements of the CertifiedBundle: a bundle emitted without anchor-inheritance records for each discharged obligation is structurally deficient even if the verdict status is CERTIFY. This annotation is what distinguishes the composed verdict from a verdict aggregation that asserts a combined result without an anchor trail — a downstream consumer can trace each discharged obligation to the specific pass soundness anchor(s) that ground it.

Procedural-verification gate (PV-gate). Refuses emission when a structural provenance requirement on any predicate in the bundle is unmet. The specific provenance requirements are declared by the applicable boundary section — §02c declares the non-language-provenance anchor requirement for predicates arriving via the non-language bridge. Refusal results in verdict downgrade to REFER or no bundle emission.

Authority-reconcile gate (AR-gate). The AR-gate governs federated multi-agent deployments in which two or more authority agents may each produce attestations over the same artifact. In a single-agent deployment the gate is vacuously cleared; the full mechanism applies when peer agents are present. The gate enforces seven interoperating requirements — peer-finding, local re-verification, divergence detection, reconciliation event emission, verdict downgrade, resolution outcome classification, and partition-recovery — that together form the AUTHORITY_RECONCILE protocol (version 1.0).

AR-gate.1 Peer-finding message format. An authority agent that has produced a verdict on an artifact emits a peer-finding message to all peer agents in the deployment. The message is typed:

PeerFinding {
  message_id:           UUID,
  source_agent_id:      registered agent identity,
  source_authority_id:  registered authority identity,
  source_spec_id:       registered analysis specification identity,
  source_spec_version:  version token,
  artifact_id:          registered artifact identity,
  artifact_content_hash: SHA256 over artifact canonical form,
  verdict_status:       ∈ {CERTIFY, REFER, REFUSE},
  verdict_scope:        scope certificate identity,
  verdict_record_id:    PassRecord audit chain pointer,
  signature:            EUF-CMA-secure signature under the emitting agent's private key,
  emitted_at:           ISO 8601 timestamp
}

A peer-finding message is a registered structure: its message_id, source_agent_id, artifact_content_hash, and verdict_status are carried in the audit chain of the receiving agent. A receiving agent that does not record a received PeerFinding in its audit chain exhibits a conformance defect observable by an independent inspector.

AR-gate.2 Local re-verification and no-unverified-propagation invariant. A receiving agent MUST NOT adopt a peer-supplied finding without first independently re-verifying the same artifact under the same governing specification (§01 §7 five-component bundle, §01 §12.1 governing collection). This is the no-unverified-propagation invariant: no agent propagates a peer verdict as its own without a local re-verification pass. The invariant is structurally enforced — the PassRecord for the local re-verification pass must precede any inter-agent consensus record in the audit chain; absence of this pass record is an independently observable conformance defect. The invariant is tested under adversarial-peer simulation: a receiving agent that emits CERTIFY in response to a peer-supplied CERTIFY without a local re-verification PassRecord fails the adversarial-peer conformance test.

AR-gate.3 Divergence detection. A divergence condition is detected when either of the following occurs:

A receiving agent holds a completed local verdict and receives a PeerFinding from a peer agent where verdict_status differs from the local verdict status for the same artifact_id and matching artifact_content_hash.
A receiving agent’s local re-verification pass (AR-gate.2) yields a status distinct from the status reported in the peer-finding message it is verifying.

When a divergence condition is detected, the AR-gate triggers. An artifact whose artifact_content_hash differs between peer-finding messages is not a divergence — it is a version mismatch and is handled by the registration system (§02b §5 delta-attestation), not by the AR-gate.

AR-gate.4 Reconciliation event. On divergence detection the detecting agent emits a typed reconciliation event:

ReconciliationEvent {
  event_id:              UUID,
  divergence_id:         UUID — stable across all re-emissions for this divergence instance,
  artifact_id:           registered artifact identity,
  artifact_content_hash: SHA256 over artifact canonical form,
  divergent_attestations: list of {
    agent_id, authority_id, verdict_status, verdict_record_id, source
  } — one entry per diverging attestation including the local one,
  detected_at:           ISO 8601 timestamp,
  detected_by_agent:     registered agent identity,
  signature:             EUF-CMA-secure signature under the detecting agent's private key
}

The divergence_id is stable: re-emissions of the reconciliation event for the same divergence instance — for example after a partition recovery — carry the same divergence_id. A downstream consumer or inspector can group all activity pertaining to a single divergence instance by divergence_id. The ReconciliationEvent is registered in the gap governance system as a governing-conflict gap record (§01 §12.4) with the ReconciliationEvent fields providing the two-artifact locus and conflict aspect fields.

AR-gate.5 Verdict downgrade. Upon AR-gate trigger, the verdict status is immediately downgraded to REFER with reason = "authority_reconcile_pending" and divergence_id carried in the reason record. The downgraded REFER is the terminal verdict for this invocation; subsequent passes do not execute (pipeline-termination rule, §3a.3). No CERTIFY is emitted for the artifact while the divergence_id is in Open or In-resolution state in the gap governance machine (§03-iii §2.0). An inspector verifies this by confirming that no CertifiedBundle exists for the artifact under the same artifact_content_hash and source_spec_id/version while the gap record for divergence_id is not Resolved or Declared-permanent.

AR-gate.6 Resolution outcome enumeration. The divergence identified by divergence_id is resolved through the gap governance procedure (§01 §12.5, §03-iii §2.0). Resolution yields exactly one of four typed outcomes:

Outcome	Semantics
`ratify_amend`	The governing specification (§01 §7 bundle) is amended; the amendment enters the delta-attestation lifecycle (§02b §5); the scope classification of the amendment (scope-preserving, scope-extending, scope-restricting, or scope-breaking) determines which issued verdicts are invalidated; re-discharge is required for all affected verdicts; the soundness declaration (§01 §7 Component E) content hash is recomputed and the bundle version identifier is updated
`admit_after_review`	A higher-authority review process (§01 §8 adjudication hierarchy, human adjudication as superior form) admits one attestation as authoritative; the admitted attestation is registered as the governing attestation for the artifact under this specification version; the competing attestation is annotated as superseded
`refuse_with_justification`	The artifact is refused; the justification is a registered record citing the divergent attestations, the review process, and the authority under which the refusal was determined; the refusal is carried as a gap-verdict annotation (§01 §12.6) on any prior verdicts over the artifact
`escalate`	The divergence cannot be resolved at the current authority level; it is escalated to the next level in the authority hierarchy (§01 §8); the gap record transitions to In-resolution at the escalation target; a maximum escalation depth is declared in the deployment registration

The resolution outcome record is appended to the gap record and to the audit chain of each participating agent.

AR-gate.7 Partition-recovery protocol. Where a network partition separates agents during an active analysis, the following declared bounds apply:

Handshake bound. An agent detecting the loss of peer connectivity emits a partition-detection event and completes a peer-reconnection handshake within the declared handshake bound of connectivity restoration. The handshake bound is a registered parameter of the deployment manifest runtime configuration record (canonical default: 2 seconds); a deployment declaring a longer bound must justify it against its declared link characteristics in the runtime configuration record. The bound governs recovery after connectivity restoration; it does not bound the duration of the disruption itself.
Consistency-recovery bound. Full PeerFinding exchange and reconciliation event resolution for all artifacts active during the partition is completed within the declared consistency-recovery bound of handshake completion. The consistency-recovery bound is a registered parameter of the deployment manifest runtime configuration record (canonical default: 60 seconds); a deployment declaring a longer bound must justify it against its declared active-artifact volume and link characteristics. Exceeding the declared bound is a recorded recovery-overrun event: partition-era verdicts remain partition_era_provisional and no new CERTIFY is emitted for affected artifacts until reconciliation completes.
Deterministic merged specification. Where the partition produced divergent local specifications (§01 §12 governing collection amendments during partition), the post-partition merge produces a single deterministic merged governing collection; the merge procedure is declared in the deployment registration and is not agent-dependent. Non-deterministic merges are non-conforming.
Verdict re-discharge. Any CERTIFY verdict emitted by an agent during the partition is subject to mandatory re-discharge under the no-unverified-propagation invariant after the partition recovery; a partition-era CERTIFY is annotated as partition_era_provisional and is not admitted as a stable verdict until re-discharged.
Invariant preservation. The no-unverified-propagation invariant (AR-gate.2) applies without relaxation during and after partition recovery; a partition does not constitute an exception to the invariant.

AR-gate capability advertisement. A deployment supporting the AUTHORITY_RECONCILE protocol declares capability AUTHORITY_RECONCILE/1.0 in its registration record. Capability advertisement is subject to the upward strict-stronger rule: a deployment declaring AUTHORITY_RECONCILE/1.0 must implement every requirement of AR-gate.1 through AR-gate.7 without exception; a deployment implementing a subset may not advertise the capability. An inspector verifies capability advertisement by testing each of the seven requirements under adversarial-peer simulation.

CertifiedBundle co-required fields. A conforming CertifiedBundle carries all of the following: (i) the typed predicates discharged in this invocation; (ii) the scope certificate produced by the scope-certification pass; (iii) the composed discrete program where the discrete-representation pass produced one; (iv) the verdict with its anchor-inheritance records; and (v) a pointer into the append-only audit chain at the position of the first PassRecord for this invocation. A bundle missing any of these fields is not a conforming CertifiedBundle and is refused at any downstream gate that receives it.

Gate ordering and pipeline-termination rule. AR-gate and PV-gate events are pipeline-terminating. Upon AR-gate downgrade to REFER, no subsequent verification pass executes; the composition gate emits a single REFER record attributing the terminal condition to the authority conflict; the per-pass audit record for the triggering pass records passed=False with falsifier=null (the authority conflict constitutes a referral, not a refusal, consistent with the tri-state rule). PV-gate failure similarly terminates the pipeline. On the non-terminated path, after all declared passes have completed and all pre-emission gates have cleared, the tri-state rule (§3a.2) is applied to the full multiset of pass results. On the pipeline-terminated path, the terminal gate verdict (REFER) is emitted directly; the tri-state rule is not applied.

When the typed-structure pass short-circuits the pipeline (failure at first pass), the PV-gate and AR-gate are applied against that pass’s PassRecord alone; the tri-state rule is then applied to that single-pass result.

3a.4 Re-entrance discipline

The final required pass in any composition invocation is the re-entrance discipline pass. It examines the ddil_state field in the PassRecord, which encodes the ordered sequence of (analysis-spec-identity, pass-name, execution_stratum) tuples currently on the active composition stack.

A re-entrance violation is detected when the (analysis-spec-identity, pass-name) pair of the current pass appears in ddil_state at any prior position. On violation: passed=False, falsifier=<re-entrance-cycle-descriptor listing the repeated tuple and its prior position index>. On non-violation: the current pass tuple is appended to ddil_state and passed=True. ddil_state is initialized to the empty sequence at the start of each top-level composition invocation.

3a.5 Procedural-confidence derivation function

The procedural-confidence value is a structurally-derived normalized weighted sum of four inputs, computed from the PassRecord set accompanying the CertifiedBundle:

Verification execution stratum of the originating composition pass.
Non-terminal pass count ratio — count of all declared passes excluding the re-entrance pass returning passed=True divided by the total number of such passes executed in this invocation.
Inverse falsifier count — 1 / (1 + falsifier_count) across all passes, equal to 1 where falsifier count is zero.
Actuation-scope-intersection coverage ratio — from the actuation anchor (§02c §4 Field 5), where the output is routed to a non-linguistic effect; zero where not applicable.

The inventive matter is the combination of all four named inputs. A derivation function that omits any one of the four named inputs does not practice this mechanism, regardless of how the remaining inputs are weighted or how the function is otherwise structured. Adding a fifth input does not alter conformance provided all four named inputs remain present and operative.

Weight registration. The weights for these four inputs are declared artifacts registered in the specification registry under the analysis specification identity. They are subject to the delta-attestation lifecycle (§02b §5) on amendment; a scope-breaking amendment invalidates procedural-confidence values issued under the prior weight declaration. The weight registration record carries: the analysis specification version it is bound to, the four declared weights (summing to 1.0), the normalization procedure, and a cryptographic signature over the weight record.

Normalization. The weighted sum is normalized by the declared normalization procedure, which must be: (i) declared in the weight registration record; (ii) deterministic given the four input values and the weights; (iii) independently recomputable by an inspector from the PassRecord set.

Derivation exclusion. The function explicitly excludes any logit, token probability, calibration score, or value computed internal to a language model’s forward pass. An independent inspector verifies a given procedural-confidence value by re-computing the function from the PassRecord set using the declared weights and normalization procedure.

Confidence floor registration. For actuation classes declaring a confidence floor, the floor value is registered in the actuation-class declaration in the specification registry. The downstream actuation gate (§02c §4.3) enforces the floor. The floor value is not a threshold on model output; it is a threshold on the procedural-confidence value derived structurally from the PassRecord set.

← The governing ground truth · Section index · The divergence signal →