§02a Jupiter — Base Analysis — Symbolic lift and order-typed representation
Mars® Spec › §02a Jupiter — Base Analysis › Symbolic lift and order-typed representation
← The divergence signal · Section index · Reverse-composition →
5. Symbolic lift and order-typed representation
The symbolic lift. Where the artifact or its governing material is linguistic, the system lifts language into a deterministically-provable symbolic or mathematical form. This lift is governed by the order-decomposition: the orders and perspectives determine which symbols, predicates, and structure the lifted form contains. The lifted form is bound back to its source by a recomputation witness from which an independent inspector can re-derive the lifted form and any verdict computed over it.
Bare conversion of rules or language to a logical or mathematical model is prior art. The inventive conjunction is: (a) the order-decomposition determines what the symbols, predicates, and structure represent; (b) the lift is bound back to the source for audit; (c) the lifted form yields a verdict computable by deterministic symbolic methods; (d) the recomputation witness makes the full derivation independently re-derivable.
The recomputation witness. A recomputation witness is one or both of: (i) a replay record — the recorded inputs, formation method, and parameters or version, such that re-performing the formation reproduces the representation; and (ii) a justification record — a record of which source elements, under which orders, yielded which symbols, predicates, variables, relations, states, factors, or structure, establishing that the representation is grounded in and traceable to its source without requiring bit-identical reproduction. Where formation is deterministic, the replay record suffices. Where formation employs an interpretive or non-deterministic method (§5, formation-method independence), the justification record suffices. Either or both may be produced; either alone satisfies the witness obligation. A third witness kind is admitted between the two: the reproducibility record — k independent formations under recorded sampling parameters with a declared aggregation rule (majority vote or declared equivalent), the record carrying the k outputs’ content hashes, the aggregation rule, and a measured stability rate, and, where a calibration set is declared, a distribution-free fidelity bound on the formation (ε, δ, exchangeability scope). The reproducibility record makes a stochastic formation auditable by measurement; it satisfies the witness obligation for a non-deterministic formation on the same terms as the justification record.
The recomputation witness extends beyond formation to use: a traversal, lookup, evaluation, or analysis performed over the order-governed structure is itself verifiable — the path taken through the knowledge is re-derivable, not only the knowledge’s origin. The independent inspector is a capability, not a dependency: re-derivability is a property the artifact carries whether or not any inspection ever occurs. No inspector or act of inspection is a required step of the analysis.
The discrete-representation genus. The symbolic lift is a species of the broader discrete-representation genus, specialized to linguistic input, symbolic or mathematical output, and a verdict computed over it. The genus covers representations that are one or more of: symbolic or mathematical; boolean; constraint; graph or relational; automaton or state-machine; probabilistic-graphical.
Formation is governed by the order-decomposition such that each representation element represents one or more orders. The order-shape contract is the mechanism: each order is specified by an order-shape specification; all members of an order share the order’s structural shape; that shape is functional — the shape carries the order’s behavior discipline. The representation kind (symbolic, boolean, constraint, etc.) is the carrier realizing the order shape. Output structure is invariant across representation kinds because structure follows order shape, not representation kind.
Order-shape contract satisfaction. The necessary and sufficient conditions are: (i) input content partitioned into disjoint owner-sets, each governed by a single order; (ii) structural uniformity within each owner-set enforced by the order’s shape prior to any analysis; (iii) the recomputation witness binds each output element to its governing order. A formation process that does not enforce these three conditions on the intermediate representation — regardless of output structural similarity — does not practice the discrete-representation genus.
Order-shape contract gate condition. A formation output that does not satisfy all three order-shape contract conditions — partitioned owner-sets, structural uniformity within each owner-set, and recomputation witness binding to governing orders — is not a conforming discrete representation and is refused at gate evaluation. A formation process that produces output with order-structured appearance but fails any of the three conditions is not practicing a different architecture; it is a non-conforming implementation of this one. Gate refusal produces a typed non-conformance record identifying: the formation output identity, the condition(s) that failed, and the timestamp. No downstream analysis gate admits a discrete representation that lacks a conformance record from this evaluation.
Formation-method independence. Formation may employ any method, including natural-language processing, a language model, semantic analysis, or any other interpretive or non-deterministic method. What is specified is the order-governed, witness-bound result, not the formation mechanics. A non-deterministic formation is bound by the justification record.
Data-source-alone formation. Where inputs include a data source alone, formation proceeds by semantic analysis of tables, collections, or schemas and by data sampling. Three regimes (usable in combination): (a) the order-decomposition serves as the map — the data source’s schema, keys, and constraints supply content instantiating the orders; (b) a minimal domain model is first derived from the data source, then serves as the map; (c) emergent regime — where semantic analysis is not possible or the domain is unknown, order-typed structure is promoted from patterns observed over the data. In each regime the instantiated representation is order-typed and witness-bound.
Governing-specification precedence over override layer. The governing specification takes strict precedence over the specification override layer for conformance determination. The override layer governs representation formation and is subordinate to the governing specification in analysis. Where an override conflicts with a conformance predicate in the governing specification, the conflict is recorded in Field 6 (falsifier annotations) and the verdict reflects the governing specification’s requirements. Suppression of governing-specification constraints via the override layer without recording the conflict as a falsifier annotation is prohibited.
5a. Intermediate representations, multi-stage pipelines, and symbolic execution
The path from raw input to analysis-ready discrete form is rarely a single transformation. In practice — and across the full range of input modalities this specification admits — it passes through one or more intermediate forms: a semantic parse, a probabilistic graph, a partially-typed structure, a neural encoding sharpened into symbolic predicates, or a lifted IR suitable for path-level analysis. This section specifies: (§5a.1) the structural requirements on intermediate representations as first-class artifacts; (§5a.2) the multi-stage witness chain that spans them; (§5a.3) the convergence criterion governing promotion from probabilistic to discrete form; (§5a.4) irreducibly probabilistic cases and the bounded-analysis record; and (§5a.5) symbolic execution — a battery method that operates over a fully order-typed IR to produce path-level analysis outputs. The mechanism of each transformation is not specified; formation-method independence (§5) applies at every stage.
5a.1 The intermediate representation as a first-class artifact
An intermediate representation (IR) is any order-typed artifact that exists between the raw input and the final analysis-ready discrete form. An IR is not an implementation detail internal to a formation procedure — it is a first-class artifact subject to the same structural requirements as the final form, with two adaptations for the partially-resolved state.
Partial order-typing is permitted at the IR level. An IR element may carry one of three type states:
| Type state | Meaning |
|---|---|
| Fully order-typed | The element has been assigned to a single order; its order-shape contract is satisfied; it may be consumed by any battery method that requires a typed input |
| Provisionally typed | The element has been assigned a candidate order but the assignment is pending disambiguation; it carries the candidate order tag and a disambiguation record identifying what must be resolved and by what authority or method |
| Untyped-pending | The element has not yet been assigned to any order; it is present in the IR as a candidate element awaiting order-assignment; it may not be consumed by analysis methods until it reaches at least provisional type state |
An IR in which all elements are fully order-typed is analysis-ready. An IR in which any elements are provisionally typed or untyped-pending is a staging form; it must reach full order-typing before final analysis proceeds, or its partial coverage must be declared in the scope invariant (Field 5) and the witness.
The order-shape contract applies at each IR stage. Structural uniformity within each order’s owner-set is enforced at the IR level, not deferred to the final form. An IR that groups elements by order but does not enforce the order’s shape specification within each group does not satisfy the order-shape contract at that stage. The contract is stage-local: each IR stage must independently satisfy it for the elements it has typed.
IR identity and versioning. Each IR stage carries: an IR identity (a stable identifier for this stage’s structure and schema), the transformation identity that produced it from the prior stage, the type-state distribution (counts of fully-typed, provisionally typed, and untyped-pending elements), and a content hash. These fields are the minimum required for a witness link at this stage.
5a.2 The multi-stage witness chain
The recomputation witness for a multi-stage pipeline is a chain, not a single binding. Each stage in the pipeline contributes one link to the chain. The chain runs from the raw input through every IR to the final discrete form and then through each analysis act to the verdict.
Each witness link satisfies its witness obligation via the replay record, the justification record, or both (§5, recomputation witness). A deterministic stage satisfies the obligation via a replay record; an interpretive or non-deterministic stage satisfies it via a justification record. A link that is neither replayable nor contains a justification record does not satisfy the witness obligation for that stage.
Minimum required fields per witness link:
| Field | Content |
|---|---|
| Stage identity | The IR identity and version of the artifact produced at this stage |
| Transformation identity | The identity, version, and declared parameters of the transformation applied to produce this stage from the prior stage |
| Witness kind | replay (deterministic stage — re-performance of the transformation with the recorded inputs and parameters reproduces this stage’s artifact) or justification (interpretive/non-deterministic stage — source elements, orders, and structure derivation recorded) or both |
| Order-type coverage | The type-state distribution at this stage: counts and identifiers of fully-typed, provisionally-typed, and untyped-pending elements |
| Disambiguation records | For each provisionally-typed element: the candidate order tag, the disambiguation method declared, and the resolution outcome (resolved / deferred to next stage / declared-irreducible) |
| Stage content hash | Tamper-evident binding over the IR artifact at this stage |
| Prior-stage link hash | The content hash of the prior stage’s witness link, forming the chain |
A pipeline that discards intermediate forms after the final form is produced does not satisfy the witness chain requirement. The IR artifacts must be retained — or their hashes must be retained and the artifacts reconstructable from the transformation record — for the chain to be independently re-derivable.
Chain termination. The chain terminates when the final discrete form is reached (all elements fully order-typed and analysis-ready) or when a declared-irreducible state is recorded (§5a.4). A chain that terminates without either condition is incomplete and does not support issuance of the grounded-verdict invariant (Field 4).
Traversal witness links. Where traversal acts (§4b) are performed during analysis, each traversal act contributes a traversal witness link to the chain, positioned between the IR stage links and the analysis act links:
[IR stage links] → [traversal witness link(s)] → [analysis act links] → [verdict link]Each traversal witness link carries the minimum fields specified in §4b.4. Where multiple traversal acts occur in sequence or in parallel, each contributes its own link; parallel traversal links share the same prior-stage link hash from the IR stage they were initiated from. A traversal act whose witness is absent from the chain does not satisfy the recomputation requirement for any analysis act performed over its outputs.
Pre-invocation signal links. Where registered pre-invocation signals (§02e) are present, the chain is extended:
[pre-invocation signal link(s)] → [raw input link] → [IR stage links] → [traversal witness link(s)] → [analysis act links] → [verdict link]Each pre-invocation signal link carries: source identity, signal value, order-type assignments, witness class, witness record (appropriate to the class), and the content hash of the signal element(s) it covers. The chain’s first link is the earliest pre-invocation signal; the chain terminates at the verdict. Where multiple pre-invocation signals are present, each contributes its own link at the pre-invocation segment of the chain. The links are ordered by signal timestamp; where two signals share a timestamp, ordering is by source registration priority declared at deployment.
5a.3 The probabilistic-to-discrete convergence criterion
Where a probabilistic or learned operation produces an IR — a neural encoding, an embedding-space representation, a probabilistic graph, a classifier output distribution — that IR is not yet a discrete form. Proceeding to analysis without a convergence criterion means the grounded-verdict invariant is derived from a form whose resolution state is undefined.
Convergence is declared, not assumed. The operator declares, at deployment registration, the convergence criterion that governs when a probabilistic IR is treated as sufficiently resolved to be used as a discrete form for analysis. The criterion is a typed declaration: a threshold on a declared measure (confidence score, entropy, posterior probability mass, inter-model agreement, or any other declared measure) above which the element is treated as resolved and below which it is treated as unresolved.
Unresolved elements at convergence evaluation. At the convergence evaluation point, each element of the probabilistic IR is evaluated against the declared criterion:
- Resolved — the element meets the convergence criterion; it is promoted to a fully order-typed element in the next-stage IR, carrying the winning type assignment and a convergence record
- Unresolved — the element does not meet the convergence criterion; it is carried forward as a provisionally-typed element with the convergence measure recorded, or escalated to the disambiguation authority declared for this stage
Convergence record. Each resolved element carries a convergence record in the witness link for that stage:
| Field | Content |
|---|---|
| Convergence criterion identity | The declared measure and threshold used |
| Measured value | The value of the declared measure for this element at this stage |
| Resolution outcome | resolved with the winning type assignment, or escalated with the escalation authority |
| Mechanism record | The probabilistic or learned mechanism that produced the measure |
The convergence criterion is a scope condition. The declared convergence criterion and threshold are carried in the scope invariant (Field 5) of the certificate. A downstream consumer that operates the certified artifact under a different convergence posture is operating outside the certified scope.
Probabilistic-only pipeline conformance. A pipeline that operates exclusively through probabilistic or statistical methods — never producing a fully discrete form — is a conforming deployment provided: (a) the probabilistic IR satisfies the order-typing and witness requirements at each stage (§5a.1, §5a.2); (b) a convergence criterion is declared and applied (§5a.3); and (c) the scope invariant (Field 5) declares the probabilistic posture and the convergence criterion governing it. Such a pipeline need not reach a fully discrete final form to issue a grounded verdict — it may issue a verdict over a fully order-typed probabilistic IR that has met the declared convergence criterion, with the convergence criterion declared as a scope condition. A pipeline that produces probabilistic outputs without declaring a convergence criterion and recording it in Field 5 is not a conforming probabilistic-only pipeline; it is operating outside declared scope. A purely probabilistic or statistical analysis framework — including Bayesian networks, probabilistic graphical models, statistical hypothesis testing, or any other declared probabilistic discipline — that satisfies conditions (a), (b), and (c) does not require any symbolic lift or formal IR to conform; the convergence criterion is the mechanism by which probabilistic resolution is made recomputable and scope-declarable.
5a.4 Irreducibly probabilistic cases
There are analysis questions for which full reduction to a discrete form is not achievable: domains where the ground truth is inherently stochastic, inputs whose ambiguity cannot be resolved without external authority that is unavailable at analysis time, or analysis questions that are formally undecidable over the governing IR.
Declared-irreducible status. Where the pipeline determines that full discrete resolution is not achievable for one or more elements, it records a declared-irreducible entry for each such element. A declared-irreducible entry is not a failure — it is an explicit, recomputable statement of the analysis boundary. It carries:
| Field | Content |
|---|---|
| Element identity | The IR element identity and order-tag state at the point of irreducibility declaration |
| Irreducibility basis | The basis for the declaration: stochastic-ground-truth (the domain is inherently probabilistic), authority-unavailable (disambiguation requires an authority that is not reachable), formally-undecidable (the question is undecidable over the governing IR and governing specification), or coverage-bounded (symbolic execution coverage was bounded before this element’s paths were exhausted — see §5a.5) |
| Best-available representation | The probabilistic or partially-resolved form that is the best achievable representation; this is carried in the IR as the element’s value, typed as irreducible |
| Scope impact | Whether this irreducibility narrows the declared scope of the verdict; if so, the narrowed scope expression |
Verdict under partial irreducibility. A verdict derived from an analysis that includes declared-irreducible elements is valid — it is a grounded verdict over the resolved portion. It must declare its scope narrowly: the grounded-verdict invariant (Field 4) carries the verdict; the declared-scope invariant (Field 5) carries the coverage expression that identifies which elements were fully resolved and which were declared-irreducible. A consumer of the certificate can determine exactly which portions of the analysis are fully grounded and which are bounded by irreducibility declarations.
Full irreducibility. Where the entire analysis question is irreducible — no element reaches discrete resolution — the pipeline may not issue a grounded verdict. It issues instead a bounded-analysis record: the declared-irreducible entries, the best-available probabilistic representation, and a typed gap referral to the authority or process required to resolve the irreducibility. A bounded-analysis record is not a certificate; it does not satisfy the grounded-verdict invariant.
Bounded-analysis record field structure. A bounded-analysis record is a first-class output artifact. Its required field set is defined canonically in §02b §3 and is not restated here: that field set carries the record identity, the target and governing-specification identities, the irreducibility basis, the declared-irreducible entries specified above, the best-available aggregate representation, the analysis-effort record, the typed gap referral, the witness chain and temporal window, and the authority attestation with tamper-evident binding. The declared-irreducible entry structure defined in this section is the content of that field set’s declared-irreducible-entries field.
Registry and consumption. A bounded-analysis record is registered in the specification registry under its record identity. Downstream gates that encounter a bounded-analysis record in place of a certificate must treat it as a non-passing result — the grounded-verdict invariant is not satisfied. The typed gap referral in the record is the routing signal for the reinforcement mechanism: it routes to the appropriate resolution authority or process. A bounded-analysis record does not expire in the same sense as a certificate (it has no grounded verdict to re-attest); its issuance timestamp and tamper-evident binding establish when it was produced and that it has not been altered.
5a.5 Symbolic execution over the IR
Symbolic execution operates over an order-typed IR, not over raw input and not over a probabilistic form. Its precondition is an IR in which all elements relevant to the analysis question are fully order-typed (§5a.1). Where the IR contains provisionally-typed or untyped-pending elements in the analysis-relevant region, symbolic execution may not proceed over those elements until they are resolved.
What symbolic execution produces. For each execution path explored, symbolic execution produces:
- A path condition record — the conjunction of constraints that must hold for this path to be taken, expressed over the order-typed elements of the IR
- A symbolic state record — the values of analysis-relevant IR elements at each program point along the path, expressed as symbolic expressions over the order-typed structure
- A path verdict — the conformance verdict for this path against the governing specification’s path-level conditions
The path condition records, symbolic state records, and path verdicts are the analysis outputs of symbolic execution. They are consumed by the analysis battery to produce the aggregate verdict.
Path-exploration strategy and bounding. Symbolic execution over any non-trivial IR is necessarily partial — full path enumeration is in general infeasible. The operator declares a path-exploration strategy at deployment registration:
| Strategy | Description |
|---|---|
| Depth-bounded | Exploration proceeds to a declared maximum path depth; paths beyond that depth are recorded as coverage-bounded declared-irreducible entries |
| Coverage-criterion | Exploration proceeds until a declared coverage criterion is met (e.g., all order-typed element types exercised, all governing-specification predicates activated at least once) |
| Oracle-guided | Exploration is guided by an oracle (a model, a heuristic, or a domain expert) that prioritizes paths by declared relevance to the analysis question |
| Exhaustive | Full path enumeration; only valid for finite, bounded IRs where termination is guaranteed |
The declared path-exploration strategy and its parameters are carried in the scope invariant (Field 5). Paths not explored under the declared strategy are recorded as coverage-bounded declared-irreducible entries (§5a.4) in the witness chain for the symbolic execution stage.
Coverage record. The symbolic execution stage produces a coverage record that is a required witness link field:
| Field | Content |
|---|---|
| Strategy identity | The declared path-exploration strategy and its parameters |
| Paths explored | Count and identifiers of paths fully explored |
| Paths bounded | Count and identifiers of paths not explored due to strategy bounding; each recorded as a coverage-bounded declared-irreducible entry |
| Governing-specification predicate coverage | For each predicate in the governing specification relevant to this analysis: whether it was activated, partially activated, or not reached during exploration |
| Aggregate path verdict | The verdict derived from the explored path set: conforming (all explored paths conform), non-conforming (at least one explored path does not conform), or conditionally-conforming (conformance holds under the explored paths subject to the coverage bound declared in Field 5) |
Relationship to the discrete-representation genus. Symbolic execution is a battery method (§3) that operates at the IR level — it is an IR-level method, not a pre-IR or post-IR method. Its outputs (path condition records, symbolic state records, path verdicts) are order-typed artifacts that feed the aggregate verdict. They satisfy the order-shape contract: each symbolic expression is owned by the order whose element it ranges over. The coverage record is a stage witness link that chains to the final verdict witness.
5a.6 Calibration attestation gate
Purpose
The calibration attestation gate is a first-class mechanism that evaluates whether operator-declared thresholds and functions are producing results consistent with the certified benchmark derived from the external canonical knowledge base and the governing domain model. It does not replace operator declaration — operators still declare convergence criteria, aggregation functions, classification functions, and divergence thresholds in the deployment manifest (§02b §6). It is an independent, autonomous check on whether those declarations are producing well-calibrated behavior, grounded in an external certified artifact the operator cannot configure away.
The operator-trust problem this gate closes. Where operator-declared thresholds or functions are miscalibrated — through negligence or intent — the downstream verification machinery executes faithfully against a corrupted foundation. Certificates appear conforming. The audit trail appears clean. The inspector sees no structural violation. The gate closes this by providing a certified external ground truth against which the declared functions are evaluated autonomously, with the result affecting the certificate’s scope and falsifier record.
Benchmark artifact
The benchmark artifact is derived from:
-
The attested KB variant consistency map (§03-ii §3.1a) — the primary source. Per-pair entries with attested correspondence types, external canonical ground truth (corpus source spans), and mechanism scores provide test cases for convergence criterion calibration, relational quantification calibration, and aggregation function calibration.
-
The governing domain model’s triage, traversal, and conclusion structure — triage test cases (inputs that should and should not trigger escalation), traversal test cases (paths that should be explored under correct configuration), and conclusion test cases (verdicts that should be produced over known-correct inputs). These are derived from the domain model’s order-decomposition tree, aspect definitions, and admissibility relation.
Benchmark derivation procedure. The system derives benchmark cases automatically from these two sources. Derivation is governed by the domain model: aspect-typed primitives from the KB variant consistency map become convergence-criterion test cases; per-pair entries with attested correspondence types become relational quantification test cases; domain model traversal paths with declared conclusions become traversal and conclusion test cases. The derivation act is itself order-typed and carries a derivation provenance record.
Benchmark attestation. The derived benchmark case set is attested by a named human authority with domain standing, applying the faithfulness-attestation procedure (§01 §8): a declared inter-rater agreement statistic fit for the measurement scale and rater count of the attestation act is computed over the per-case correctness ratings against a pre-declared threshold registered in the specification registry. A statistic value below the registered threshold is a gate failure on the attestation act; no attested benchmark is emitted for the affected case set until the agreement threshold is met. No operator override of a threshold breach is permitted. The declared statistic must satisfy the five agreement-statistic properties (§01 §8): scale-appropriate, rater-count-appropriate, chance-corrected, independently recomputable, and threshold-bound.
Benchmark registration. The attested benchmark is a first-class registered artifact in the specification registry, enrolled in the delta-attestation lifecycle (§02b §5). Its fields:
| Field | Content |
|---|---|
| Benchmark identity | Stable content-derived identifier |
| Version | Enrolled in the delta-attestation lifecycle |
| Governing specification version | The governing specification version under which this benchmark was derived |
| KB variant consistency map version | The attested KB variant consistency map version (§03-ii §3.1a) from which KB-derived test cases were sourced |
| Domain model version | The domain model version from which triage/traversal/conclusion test cases were derived |
| Case set | The typed set of benchmark cases, each carrying: case identity, source (KB-derived or domain-model-derived), input, attested expected output, variation axis (where KB-derived), and derivation provenance record |
| Attestation record | Named authority identity, domain standing declaration, declared inter-rater agreement statistic identity, computed statistic value, declared threshold, registry identity of both statistic and threshold, and attestation timestamp |
| Tamper-evident binding | EUF-CMA-secure signature over all fields |
A scope-breaking amendment to the governing specification version, KB variant consistency map version, or domain model version cascades re-attestation of the benchmark. A re-attestation obligation is not waivable; a deployment operating under a benchmark whose version binding has been superseded without re-attestation carries a stale-benchmark falsifier annotation in Field 6.
What the gate checks
The gate evaluates four classes of operator-declared functions against the benchmark case set:
Class 1 — Convergence criterion. For each KB-derived benchmark case carrying an attested correspondence type of equivalent: the declared convergence criterion is applied to the probabilistic measure value recorded in the per-pair entry’s mechanism scores. A conforming convergence criterion resolves equivalent pairs as resolved at or above the declared threshold. A criterion that resolves equivalent pairs as unresolved at a rate exceeding a declared tolerance is miscalibrated for that pair class.
Class 2 — Aggregation function. For each benchmark case carrying an attested divergence expectation (pairs declared equivalent should produce low divergence; pairs declared conflict should produce high divergence): the declared aggregation function is applied to the per-pair mechanism scores. A conforming aggregation function produces divergence signals consistent with the attested expectations within the declared tolerance.
Class 3 — Classification function. For each benchmark case carrying an attested amendment classification (scope-breaking, scope-restricting, scope-extending, or scope-preserving): the declared classification function is applied to the structural-difference record of the amendment. A conforming classification function produces the attested classification. A function that under-classifies (returns scope-preserving for an attested scope-breaking case) is miscalibrated and is a structural floor violation independent of this gate.
Class 4 — Divergence threshold. For each benchmark case carrying an attested gap-referral expectation (the case is one where correct behavior is gap referral): the declared divergence threshold is applied. A conforming threshold triggers gap referral for attested gap-referral cases. A threshold set so high that it suppresses gap referrals on attested referral-warranted cases is miscalibrated.
Calibration record
The gate produces a typed calibration record for each evaluation run. The calibration record is a first-class registered artifact:
| Field | Content |
|---|---|
| Calibration record identity | Stable content-derived identifier |
| Benchmark version | The benchmark artifact version used |
| Deployment manifest version | The manifest version whose declared functions were evaluated |
| Evaluation timestamp | When the gate ran |
| Per-class verdict | For each of the four classes: calibrated (declared function produces results consistent with attested expectations within declared tolerance), miscalibrated (declared function produces results inconsistent with attested expectations beyond declared tolerance), or inconclusive (insufficient benchmark cases for this class, or pending-re-attestation entries excluded from the case set) |
| Miscalibration detail | For each miscalibrated class: the case identities on which the function failed, the declared value, the attested expected value, and the deviation measure |
| Tamper-evident binding | EUF-CMA-secure signature over all fields |
Autonomy model
Base case — full autonomous. The calibration attestation gate runs autonomously without operator initiation. It runs: (a) at deployment registration, as a precondition of admission; (b) on any scope-breaking or scope-restricting amendment to the deployment manifest that changes a declared function or threshold; (c) on any re-attestation of the benchmark artifact. Autonomous runs produce calibration records registered in the specification registry.
Not suppressible. A deployment configuration that disables or bypasses calibration gate runs is refused at deployment registration. The gate is not an optional feature; it is a structural admission precondition. A manifest sub-record declaring calibration suppression is a non-conforming sub-record refused at registration with a typed diagnostic.
Effect on the certificate. The calibration record affects the certificate as follows:
- All classes calibrated: no effect on the certificate beyond the standard calibration record reference in Field 5 (scope invariant).
- Any class miscalibrated: the miscalibrated class’s scope is narrowed in Field 5 — the certificate’s declared scope excludes cases in the miscalibrated range, with the exclusion expressed as a typed scope restriction referencing the calibration record. A falsifier annotation is added to Field 6: if the miscalibration is not resolved within the declared re-calibration window, the certificate is invalidated. The re-calibration window is declared in the deployment manifest runtime configuration record (§02b §6.5).
- Inconclusive for any class: the certificate carries an inconclusive-calibration annotation for that class in Field 5. Inconclusive is not a miscalibration finding; it does not narrow scope or add a falsifier. It does record that calibration coverage for that class was limited.
Owner-configurable response. The system owner declares in the deployment manifest runtime configuration record (§02b §6.5) the calibration response mode:
| Mode | Behavior |
|---|---|
fail-closed |
A miscalibrated-class finding refuses certificate issuance until the miscalibration is resolved; no certificate is emitted with a narrowed scope under this mode |
flag-and-continue |
A miscalibrated-class finding narrows scope and adds a falsifier annotation but does not refuse issuance; the certificate is emitted with the narrowed scope |
The default, where calibration response mode is not declared, is flag-and-continue. Both modes are conforming. The fail-closed mode provides stronger protection against operator-miscalibrated deployments; the flag-and-continue mode allows production to continue with a traceable, inspector-visible miscalibration record. A deployment that suppresses the calibration record from the certificate — whether under fail-closed or flag-and-continue — is non-conforming.
Re-calibration
When a miscalibration finding is present, the operator resolves it by amending the relevant declared function or threshold in the deployment manifest. The amendment is subject to the manifest amendment lifecycle (§02b §6.6): a change to a declared function is a scope-breaking amendment producing immediate cascade. After amendment and re-registration, the calibration attestation gate runs automatically against the new manifest version. A calibration record showing all-classes-calibrated under the new manifest version resolves the falsifier annotation from certificates issued under the prior manifest version that were emitted under flag-and-continue mode.
Observable properties
| Property | Observable condition |
|---|---|
| CA1 — Gate runs at deployment registration | Every deployment registration includes a calibration record in the specification registry; a deployment with no calibration record is refused at registration with a typed diagnostic |
| CA2 — Benchmark is a certified registered artifact | The benchmark artifact version referenced by the calibration record is present in the specification registry with a valid attestation record; a calibration record referencing an unregistered or unattested benchmark is non-conforming |
| CA3 — Miscalibration narrows Field 5 | A certificate issued under a manifest with a miscalibrated class carries a typed scope restriction in Field 5 referencing the calibration record identity; an inspector reproduces the scope restriction by retrieving the calibration record |
| CA4 — Miscalibration falsifier present in Field 6 | A certificate with a miscalibrated-class finding carries a falsifier annotation in Field 6 with a declared re-calibration window; the falsifier fires if the window expires without a resolved calibration record under an amended manifest version |
| CA5 — Gate not suppressible | Submitting a deployment configuration that disables calibration gate runs, or a manifest sub-record declaring calibration suppression, is refused at deployment registration with a typed structural diagnostic |
| CA6 — Autonomous re-run on amendment | A scope-breaking amendment to the deployment manifest that changes a declared function produces an automatic calibration gate re-run; the new calibration record is registered before the amended manifest version takes effect |
| CA7 — Benchmark version binding enforced | A calibration record produced under a benchmark version whose governing specification, KB variant consistency map, or domain model version binding has been superseded produces a stale-benchmark finding; the certificate carries a stale-benchmark falsifier annotation in Field 6 |
| CA8 — Calibration response mode declared | The deployment manifest runtime configuration record carries a calibration response mode declaration; an inspector confirms the certificate issuance behavior matches the declared mode |
← The divergence signal · Section index · Reverse-composition →