§02a Jupiter — Base Analysis — The divergence signal
Mars® Spec › §02a Jupiter — Base Analysis › The divergence signal
← The analysis battery · Section index · Symbolic lift and order-typed representation →
4. The divergence signal
Where two or more method families are present in the deployed battery — specifically both a deterministic family and a probabilistic family — the system records their agreement and disagreement on the same conformance question as a measurable signal. This is the cross-method corroboration signal.
The divergence signal is a continuous contribution to the verdict and to confidence. There is no fixed threshold; thresholding, if any, is declared at deployment registration. On agreement, the divergence signal raises procedural-confidence. On disagreement, it flags for review or triggers a gap referral.
Aggregation across multiple method pairs. Where the deployed battery produces more than one divergence signal — because it contains more than two method families, or because multiple method pairs evaluated the same conformance question under different order-perspective combinations — the signals are aggregated into a single composite divergence contribution before feeding the verdict. The aggregation function is declared at deployment registration and carried in the analysis battery record. The aggregation function must be: (a) declared — not inferred post-hoc; (b) stable across re-derivations — an independent inspector applying the declared aggregation function to the recorded per-pair signals must reproduce the composite contribution; (c) order-typed — the aggregation records which orders each constituent pair evaluated, so that a downstream consumer can determine whether high-divergence results were confined to a specific order.
Non-limiting admitted aggregation functions: weighted sum with declared per-pair weights; maximum divergence (conservative upper bound); declared priority ordering with first-diverging pair governing; unanimous-agreement requirement (composite divergence is zero only when all pairs agree). The aggregation function identity and its parameters are declared fields in the analysis battery record. An analysis battery record that reports a composite divergence contribution without declaring the aggregation function does not satisfy the independent-re-derivability requirement of Field 7.
Conditionality. Cross-method corroboration is an emergent property that arises only when both deterministic and probabilistic method families are present. Where the deployed battery contains only one method family, corroboration is vacuously satisfied: Field 3 of the certificate records the battery composition and the absence of cross-family corroboration is not a conformance defect. Single-method-family deployment is a valid embodiment.
Same-kind ensembling and single-architecture hybrids are prior art. The inventive contribution is the cross-kind divergence signal: the deterministic and probabilistic analyses run in parallel over the same conformance question; their divergence or agreement is a recorded measure in the analysis battery record.
Cross-phase corroboration. Where a registered pre-invocation signal source (§02e) produced a deterministic verdict over the same input and the same governing-specification predicates that the §02a probabilistic battery also evaluates, their agreement or disagreement is a cross-phase corroboration signal — a species of the cross-kind divergence signal operating across the pre-invocation / post-invocation boundary. It is recorded as pre-invocation-cross-phase in the analysis battery record and contributes to the verdict and confidence on the same basis as within-battery corroboration. Full specification in §02e.
4a. Multi-perspective, multi-order, multi-source analysis
The analysis spans one or more orders, under one or more perspectives, over one or more domain models, knowledge bases, data sources, and governing specifications — combinatorially. The mechanism is block-agnostic and count-agnostic: there is no fixed count of orders, perspectives, or sources; any combination is admitted. The same artifact analyzed under different perspectives produces observably different analyses and verdicts.
A single-method, single-order, single-source analysis is one embodiment of this combinatorial structure, not a limitation. The analysis-artifact structure is invariant across the full range of compositions: the verdict and recomputation witness produced by a single-method, single-order analysis are structurally identical to those produced by a multi-method, multi-order, multi-source analysis. A deployment cannot narrow its structural footprint by reducing the number of methods, orders, or sources it employs.
Traversal as the enabling mechanism. The combinatorial structure of §4a is made operational by traversability (§4b): the domain model’s metric space is the map over which multi-order, multi-perspective, multi-source analysis is navigated. Battery methods operate over what traversal surfaces, not directly over raw artifact content. §4b specifies traversal as a first-class analysis feature.
4b. Traversability
Traversability is the governed, recomputable navigation of the domain’s metric space during analysis. It is a first-class feature of the analysis layer — not a retrieval convenience, not a downstream application detail, and not reducible to similarity search. The domain model (§01) produces the map: order-decomposition, aspect identifiers, relational metrics, variant consistency map, and distance measures. Traversal navigates that map. The metadata of every governed artifact (KB metadata, data source metadata, query library — §03-i, §03-ii) is built against the same map and constitutes the traversal index: arriving at a domain aspect via traversal surfaces all KB entries, data source fields, and queries bound to that aspect.
Traversal is the mechanism by which multi-order, multi-perspective, multi-source analysis (§4a) is operationalized: the combinatorial structure of §4a is navigated via traversal, not assembled by static enumeration. Pre-IR battery methods may operate over raw content to produce an IR; traversal then navigates that IR against the domain model’s metric space to supply the battery with order-typed, aspect-keyed, witness-bound content for analysis acts. Traversal may be initiated at any pipeline layer — pre-IR, IR-level, or post-IR — wherever an order-typed or embedding-bearing artifact is present.
Governing structural invariant. Every traversal act, regardless of mechanism, pipeline layer, or mathematical form, is governed by the same structural requirements: (a) it is initiated from and steered by declared inputs bound to the domain model’s aspect structure; (b) it is parameterized — all parameters are declared and registered; (c) it is recomputable — an independent inspector can re-derive the traversal path and its outputs from the traversal witness without deployment access; (d) its outputs are order-typed and aspect-keyed; and (e) it contributes a traversal witness link to the multi-stage witness chain (§5a.2). A traversal mechanism that satisfies these five conditions is governed here regardless of its mathematical form, algorithmic lineage, or layer of operation. A mechanism that does not satisfy all five conditions is not a traversal act under this specification, regardless of its resemblance to traversal in output or intent.
4b.1 The traversal metric space
The traversal space is the metric space defined by the domain model’s relational quantification outputs (§01 §3.1) and variant consistency map (§01 §5.1). Every domain aspect occupies a position in this space; distance and similarity measures between aspects are first-class model outputs, registered declared artifacts, not implementation details. The variant consistency map establishes the ground truth for semantic equivalence across surface-form variation — a traversal that arrives at a known-equivalent variant is a confirmed move; one that arrives at an undeclared position is a discovery candidate or a gap signal.
Distance and similarity measures. The declared measures governing the metric space are registered artifacts subject to the delta-attestation lifecycle. Non-limiting admitted measure classes: cosine similarity, dot-product similarity, declared-distance-function evaluation, cross-order relational metric, cross-perspective relational metric, Mahalanobis distance under a declared covariance structure, learned metric from a declared metric-learning procedure. The measure class, its parameters, and its registered identity are carried in the traversal witness (§4b.4) for every traversal act.
Traversal inputs and steering. A traversal act may be initiated from and steered by any combination of: one or more domain model aspect identifiers, one or more formal specification predicates, KB metadata aspect bindings with declared optional strength, data source metadata aspect bindings with declared optional strength, and query library entries (§03-i). Where multiple steering inputs are provided, their combination is governed by a declared steering-composition function registered at deployment. Where steering inputs conflict — for example, a KB metadata binding points toward one aspect and a formal specification predicate points toward another — the conflict is recorded in the traversal witness as a steering-conflict entry and does not produce a silent resolution. The steering-composition function, its parameters, and any steering-conflict entries are carried in the traversal witness.
The traversal index. KB metadata binds KB chunks, extractions, or evidence collections to domain aspects with optional declared strength. Data source metadata binds tables, schemas, collections, and field combinations — including multi-field combinations — to domain aspects with optional declared strength. The query library (§03-i) carries pre-declared traversal paths into the data source as queries relating to one or more domain aspects. These bindings are the traversal index: they are what makes the metric space navigable against real artifact content. The index is a property of the governed artifacts, not of the traversal mechanism; the same index is navigated by any conforming traversal act regardless of its mathematical form.
4b.2 Controlled embedding transformation
A traversal act may navigate the metric space by applying controlled transformations to an embedding — governed movements through the space that expose structure not accessible by proximity lookup alone. These transformations are not heuristic operations; they are declared, parameterized, recomputable acts that produce witnessable positions in the metric space. The governing structure is the domain model’s order-typed metric space; the transformation is the navigation mechanism. Any parameterized, recomputable operation on an embedding that navigates that space under the domain model’s order structure is a controlled embedding transformation under this specification, regardless of its mathematical form.
Non-limiting admitted transformation classes:
| Transformation class | Description |
|---|---|
| Magnitude scaling | Scale the embedding vector by a declared scalar factor; governs the reach of the traversal from the current position without changing direction |
| Dimensional rotation | Apply rotations in declared 2D subspaces; reorients the traversal direction without changing position magnitude; useful for exploring angular neighborhoods |
| Spectral filtering | Retain components above a declared magnitude percentile; isolates the dominant dimensional structure and suppresses noise dimensions |
| Sign flipping | Flip the sign of a declared ratio of components; tests the analytic consequences of polarity reversal — useful for probing the structure of antonymic or contrastive aspects |
| Component perturbation | Add proportional noise to the largest components; tests perturbation stability — a finding that survives perturbation is more robust than one that does not |
| Subspace projection | Project the embedding onto a declared subspace (e.g., spanned by a set of aspect vectors); isolates the component of the embedding relevant to a declared order or perspective |
| Cross-embedding arithmetic | Compute a linear combination of two or more embeddings (addition, subtraction, weighted sum, analogy-style A−B+C); produces positions in the metric space that express relational structure between aspects |
| Interpolation | Traverse the geodesic or linear path between two declared positions in the metric space; exposes intermediate aspects and transition structure |
| Centroid displacement | Compute the centroid of a declared set of aspects and displace toward or away from it by a declared factor; navigates toward or away from the prototype of a cluster |
| Adversarial perturbation | Apply a perturbation computed to move the embedding toward or across a declared decision boundary in the metric space; tests boundary stability and probes the robustness of the current position’s order assignment |
| Attention-weighted reweighting | Reweight components by a declared attention or salience vector; navigates the space from the perspective of a declared ordering of dimensional importance |
| Manifold projection | Project the embedding onto a declared lower-dimensional manifold; enables traversal within a constrained region of the metric space corresponding to a declared aspect cluster or order subspace |
The enumeration is non-limiting. Any transformation class satisfying the governing structural invariant (§4b intro) may be declared by the licensee or by other parties, registered with its governing parameters, and used as a traversal act. Each transformation is a declared, parameterized, recomputable act: the transformation class identity, its registered parameters, and the pre- and post-transformation embedding content hashes are carried in the traversal witness (§4b.4).
Transformation sequences. Transformations may be composed in sequence, producing a traversal path through the metric space. The path is the ordered record of transformations applied and positions reached. The path is itself a recomputable artifact; an independent inspector re-derives it from the traversal witness. A transformation sequence that produces a position not traceable via the witness to a sequence of declared transformation acts is not a governed traversal path.
4b.3 Traversal-driven analysis acts
Traversal locates, surfaces, and positions domain-aspect-bound content in the metric space. The analysis battery (§3) then operates over that content. Every traversal-driven analysis act must produce an order-typed, aspect-keyed, witness-bound output: the output must declare which domain aspect(s) it was performed at, under which orders and perspectives, and carry a binding back to the traversal witness that supplied the content. An act that produces a verdict or finding without an aspect-keyed, witness-bound output does not satisfy this structural invariant and is not a traversal-driven analysis act under this specification.
Non-limiting admitted analysis acts:
| Analysis act | Description |
|---|---|
| Confirm / ratify | Assert that a traversed finding is consistent with the governing specification or domain model at the traversed aspect; produces a positive verdict contribution bound to the aspect and order |
| Refute | Assert that a traversed finding is inconsistent with the governing specification or domain model at the traversed aspect; produces a falsifier bound to the aspect and order |
| Hypothesis test | A proposed relationship between traversed aspects — including relationships not yet declared in the domain model — is tested against the metric space and governing artifacts; produces a supported, unsupported, or inconclusive result with a declared significance basis |
| Consensus | Agreement is evaluated across cross-model outputs, neighbor positions in the metric space, perturbation-stable results, and query-library outputs; the convergence or divergence of the consensus is a signal contributing to the verdict; the consensus membership (which models, neighbors, perturbations, or queries participated) is declared and carried in the witness |
| Mixture of experts | Multiple independent analysis paths over the same traversed element — potentially spanning different orders, perspectives, or battery methods — are combined under a declared combination function; the combination function, its parameters, and the per-path outputs are declared and registered |
| Deterministic program binding | A deterministic program (symbolic, constraint-based, or executable) is bound to the traversed element and executed for formal analysis; produces an order-typed verdict suitable for post-IR battery methods (§3) |
| Counterfactual analysis | A declared modification to the traversed aspect’s content or position is hypothesized and analyzed; produces a verdict over the hypothetical state, enabling the system to reason about what would change if a governing artifact or data value were different |
| Ablation | One or more components of the traversed content are systematically removed or suppressed; the change in the analysis output is measured; identifies which components are load-bearing for the verdict |
| Causal intervention | A declared causal model is applied to the traversed aspect; an intervention is made on a declared variable; the downstream effect on order-typed aspects is computed and recorded; produces a causal-structure finding bound to the aspect |
| Contrastive analysis | Two or more traversed positions are compared against the same governing artifact; their differences are characterized by order and perspective; produces a typed contrastive record identifying what distinguishes the positions |
| Boundary detection | The traversal is steered toward the decision boundary between two declared aspect regions in the metric space; the boundary’s position, stability, and sharpness are characterized; useful for identifying where the governing specification’s predicates transition |
| Coverage-driven exploration | The traversal is steered to maximize coverage of the metric space relative to a declared coverage criterion (e.g., all declared orders exercised, all governing-specification predicates activated); gaps in coverage are recorded as gap referrals |
| Licensee- and third-party-declared acts | Additional analysis acts declared and registered by the licensee or by other parties; governed by the same structural invariant, witness, and audit requirements as the enumerated acts; a declared act that does not satisfy the structural invariant is refused at registration |
Formal specification as a dedicated battery target. A formal specification (§01 §7) may itself be the target of a dedicated traversal-driven analysis battery, distinct from the analysis of an external target artifact against a governing specification. In this mode, the battery acts are applied over the specification’s own predicates, axioms, and relational structure, traversed via the domain model’s metric space. This produces a verification or certification verdict over the specification itself. The battery, witness, and audit requirements of §3 and §3a apply identically; the invocation record is observably distinct from a target-analysis invocation.
4b.4 Traversal witness
Every traversal act produces a traversal witness — a record sufficient for an independent inspector to re-derive the traversal path, the content surfaced, the analysis acts performed, and their outputs, without access to the deployment. The traversal witness is a first-class registered artifact and a required link in the multi-stage witness chain (§5a.2). A traversal act whose witness is absent, incomplete, or does not satisfy the minimum fields below is not a governed traversal act; any analysis act performed over its outputs does not satisfy the recomputation requirement.
Minimum required fields:
| Field | Content |
|---|---|
| Traversal act identity | A stable content-addressed identifier for this traversal act within the analysis invocation |
| Domain model version | The version of the domain model whose metric space was navigated; the metric space is version-specific and traversal results are not valid across domain model version boundaries without re-execution |
| Governing specification version | The version(s) of the governing specification(s) in effect at the time of traversal; carried to enable replay under the same governing context |
| Initiating inputs | The declared combination of aspect identifiers, formal specification predicates, KB metadata bindings (with declared strength), data source metadata bindings (with declared strength), and query library entries that initiated and steered this traversal |
| Steering-composition function | Where multiple steering inputs were provided: the declared function governing their combination, its registered identity and parameters, and any steering-conflict entries |
| Distance / similarity measure | The declared measure class, its registered identity, version, and parameters |
| Transformation sequence | The ordered record of every transformation act applied: for each act, the transformation class identity, its declared parameters, the pre-transformation embedding content hash, and the post-transformation embedding content hash; empty if no transformations were applied |
| Positions reached | The domain aspect(s) reached at each step of the traversal path, with their aspect identifiers and domain model version; positions that are discovery candidates or gap signals are flagged as such |
| Surfaced content | For each position reached: the KB entries, data source fields, and query library entries surfaced at that aspect, with their binding strength where declared and their artifact version identifiers |
| Analysis acts performed | For each analysis act: the act type, its declared inputs from the surfaced content, its order-typed aspect-keyed output, and its contribution to the verdict (positive, falsifier, gap referral, or inconclusive); the combination function and its parameters where mixture of experts or consensus acts were used |
| Gap referrals emitted | Any gap referrals raised during this traversal act, typed by locus (§7), each carrying the aspect identifiers, orders, and perspectives involved |
| Traversal witness hash | Tamper-evident binding over all fields of this traversal witness |
4b.5 Gap types surfaced by traversal
Traversal surfaces gaps that are not detectable by static analysis of the artifact alone. Gap referrals emitted during traversal are typed by locus, routed for reinforcement under the canonical gap governance mechanism (§03-iii §2.0), and carry the traversal witness hash binding the gap to the traversal act that surfaced it. The gap loci of §7 apply. Traversal additionally surfaces the following gap types, which are added to the locus taxonomy:
Higher-order analysis gap (higher-order-analysis). A gap in the analytical structure itself: two or more known values of known rules are present at traversed aspects, but the relationship between them at a higher-order level is unknown, undeclared, or has not been established. The individual rules are known; their values at the traversed aspects are known; but the cross-order or cross-perspective relationship record connecting them is absent or ambiguous. This is distinct from a specification gap (a missing rule), a KB gap (missing content), or a data source gap (missing data) — it is a gap in the higher-order synthesis layer (§01 §11) that traversal exposes by revealing that two aspects are in proximity but their relational structure is undeclared. A higher-order analysis gap referral carries: the aspect identifiers of the involved elements, the orders and perspectives under which they were traversed, the relationship type that is absent or ambiguous, and the traversal witness hash.
Cross-artifact consistency gap (cross-artifact-consistency). A gap surfaced when traversal reveals that two or more governing artifacts — for example, a KB entry and a formal specification predicate, or two formal specifications — assert inconsistent or contested values at the same domain aspect under the same order. This is distinct from the KB ↔ data source divergence signal (§03-iii §2.12), which operates at the attribution layer between KB governance and data-source instance-facts. The cross-artifact consistency gap operates at the traversal layer, between governing artifacts that are both in force as governing references. A cross-artifact consistency gap referral carries: the aspect identifier, the order and perspective, the identities and versions of the conflicting artifacts, the values they assert, and the traversal witness hash. The gap is routed to the adjudicator set declared for the governing specification collection in effect (§03-iii §2.2).
← The analysis battery · Section index · Symbolic lift and order-typed representation →