§02a Jupiter — Base Analysis — Verdict, gap analysis, and outputs
Mars® Spec › §02a Jupiter — Base Analysis › Verdict, gap analysis, and outputs
← Reverse-composition · Section index · Externally-observable properties →
7. Verdict, gap analysis, and outputs
Verdict. The system computes a typed verdict for the artifact against the governing ground truth from the analysis. The verdict is drawn from the canonical enumeration: {conforming, non-conforming, conditionally-conforming}. A verdict must be a grounded verdict — derived from and traceable to the analysis battery. An asserted verdict without traceable grounding does not satisfy this requirement.
Gap analysis and reinforcement routing. Where the analysis is insufficient or surfaces a deficiency, the system emits a typed gap rather than an unsupported verdict. The base locus taxonomy is: {domain model, governing specification, data source, knowledge base}. Where pre-invocation signals (§02e) are registered for this deployment, pre-invocation signal is admitted as a fifth locus. Where traversal (§4b) is performed, two additional loci are admitted: higher-order-analysis (§4b.5) — emitted when traversal reveals that two or more aspects are in proximity but their cross-order or cross-perspective relationship record is absent or undeclared; and cross-artifact-consistency (§4b.5) — emitted when traversal reveals that two or more governing artifacts assert inconsistent or contested values at the same domain aspect. Where two or more individually-adequate artifacts in the governing collection (§01 §12.1) assert incompatible predicates at the same domain aspect, a governing-conflict gap (§01 §12.4) is admitted as an additional locus — distinct from cross-artifact-consistency (which is traversal-time detection of inconsistency) in that the governing-conflict locus identifies a registered, governed condition between artifacts that are each sound on their own terms and requires a resolution procedure rather than a reinforcement act. The gap is routed for reinforcement of the corresponding artifact — filling the gap reinforces the system and enables a grounded verdict on re-analysis. A gap referral is not a failure. It is an explicit, recomputable statement of the analysis boundary. Issuing an unsupported verdict in place of a gap referral is a conformance defect.
Outputs produced by this layer (the analysis output specification, §1):
| Output | Description |
|---|---|
| Verdict | Typed value: {conforming, non-conforming, conditionally-conforming}; derived from the aggregate of all battery-method outputs across all pipeline stages including pre-invocation signal inputs; where conditionally-conforming, a conditions record is co-required |
| Multi-stage witness chain | The ordered sequence of stage witness links spanning pre-invocation signal links, raw input, each IR stage, each analysis act, and the verdict; each link carries its stage identity, transformation or signal identity, order-type coverage, witness class (for pre-invocation links), stage content hash, and prior-stage link hash |
| Recomputation witness | Full record enabling independent re-derivation: the multi-stage witness chain plus the replay record, justification record, or both at the terminal stage |
| Typed gap referrals | Typed by locus: {domain model, governing specification, data source, knowledge base, pre-invocation signal, higher-order-analysis, cross-artifact-consistency, governing-conflict} — routing for reinforcement in lieu of unsupported verdicts; traversal-surfaced gaps (higher-order-analysis, cross-artifact-consistency) carry the traversal witness hash and the aspect identifiers binding the gap to the traversal act that surfaced it; governing-conflict gaps carry the two-artifact locus, conflict aspect, and resolution procedure reference per §01 §12.4 |
| Analysis battery record | The primary interface artifact between this layer and §02b. Minimum required fields specified below. |
| Declared-irreducible entries | For each element that could not be fully resolved to a discrete form: irreducibility basis, best-available representation, and scope impact; feeds the declared-scope invariant (Field 5) |
| Bounded-analysis record (when applicable) | Issued in lieu of a certificate when the entire analysis question is irreducible; carries the full required field set (§02b §3); registered in the specification registry; consumed by downstream gates as a non-passing result |
| Composed discrete program (optional) | Order-governed, audit-bound composition of two or more composable programs or expressions — each a discrete representation or derived therefrom — into one executable program constituting a composition of one or more orders and higher-order orders. The composed program is reusable without limitation and infrastructure-agnostic: it may be consumed by any downstream use without re-derivation and without dependence on any particular infrastructure. Where no governing specification is provided, the composed program may itself serve as or be used to compose a first-class governing specification, bound to and recomputable from its source artifacts. Full specification: §02d. |
Analysis battery record — minimum required fields. The analysis battery record is the primary interface artifact between this layer and §02b. Its canonical schema is declared in schemas/analysis-battery-record.json. Minimum required fields:
| Field | Content | Required when |
|---|---|---|
| Record identity | Stable content-addressed identifier for this record; used by conformance certificate Field 3 evidence references and Field 7 recomputation witness references | Always |
| Artifact identity | Content-addressed identity of the artifact analyzed in this battery run | Always |
| Governing-specification version identity | Content-addressed registry identity of the governing specification version under which this battery ran; must match conformance certificate Field 2 | Always |
| Analysis-specification version identity | Content-addressed registry identity of the analysis specification version that declared the pass set | Always |
| Source-registration version identity | The pre-invocation signal source registration record version in effect at analysis time; a scope-breaking update to the source registration cascades revocation of certificates issued under batteries carrying the prior version (inspector property G8) | Always |
| Method entries | One entry per battery method invoked; each entry carries: method_entry_id (resolution target for Field 3 evidence references), battery_method_identity (§3 battery method table entry), layer (pre-IR / IR-level / post-IR), orders_acted_upon (list of order identities; structurally deficient if absent per B2), method_family (deterministic / probabilistic; governs corroboration eligibility per §4), output_content_hash (must match the hash in Field 3 evidence references, per G7), and pass_record_ref (audit chain pointer per §3a.1) |
Always; at least one entry required |
| Pre-invocation signal entries | One entry per registered pre-invocation signal source that contributed; each carries: source identity, source registration version, signal value, witness class (W1/W2/W3), order-type assignments, and absence posture where the source produced no signal | When any pre-invocation signal source is registered for this deployment |
| Corroboration signal | Per-pair signals (one per deterministic × probabilistic method pair evaluating the same conformance question), each order-typed; aggregation function identity and parameters (required when more than one per-pair signal is present, per G3); composite divergence contribution; an analysis battery record reporting a composite contribution without declaring the aggregation function does not satisfy the independent-re-derivability requirement of Field 7 | When both deterministic and probabilistic method families are present |
| Cross-phase corroboration | Pre-invocation source identity, probabilistic method entry reference, orders evaluated, agreement boolean, divergence measure, and label pre-invocation-cross-phase; contributes to the verdict and confidence on the same basis as within-battery corroboration |
When a deterministic pre-invocation signal and a probabilistic battery method evaluated the same conformance question (inspector property S13) |
| Aggregate verdict basis | The multiset of (pass_record_ref, passed, has_falsifier) tuples from which the mechanical tri-state status was derived (§3a.2); the determined status (CERTIFY / REFUSE / REFER); status reason (for REFUSE/REFER); pipeline-termination flag and terminating gate (for AR-gate or PV-gate termination) |
Always |
| Record content hash | Tamper-evident binding over all fields | Always |
These outputs are the inputs to §02b (certification and attestation). The conformance certificate satisfying the nine structural invariants is produced by §02b from the verdict and recomputation witness produced here.
← Reverse-composition · Section index · Externally-observable properties →