§03-iii Minerva — Evidence Gathering — The conformance certificate
Mars® Spec › §03-iii Minerva — Evidence Gathering › The conformance certificate
← Evidence-gathering verification · Section index · Outputs →
3. The conformance certificate
3.1 Certificate and witness as distinct objects
The conformance certificate (defined by nine structural invariants in §02b §2) and the recomputation witness (§2.7) are distinct objects that compose.
The recomputation witness is the record of the evidence-gathering traversal — traversal trace, evidence record, uncertainty-reduction record — produced by the evidence-gathering verification operation. It is the primary output of that operation.
The conformance certificate is produced by the conformance-certification operation. Certificate Field 7 is the recomputation witness field. In the evidence-gathering composition, this field is populated by — or references — the recomputation witness, carrying it into the certificate and making it available to any downstream recipient.
A standalone grounded verdict is also a valid delivery form. The certificate is one embodiment, not the only one.
3.2 Certificate invariants
The conformance certificate is fully defined in §02b §2. The inventive matter is the co-presence of nine structural invariants — not a field count. A certificate carrying all nine invariants is conforming regardless of additional fields; a certificate omitting any one invariant is structurally deficient. The canonical realization assigns one invariant per field:
| Invariant | Canonical field | Content in this context |
|---|---|---|
| Target identity | 1 | Identity of the artifact being certified (non-linguistic analysis program, generated interpretation, or linguistic artifact of arbitrary provenance) |
| Governing-specification identity with bootstrap provenance | 2 | Identity and version of the governing specification, with bootstrap provenance (source-authority hash, attestation statistic, scope-certificate hash) |
| Certification-path record | 3 | The analysis pipeline and composition gate sequence used to reach the verdict |
| Grounded verdict | 4 | The conformance verdict: {conforming, non-conforming, conditionally-conforming} derived through evidence-gathering verification |
| Declared scope | 5 | The scope over which the verdict applies, bounded by the scope-of-applicability certificate |
| Falsifier record | 6 | Conditions under which the verdict would be falsified |
| Order-typed recomputation witness | 7 | The record from which an independent inspector re-derives the verdict; in the evidence-gathering composition: the three-invariant witness of §2.7 |
| Temporal validity window | 8 | The time window within which the verdict is valid |
| Tamper-evident cryptographic binding | 9 | Binding computed over all invariant fields of the certificate |
Certificate conformance requirement. Certificate novelty is concentrated in the grounded-verdict invariant (Field 4) and the order-typed recomputation witness invariant (Field 7). A conforming certificate must satisfy both of the following:
- Field 4 must contain a grounded conformance verdict derived through bounded exploration under a governing specification — one of {conforming, non-conforming, conditionally-conforming}. A certificate that populates Field 4 with an asserted verdict does not conform.
- Field 7 must contain or reference an order-typed recomputation witness satisfying the structural requirements of §3.4. A certificate that populates Field 7 with an untyped audit log or computation trace lacking per-step order-type tags does not conform.
Falsifier annotation format (Field 6). A falsifier annotation is a typed record with four fields:
| Sub-field | Content |
|---|---|
condition-type |
A value drawn from a registered taxonomy of condition types (licensee-declared values; the taxonomy itself is a registered artifact) |
condition-predicate |
An order-typed expression defining the condition that, if true, falsifies the verdict |
detection-method |
Identifies how the condition would be detected (inspection procedure, monitoring signal, or automated check) |
effective-date |
The date from which the annotation is in force |
3.3 Consumed by reference at a downstream gate
“Consumed by reference” means the downstream gate does not re-execute or re-derive the verification. It receives the certificate as an already-completed formal output and checks its validity, currency, and scope. The gate refuses to proceed in the absence of a valid, current certificate or standalone verdict.
The gate is any point in the pipeline at which the conformance of an artifact is a precondition for proceeding — for example, the actuation anchor of §02c §4, which accepts a certified verdict into its originating-verification-record identity field. The specific gate is determined by the licensee’s pipeline architecture. What the Mars® specification requires is that the certificate is consumed by reference and that the gate refuses absent a valid current certificate. It does not prescribe which step constitutes the gate.
3.4 Unified recomputation witness definition
The recomputation witness appears across all layers with a consistent meaning. Across layers:
| Layer | Witness content |
|---|---|
| §01 (modeling) | Record sufficient to re-derive the lowered artifact from its source: the well-typed expression and the order-shape specification version, together with the determinism of the lowering |
| §02a (base) | Record from which the inspector re-derives the conformance verdict: the analysis inputs, cited bounds, and derivation sufficient to reproduce the verdict |
| §02c (elevated / pre-invocation governance / AIGP witness retention) | Order-governed retained object: order-typed prompt, methods applied, cited bounds, derivation — sufficient to re-derive the admission or assessment decision; carries spec-version binding enabling drift re-binding |
| §03-iii (evidence-gathering) | Gathered evidence, traversal trace under guide, and uncertainty-reduction record, from which the grounded conformance verdict is re-derived |
Unified definition. A recomputation witness is a record sufficient for an inspector to independently re-derive the result from source under the governing orders, without access to the deployment or trust in the system. The essential components are: (i) the recorded inputs and the governing orders and specification version, plus (ii) the re-derivability of the result from those inputs. Tamper-evidence, signing, and cryptographic binding are hardening applied at the certificate layer; the witness’s sufficiency for independent re-derivation is the primary property.
Re-derivability defined. Re-derivability has two admitted forms depending on whether the producing operation is deterministic:
-
Deterministic operation. The result is re-derivable if an inspector, given the recorded inputs and governing orders, executing the same declared procedure, produces the identical result. Determinism is a sufficient condition for re-derivability; no further qualification is required.
-
Non-deterministic operation. The result is re-derivable if the evidence record contains direct, discrete evidence independently sufficient to reach the same result — evidence that is verifiable without re-executing the operation. The result’s re-derivability rests on the evidence record, not on replication of the operation’s path. The operation’s trace is retained as an audit record of how the evidence was found. Admitted forms of direct discrete evidence are specified in §2.7. A witness in which re-derivability depends solely on replicating a non-deterministic path does not conform.
The order-decomposition binding is the novelty. The witness records not just a computation trace but the order-typed structure that governed the computation. This enables an inspector to re-derive not only whether the result is correct but whether it was correctly governed by the declared orders.
Redaction with integrity — reconciling erasure rights with immutable evidence. Recomputation witnesses, generation environment capsules (§03-iv §2.8), and KB primitives retain evidence content — source spans, dynamic input records, returned values — under append-only, tamper-evident retention running to certificate lifetime plus the mandatory post-revocation tail. This retention collides with data-subject erasure rights (GDPR, CCPA, and equivalents), classified-data handling obligations, and row-level entitlements in federated sources. The collision is reconciled structurally, not by exempting governance artifacts from erasure and not by breaking the hash chain.
Every retained evidence value that may be subject to erasure or access restriction is committed by a salted content commitment: the evidence record and witness carry the commitment (a hash over the value and a per-value random salt) and, separately, the value-and-salt in a redactable evidence store. The commitment is what the hash chain and re-derivation bind to; the plaintext value lives only in the redactable store. Erasure deletes the value-and-salt from the redactable store and records a typed redaction event naming the erased commitment, the authority for the erasure, and the effective time; the commitment remains in the witness, the hash chain remains valid, and re-derivation over the redacted evidence yields a typed redacted-evidence result rather than a broken witness. An inspector re-deriving a verdict whose grounding evidence was subsequently redacted observes that the commitment is intact and the value is lawfully absent — the witness is provably complete-as-of-issuance and lawfully-redacted-thereafter, which is a distinct, conforming state, not a tampered one.
Witness access classification and entitlement-scoped traversal. Each evidence entry carries an access classification inherited from the source it was retrieved from; the classification propagates unstripped into the witness and the verdict, exactly as the lossy-provenance flag propagates (§01 §14 D24). An artifact or verdict derived from two or more entries of differing access classifications carries the most restrictive classification among its inputs; classifications are never widened downstream. An inspector’s ability to re-derive is scoped to the access classes they are entitled to: re-derivation over an entry above the inspector’s entitlement yields a typed entitlement-restricted result — the commitment and order-typing are verifiable, the plaintext is withheld — preserving the structural verifiability of the chain without disclosing restricted content. Traversal over federated sources executes each source’s queries under a declared entitlement scope: a traversal that retrieves from a source outside its declared entitlement scope is refused at the source boundary and recorded as a typed entitlement gap (locus data, subtype entitlement), not silently completed. An evidence record whose entries carry no access classification where their sources declare one is structurally incomplete.
Specification registry requirements. The specification registry — which stores governing specifications, perspective specifications, reinforcement-policy records, and related artifacts — must be content-addressable, append-only, and tamper-evident. Admitted embodiments include, non-exhaustively: a content-addressed distributed store, a cryptographic ledger, and a cryptographic transparency log. Any embodiment satisfying the three structural properties is admissible; deployment choice is at the licensee’s discretion. The three properties (content-addressable, append-only, tamper-evident) are required regardless of embodiment. Content-addressable means the artifact’s identifier is derived from the artifact’s content — for example, a cryptographic hash of the full artifact — such that any change to the content produces a different identifier; a registry that assigns identifiers by sequential counter or any scheme independent of content, even if accompanied by a hash annotation, is not content-addressable: the identifier does not carry the tamper-detection property, and two distinct artifacts could occupy the same address or the content at an address could be replaced without changing the identifier.
← Evidence-gathering verification · Section index · Outputs →