Skip to content
Mars® Protocol

§03-iii Minerva — Evidence Gathering — Evidence-gathering verification

Mars® Spec › §03-iii Minerva — Evidence Gathering › Evidence-gathering verification

← What this section covers · Section index · The conformance certificate →

2. Evidence-gathering verification

2.0 Canonical gap governance

A gap is any identified absence, insufficiency, ambiguity, or unresolvable inconsistency in any artifact governed by the Mars® specification — across all artifact types (model, knowledge base, data source, governing specification) and all gap loci (order, perspective, variant, data, domain-model, KB, specification, construction-conflict, governing-conflict). Regardless of gap type or locus, all gaps are governed by the same canonical state machine, authority contract, and record structure defined here. Artifact-specific sections specify what produces a gap and what resolves it; this section specifies how gaps are governed once identified.

Canonical gap states. Every gap occupies exactly one of four states at any point in time:

State Meaning
Open Gap has been identified and recorded; no resolution action is in progress
In-resolution A resolution action has been initiated under the declared authority procedure; the gap record is locked against concurrent amendment until the action completes or is withdrawn
Resolved The resolution action completed; a re-verification pass confirmed the gap is closed; the gap record is closed with a closure witness
Declared-permanent The gap cannot be filled within the scope of the current governing specification; declared permanently open by the designated authority procedure; its effect on certificate scope is recorded

Transitions between states are one-directional except that a gap may return from In-resolution to Open if the resolution action is withdrawn before completion. The transition from In-resolution to Resolved requires completion of the resolution action and a re-verification pass confirming the gap is closed; this transition operates under the authority procedure invoked at the Open-to-In-resolution transition, and the gap record’s transition history must record the authorization act identity and effective timestamp. A gap may not transition from Resolved or Declared-permanent without a new gap detection event. A new gap detection event on a Resolved gap returns it to Open. A new gap detection event on a Declared-permanent gap also returns it to Open; this transition is subject to the same authority procedure contract as the original Open-to-In-resolution transition and must be recorded in the gap’s transition history.

State refinement and the quotient rule. A deployment may refine the canonical states internally — for example, sub-states of In-resolution distinguishing triage, assignment, and verification stages, or priority and escalation annotations carried alongside the state — provided the refinement quotients onto the canonical four states: every internal state maps to exactly one canonical state; every internal transition maps to an enumerated canonical transition or to identity within one canonical state; and the blocking discipline (structural prohibition of use while the quotient state is Open or In-resolution), the authority procedure contract, and the closure-witness obligation attach to the canonical quotient, not to the internal refinement. A state machine that does not quotient onto the canonical four states — one whose additional states escape the blocking discipline or whose transitions bypass the authority contract — is non-conforming however many states it declares. The canonical machine is the quotient invariant of every conforming gap-governance implementation; adding states neither relaxes the blocking discipline nor exits the governance.

Authority procedure contract. The transition from Open to In-resolution, and from any state to Declared-permanent, requires action under a declared authority procedure. The authority procedure is a registered artifact enrolled in the delta-attestation lifecycle (§02b §5). It must be declared before any gap governed by it can transition. The form of the authority procedure is the licensee’s choice; admitted forms include but are not limited to:

Form Description
Administrative ticket The gap is issued as a ticket to a named administrative role or queue; the ticket’s resolution constitutes the authorization act
Autonomous analysis The gap is submitted to an analysis procedure that traverses the model, KB(s), and data source(s) to derive a resolution recommendation; the recommendation is eligible for flagging and human or automated verification before the transition is recorded
Operator rule set A declared set of rules governs delegated adjudication: gaps matching specified patterns are automatically transitioned by the rule set without per-gap human review; the rule set itself is a registered artifact subject to versioning and amendment
Third-party or architectural The gap is routed to a registered third-party service, governance body, or architectural mechanism (such as a consensus protocol or multi-party sign-off); the service’s decision constitutes the authorization act
Combination Any combination of the above, declared as a composite procedure in the registered authority procedure artifact

The contract requires that the authority procedure is: (a) declared and registered before use, (b) enrolled in the delta-attestation lifecycle so that changes to the procedure are versioned and auditable, and (c) its decision for each transition recorded in the gap’s transition record. The implementation is the licensee’s choice within these constraints.

Gap record structure. Every gap, regardless of type or locus, is represented as a gap record carrying:

Field Content
Gap identity A stable identifier unique within the governing specification version
Gap type The producing operation and locus set (one or more of: order, perspective, variant, data, domain-model, KB, specification, construction-conflict, governing-conflict)
Producing artifact The artifact and version in which the gap was detected
State Current state: Open / In-resolution / Resolved / Declared-permanent
Authority procedure reference The registered authority procedure governing this gap’s transitions
Transition history Ordered record of state transitions: each entry carries the prior state, the new state, the authorization act identity, and the effective timestamp
Resolution record Where state is Resolved: the resolution action taken, the artifact that closed the gap, and the re-verification verdict confirming closure
Permanence-declaration record Where state is Declared-permanent: the authority identity, the justification, and the effective date

Closure witness. When a gap transitions to Resolved, the gap record’s resolution record serves as its closure witness. It must carry: the resolution action taken, the aspect(s) or locus under which the gap was open, the artifact that closed it (identified by content hash and version), and the re-verification verdict that confirmed closure.

Permanence-declaration record. When a gap transitions to Declared-permanent, the gap record’s permanence-declaration record must carry: the authority identity (the role, procedure, or service that authorized the transition), the gap identifier(s), the justification (why the gap cannot be resolved within the current governing specification scope), and the effective date. The permanence-declaration record is itself a registered artifact enrolled in the delta-attestation lifecycle.

Effect on certificate scope. A gap in Declared-permanent state narrows the declared scope of any conformance certificate whose governed artifact or aspect set intersects the gap’s locus. The certificate’s declared scope (Field 5) must explicitly exclude the aspect(s) or locus under which the permanent gap was declared. A certificate whose declared scope does not account for known permanent gaps in Declared-permanent state does not conform.

Composition. This canonical mechanism composes with:

  • §01 §10 (completeness and gap referral) — model-layer gaps at order, perspective, and variant loci enter the canonical state machine; conditional attestation at the adjudication gate (§01 §8) is triggered by gaps in Open or In-resolution state
  • §03-i §2.4 (multi-locus gap report) — gaps emitted by semantic binding enter the canonical state machine at Open state; pending-refinement is an in-progress annotation on an Open gap, not a separate state
  • §03-ii §3.4 (KB lifecycle) — KB-locus gaps emitted during domain-model amendment or KB self-change enter the canonical state machine at Open state
  • §2.11 (gap resolution lifecycle) — data gaps are governed by this canonical mechanism; §2.11 specifies the resolution paths available for data-locus gaps specifically

2.1 What it is and what it is not

Evidence-gathering verification is active, discovery-driven conformance assessment. It is distinct from certification (§02a):

Certification (§02a) takes evidence as given. A proof artifact, test result, or empirical report is supplied; the system certifies a verdict over it and emits the conformance certificate (nine structural invariants, §02b §2).

Evidence-gathering verification does not start with evidence in hand. The evidence sufficient to reach a verdict must be found — by traversing knowledge bases and data sources, expanding what is known, and reducing uncertainty until the verdict can be reached and justified.

The two compose. The gathered-evidence verdict and recomputation witness may be carried in or referenced by the conformance certificate (§3.1), which is then consumed at a downstream gate. The evidence-gathering nucleus is the gathering-and-verdict; the certificate is one delivery embodiment.

2.2 The four artifact roles

Four distinct artifacts participate, each in a distinct role.

Domain model(s) (“the map”) — one or more. The generative authority: the orders, perspectives, and aspects that do the structuring. One or more domain models may be active simultaneously; each is composable and independently operable (§01 §1). Each domain model is the governing lens for the artifacts and traversal paths scoped to it, not the content. It serves as a guide in the traversal. Where multiple domain models are active, the traversal trace (§2.7 invariant i) records which domain model version governed each step.

Governing specification. A dynamic, context/condition/time-sensitive active selection from a collection of one or more formal specifications (§03-ii §1.1), constituting the global source of truth for a governed operation. The governing specification is a view over a governing collection — the Juno-layer registered artifact (§01 §12.1) that declares which domain models and formal specifications participate in the deployment, the activation conditions under which each becomes active (static, conditional, event-triggered, time-bounded, programmatic/API, human-selection, machine-selection, or grouped, per the activation condition schema of §01 §12.2), the collection’s declared precedence order, and the registered conflict resolution procedure. The governing specification is resolved at operation time from that collection; it is not itself a single flat artifact. An architecture may operate multiple governing specifications simultaneously, each active under different contexts or conditions, each with its own adjudicator set (§03-ii §1.1). The governing specification is expressly not the raw corpus; it is the active, formalized, adjudicated collection of formal specifications governing the current operation. Where two or more formal specifications in the governing collection assert incompatible predicates at the same domain aspect, a governing-conflict gap (§01 §12.4, locus: governing-conflict) is registered and governed under the canonical gap governance mechanism (§2.0); the conflict resolution procedure declared in the governing collection (§01 §12.5) governs the resolution path; all verdicts produced while the gap is Open or In-resolution carry a conflict-gap annotation per §01 §12.6.

Knowledge base. A map-produced artifact: the order-structured, co-indexed, navigable store of aspect-typed primitives and aspect-bound variants, built for discovery and traversal. Formal specifications (§03-ii §1.1) are KB variants and participate in this role.

Ground-truth anchor. The governing specification — in whatever shape it takes — establishes the ground-truth anchor against which all measurement is performed. Without the anchor, there is no reference frame; the anchor is the precondition for measurement.

Governing specification lifecycle. At initial construction, the governing specification is constituted from formal specifications that have each undergone validity determination (§03-ii §1.1). Once established, its active selection may change dynamically as context, conditions, or time change. Each constituent formal specification is a versioned artifact governed by the delta-attestation lifecycle (§02b §5); a scope-breaking amendment to any constituent triggers re-adjudication of that constituent and re-evaluation of the governing specification’s active selection.

Fallback hierarchy. Where no governing specification has been constituted, three fallback positions apply in order: (1) specification-absent fallback — when no formal specifications have been provided or adjudicated, the domain model serves as the governing specification; (2) model-absent fallback — when the domain model is also absent or incomplete but at least one formal specification version has been committed, the most-recently-committed formal specification serves as the governing lens; (3) reverse-synthesized fallback — when neither a formal specification nor a domain model is available, a domain model is reverse-synthesized from available artifacts (KBs, data sources, observation-over-time telemetry) per the bootstrapping paths of §03-i and §03-ii, and that reverse-synthesized model serves as the governing lens. The full three-rung fallback hierarchy is canonically specified in §2.12.

Cold-start. Cold-start instantiation requires a governing lens before it can proceed. A domain model is the preferred governing lens. If none is provided, the bootstrapping paths of §03-i (from data sources or observation-over-time telemetry) and §03-ii (from KBs or externally-provided specifications treated as corpus source material) are the operative mechanism for producing one before cold-start proceeds. An externally-provided specification (a protocol, standard, guideline, or rules document) is source material for bootstrapping a domain model; it is not itself a formal specification before predicate lowering through a domain model, and it does not serve as a governing specification until so lowered and adjudicated. Cold-start is not blocked by the absence of a domain model — it is preceded by bootstrapping. Partial specifications that satisfy only the corpus-derivation role are valid intermediate artifacts but may not serve as governing specifications until adjudicated.

2.3 Multi-guide traversal

To reach a verdict, the system traverses the KB(s) and data source(s) to gather evidence. The traversal is guided by one or more of: (a) the order-decomposed domain model at any order or composition of orders, (b) the governing specification (including where it is a metadata-bound view within a KB, or is the map serving as fallback), and (c) the KB(s) themselves. The guide is multi-source; the KB may steer the traversal in addition to the map and specification.

The traversal rides the KB’s bidirectional metadata fabric. It operates at the level of aspect-typed primitives — not raw chunks alone — and navigates entry-point-agnostically across the order structure and the data’s aspect bindings.

2.4 Dual-modality evidence

Evidence is gathered combinatorially across one or more data sources and one or more knowledge bases used together, not one at a time. Both the guide(s) and the evidence source(s) are each one or more of {the map at any order or composition, the governing specification, KB(s), semantic data over data source(s)}, in any composition.

Discovery proceeds in two complementary modalities, bridged by the metadata fabric.

Text-side (symbolic) modality. Operates on the symbolic representation on a what-was-seen basis: by textual and symbolic methods including scoring, trees, lexical overlap, and structural overlap. May employ language models of any class or size, including enterprise-grade LLMs and models suited for training or fine-tuning, as well as non-model-based symbolic methods. Non-limiting as to model class, size, architecture, or generation.

Embedding-side (numeric) modality. Operates on the embedded representation. Because embeddings are numeric, similarity match and lookup are computationally efficient and operate over the full embedded space.

The two modalities are interchangeable and composable; either or both may be used. The metadata fabric bridges them: a step in one modality may continue in the other.

2.5 Bounded exploration

Discovery proceeds over a multi-directional exploration fabric, bounded by a perimeter defined by the governing specification. Four mechanisms compose it.

(a) Controlled, reversible embedding transformation (“pondering”). On the embedding-side modality, discovery surfaces related primitives and traversal paths by applying controlled, bounded transformations to the embedding under analysis. Because a tuned embedding model makes match and lookup efficient, this bounded transformation constitutes a form of reasoning: exploring related positions in the embedding space without corrupting the evidence. The mechanism operates over the KB’s embedded representation using the bidirectional round-trip (§03-ii §3.2) to identify the originating primitive of each visited neighbor position.

The admissibility conditions, mathematical bounding principle, and traversal record requirements are fully specified at the KB layer in §03-ii §3.2a. The operative constraint here is: a pondering step is a controlled transformation of the representational state satisfying the §03-ii §3.2a admissibility conditions — bounded displacement (D(T(e), e) ≤ δ, where D is the distance function declared for the KB’s representational space), semantic coherence (d(prim(T(e)), prim(e)) ≤ ε), and interpretability (within the locally coherent neighborhood). A transformation that satisfies the displacement bound but exits the locally coherent neighborhood is recorded as a boundary encounter, not as a traversal step.

Reversibility is required for pondering steps used as evidence-gathering traversal: the transformation must admit a declared inverse such that applying the inverse to T(e) recovers e within a declared numerical tolerance ε_inv, itself a registered parameter of the transformation record. The semantic coherence bound ε is likewise a declared registered parameter of the transformation record, alongside ε_inv; without registration, an inspector cannot verify which value of ε was in force during a specific pondering step. Transformations that satisfy the §03-ii §3.2a admissibility conditions but do not admit an inverse satisfying the declared ε_inv are admissible as exploration steps (surfacing candidate neighbors) but not as pondering steps in the recomputation witness — a witness that cannot be re-derived within the declared tolerance does not satisfy the §2.7 re-derivability requirement.

For each pondering step, the traversal trace component of the recomputation witness records the fields specified in §03-ii §3.2a: the transformation identity and parameters, the source entry state (as a content-derived identifier, inline representation, or both, per operator preference), the displacement magnitude under the KB’s declared distance function, the neighbor entry identifier, the semantic distance, and the admissibility decision.

(b) Ground-truth-anchored measurement. Measurement is performed relative to the ground-truth anchor established by the governing specification. Multiple quantities may be measured from the anchor: relationship distances across the navigable fabric, weights, scores (text-side or embedding-side), and coverage. Each tracks a different quantity off the same anchor.

(c) Measure-agnostic control functional. From the measurements, the system computes a control functional and uses it to shape the next action under a selected strategy. Each direction the exploration exposes is tracked by the functional with a continue / deprioritize / prune signal. A step in one direction may expose further directions worth pursuing, yielding the multi-directional fabric.

The control functional is measure-agnostic in the following structural sense: it accepts a declared measure drawn from a registered measure vocabulary — non-limiting examples include entropy, free energy, expected free energy, information gain, surprise, divergence, coverage, and cost; any measure meeting the declared-measure selection requirement is admissible — and its continue/deprioritize/prune decision is computed from the declared measure’s output. The declared measure is a configuration-time selection, not a compile-time selection. A system that hard-codes a single measure (for example, cosine similarity threshold) does not practice a measure-agnostic control functional even if that measure is in the registered vocabulary.

(d) Higher-order synthesis during exploration. Within the governing-specification-bounded perimeter, the system may perform higher-order synthesis (§01 §11) over any combination of gathered evidence sources: order outputs from the domain model, KB primitives acquired during traversal, semantic data retrieved from data sources, or prior higher-order outputs produced earlier in the same exploration. This is not a separate mechanism — it is the application of the §01 §11 higher-order synthesis procedure within the evidence-gathering context. Each synthesis act declares its input selection and produces a composition provenance record, making the derived finding recomputable and independently verifiable. The composition provenance record must carry at minimum: the governing order type(s), the input primitive identifiers and versions, the synthesis procedure identity, and the output primitive identifier; see §01 §11 for the full field definition. The traversal trace component of the recomputation witness (invariant i, §2.7) includes synthesis provenance records for any higher-order synthesis steps performed during the traversal.

The analytical capabilities available here include: traversal of one or more KBs alone, traversal of one or more data sources alone, and combined traversal of KBs and data sources together. Each combination surface distinct analytical capabilities: KB traversal surfaces aspect-typed reference knowledge and cross-primitive relationships; data source traversal surfaces operational evidence and quantitative signals; their combination enables findings that neither source alone can yield — hidden patterns, cross-source correlations, and nontrivial relationships not explicitly present in any single source. Higher-order synthesis over these combinations produces findings of this kind, and those findings may be written back as new primitives in the KB or as gap referrals in the completeness mechanism (§01 §10), driving the system toward completeness.

Two-layer KB × data-source attribution join. Where combined KB and data-source traversal is used and a finding is to be attributed across the relation between them, the attribution is resolved at the order-structured join of KB governance and data-source instance-facts — neither layer alone is sufficient. The join is a governed act under the same domain model and governing specification that governs the traversal; it is not a post-hoc aggregation of independent retrieval outputs. The full specification of the join, the join result record, the KB ↔ data-source divergence signal, and the attribution record is in §2.12.

Exploration continues until a verdict can be reached or a bound (budget, depth, or convergence criterion) is met. The exploration budget and depth bound are declared registered parameters of the evidence-gathering configuration record, enrolled in the delta-attestation lifecycle; they are not hard-coded. Where evidence is insufficient, the system emits a gap-on-insufficiency rather than asserting an unsupported verdict. A gap-on-insufficiency emitted by evidence-gathering verification carries the gap locus of the unresolved evidence shortfall (one or more of: data, KB, specification, domain-model, as applicable); it enters the canonical state machine at Open state with those locus fields populated. This gap composes with the completeness and gap-referral mechanism of §01 and with the multi-locus gap report of §03-i §2.4.

2.6 Grounded conformance verdict

The system computes a conformance verdict for the artifact against the governing specification from the gathered evidence — not from model-internal assertion. The verdict is drawn from a registered verdict vocabulary whose canonical values are {conforming, non-conforming, conditionally-conforming}; additional verdict values may be declared in a registered extension to the vocabulary, provided each extension value carries a declared semantic definition and admissibility conditions. A conditionally-conforming verdict carries an explicit conditions record: a non-empty set of structured conditions, each specifying the aspect or clause under which the condition applies, the nature of the condition (unresolved gap, evidence-below-threshold, scope-restricted evidence, temporal limit, or other declared condition type), and the action required to clear the condition. A verdict of conditionally-conforming without a conditions record does not conform to the Mars® specification. Extension verdict values that omit a conditions-record requirement are not admissible.

2.7 Recomputation witness

The inventive matter is the co-required set of three structural invariants, not the count. A recomputation witness for a governed evidence-gathering act is defined by the co-presence of three structural invariants — each independently required, none waivable. The canonical realization records each invariant as a distinct component. A witness carrying all three invariants is conforming; a witness omitting any invariant is structurally deficient.

Invariant Canonical component What it requires
Traversal trace under guide (i) For each traversal step: the aspect-typed primitive visited; which guide(s) steered the selection (domain model, governing specification, KB, or combination); the order type, perspective tag, and variant identifier (as applicable) of the governing primitive; and the domain model version that governed the step (encoded in the aspect identifier or recorded explicitly where multiple domain models are active). For any pondering step: the transformation applied, its declared inverse, and the pre-transformation embedding state — recorded as a content-derived identifier, an inline representation of the state, or both, at the operator’s declared preference. Where the evidence-gathering traversal is performed as §02a §4b governed traversal (with declared inputs, declared parameters, and a steering-composition function navigating the metric space under the §02a §4b 5-condition structural invariant), the §02a §4b traversal witness (§02a §4b.4) is a first-class required component of the witness chain — additive to the traversal trace; it is not a substitute for the traversal trace. In the §02a §5a.2 chain, the §02a §4b traversal witness link appears between the IR stage links and the analysis-act links; the traversal trace of this invariant is the detailed per-step record within that witness. Where evidence-gathering verification is performed within a composed discrete program (§02d), the §02d §3.2 model-navigation traversal witness is an additional required component of the recomputation witness — recording each order-structure walk step (entry order, exit orders, walk rule identity, domain model version per step) — and is additive to both the traversal trace and the §02a §4b traversal witness where that is also present. The full chain in that context is: [IR stage links] → [§02d §3.2 model-navigation traversal witness] → [§02a §4b metric-space traversal witness link(s)] → [analysis-act links] → [verdict link], where either traversal witness type may be absent if the corresponding traversal mode was not used. An implementation that produces only the §02a §4b traversal witness while operating a composed discrete program is structurally incomplete at the chain level.
Evidence record (ii) The data-source queries with returned values and the knowledge-base primitive expansions with returned values. Each entry is tagged with the aspect-binding and order type of the governing primitive. Where a two-layer KB × data-source attribution join is in effect (§2.12), the evidence record carries the join result record and any KB ↔ data-source divergence signals detected. Where the governing specification is a collection of formal specifications, the evidence record carries the identity and version of each formal specification active at the time of the operation, together with the activation conditions (context, condition, time) that made each active
Uncertainty-reduction record (iii) The per-step uncertainty estimate before and after each step, tagged with the order-typed aspect under which the step was executed

From this witness, an independent inspector can re-derive the same verdict from the gathered evidence under the governing specification, without access to the deployment and without trust in the system. This is what distinguishes a grounded, recomputable verdict from an opaque assertion.

Each component must carry per-step order-type tags. A witness that records computation steps without order-type tags on each step does not constitute a recomputation witness as defined in this specification.

Two-invariant witness is structurally deficient. The three invariants are jointly required and none is waivable. A witness carrying only two of the three — for example, a traversal trace and an evidence record without an uncertainty-reduction record, or a traversal trace and an uncertainty-reduction record without an evidence record — is structurally deficient and is not admitted as a recomputation witness under this section. A two-component witness does not enable an independent inspector to re-derive the verdict: the uncertainty-reduction record is the component that establishes why the traversal stopped where it did and why the gathered evidence was sufficient to support the verdict; without it, the inspector cannot distinguish a verdict grounded in adequate evidence from one reached prematurely. A traversal log plus an evidence list without uncertainty quantification per step is an audit record, not a recomputation witness. Equally, a verdict grounded in evidence but without a traversal trace cannot be re-derived: the inspector cannot verify that the guide steered the traversal to the evidence that supports the verdict. All three invariants are required for the witness to be conforming.

Re-derivability under non-deterministic traversal. The multi-guide traversal (§2.3) may employ a measure-agnostic control functional (§2.5(c)) whose declared measure is stochastic — for example, entropy estimates derived from sampling, or expected free energy computed by Monte Carlo approximation. In such cases, two re-derivation runs from the same witness inputs may diverge in their traversal paths. The traversal trace (invariant i) records the path taken; it is an audit record, not a re-execution prescription.

Re-derivability of the verdict does not require re-derivability of the traversal path. The verdict derives from the evidence record (invariant ii) and the uncertainty-reduction record (invariant iii), not from the traversal path alone. The rule governing non-deterministic traversal is therefore:

When the traversal is non-deterministic, the evidence record (invariant ii) must contain at least one form of direct, discrete evidence sufficient to reach the verdict independently of the traversal path. Direct, discrete evidence is evidence that is independently verifiable without re-running the traversal. Admitted forms, non-exclusively:

Form Description
Ground truth reference A KB primitive, governing specification clause, or previously attested artifact — directly addressable by identifier, version-stable, verifiable by lookup
Operational data A concrete query result from a data source — a discrete returned value at a declared, stable address in the source (such as a schema location, key, identifier, or query predicate); the source version, query definition, returned value, and the as-of timestamp of retrieval at the time of verification are recorded in the witness; re-execution against that recorded state may be achieved through source versioning, frozen snapshots, shims, or equivalent mechanisms declared in the licensee’s ecosystem

Evidence currency — the freshness invariant for operational data. Operational data differs from ground-truth references and previously-adjudicated evidence in one structural respect: its underlying source state is not version-stable. A live inventory table, a patient record, a telemetry stream, or any moving-source row is correct at retrieval and may be stale a moment later. Version-based staleness detection (§03-i §2.6; certificate Field 8) governs artifact amendment; it does not govern the recency of a retrieved value relative to the verdict it grounds. This section adds the freshness invariant that closes that gap.

Every operational-data evidence entry carries an as-of timestamp — the source-state time the returned value reflects, distinct from the wall-clock time of the query — as first-class, tamper-evident metadata within the evidence record (invariant ii). Where the source cannot supply an authoritative as-of time, the query wall-clock time is recorded with an as-of-unverified flag that propagates unstripped into the verdict.

For each domain aspect whose evidence may be drawn from a moving source, the governing specification declares an evidence-freshness bound — the maximum admitted age (verdict time minus as-of time) of operational-data evidence grounding a verdict at that aspect. The freshness bound is a registered parameter of the governing specification, per-aspect, and is not assertable per-verdict. At verdict formation, an operational-data entry whose age exceeds the aspect’s declared freshness bound is not admitted as grounding evidence: the verifier either re-retrieves within bound, or emits a typed evidence-staleness gap (locus data, subtype freshness) at that aspect under the canonical gap machine (§2.0), and no conforming verdict is issued over that aspect on the stale value. An aspect drawing on a moving source without a declared freshness bound is structurally incomplete at the governing-specification level and is refused at registration.

Where a knowledge base is derived from one or more moving sources, the KB carries a declared currency contract — a statement of the source state as-of time the KB reflects, per contributing source — propagated into every evidence entry expanded from that KB. A KB currency contract older than an aspect’s freshness bound is governed identically to a stale operational-data entry: it does not ground a conforming verdict at that aspect. The freshness invariant is uniform across direct operational-data retrieval and KB-mediated retrieval; the KB does not launder stale source state into fresh-appearing evidence. | Previously adjudicated evidence | A human-certified finding, a prior conformance certificate, or an attested recomputation witness from a prior pass — already verified, referenced by identity and version | | Combination | Any mix of the above forms, jointly sufficient to reach the verdict |

A witness in which the evidence record contains only stochastic or path-dependent intermediate states — with no direct discrete evidence independently sufficient to reach the verdict — does not satisfy the re-derivability requirement under non-deterministic traversal. The traversal may be non-deterministic; the evidence anchoring the verdict may not be.

2.8 Symmetric reinforcement

During verification, the system emits typed reinforcement signals from the enumeration {model-gap, specification-gap, data-source-gap, knowledge-base-gap}. Each signal is recorded in an audit trail naming: the artifact class for which a gap was surfaced, the aspect or order under which it was surfaced, and the gathered evidence supporting the identification.

Signal definitions:

Signal Meaning
model-gap Gathered evidence indicates the domain model is missing an aspect, perspective, relationship, or higher-order composition required to reach the verdict
specification-gap Gathered evidence indicates the governing specification is missing a clause, contains an ambiguity, contains an aspect conflict, or has incomplete scope — within one specification; this is a deficiency within a single artifact. A conflict between two individually-adequate formal specifications in the governing collection is not a specification-gap; it is a governing-conflict gap (locus: governing-conflict, §01 §12.4) and is governed by the conflict resolution procedure, not by the symmetric reinforcement policy
data-source-gap Gathered evidence indicates one or more data sources are missing a field, exhibit schema-version mismatch, contain stale records, or exhibit calibration drift
knowledge-base-gap Gathered evidence indicates one or more KBs are missing an aspect-typed primitive, metadata-fabric binding, cross-reference, or aspect-bound synthetic variant

A single declared reinforcement policy triggers a declared reinforcement action on the artifact class named by each typed signal. The reinforcement is symmetric across all four artifact classes under one mechanism.

What “single declared policy” requires. The reinforcement-policy record is a named, stored artifact referenced by identifier in every typed reinforcement signal it governs. It specifies: (a) the set of artifact classes to which it applies — this set must include all four: model, specification, data-source, knowledge-base; (b) the signal type schema for each class; and (c) the amendment-trigger conditions. Four separate feedback handlers without a shared reinforcement-policy record do not practice symmetric reinforcement as defined here, even if the handlers produce identical outputs. The amendment-trigger conditions declared in field (c) must be a single condition expression uniformly applicable across all four artifact classes — evaluated against whichever artifact class emitted the signal — not a set of four class-specific condition expressions declared under one policy record identifier. An implementation that declares one policy record but specifies distinct per-class trigger conditions in field (c) is not practicing symmetric reinforcement: the trigger condition is the structural constraint that makes the mechanism symmetric; class-specific triggers under one label produce four independently-conditioned loops, not one symmetric mechanism.

A reinforcement audit trail produced by four disjoint loops — one per artifact class, each governed by its own policy record — is not a conforming symmetric reinforcement audit trail under this section. The shared reinforcement-policy record is the artifact that makes the four classes first-class reinforcement targets under one mechanism; without it, the audit trail is four independent single-leg records, not a symmetric reinforcement record. An inspector verifying symmetric reinforcement checks that every typed signal in the audit trail — regardless of artifact class — carries the same reinforcement-policy record identifier; a signal carrying a class-specific policy identifier is evidence of single-leg reinforcement, not symmetric reinforcement.

KB ↔ data-source divergence is an attribution-layer signal, not a reinforcement signal. Where the two-layer KB × data-source attribution join (§2.12) is in effect, a divergence between the knowledge-base governance layer and the data-source instance-facts layer on the same finding’s referent produces a KB ↔ data-source divergence signal — canonically specified in §2.12. This signal is distinct from a knowledge-base-gap signal and from a data-source-gap signal: it identifies a conflict between two individually-adequate layers, not a deficiency in either relative to the governing specification. It is not a reinforcement signal and is not governed by the symmetric reinforcement policy of this section; it is an attribution-layer signal carried in the evidence record (invariant ii, §2.7). Its full field definition, trigger condition, and placement in the attribution record are specified in §2.12.

Model-gap reinforcement. A model-gap signal triggers amendment of the domain model: regenerating an affected order portion, re-binding the affected aspect-typed structure, or re-attesting the model under the delta-attestation lifecycle. The domain model is reinforced by the same mechanism and the same declared policy as any other artifact class.

Order-scoped regeneration proceeds bottom-up: the lowest-order primitives implicated by the model-gap are regenerated first, followed by each higher-order output (§01 §11) whose composition provenance record declares a regenerated lower-order primitive as a declared input, up to the gap site. Re-attestation is available only when the order structure itself is unchanged and only the binding or labeling of an existing primitive is affected. It is not available when a primitive’s content or composition changes.

Downstream cascade. When a typed signal triggers amendment of any artifact class (specification, domain model, knowledge base, or data source), that amendment is processed as a versioned event through the delta-attestation lifecycle (§02b §5). The four-valued delta classification applies; scope-breaking amendments cascade immediately to downstream pipeline components.

Perspective-bound reinforcement signals. A specification-gap signal generated within a perspective-bound evidence-gathering operation proposes a specification amendment scoped to the perspective’s admissibility rules. It does not automatically amend the governing specification for content outside those rules. The perspective-tagged signal is forwarded to the governing specification for consideration, but amendment outside the perspective’s primitive-admissibility rule requires a separate ungated (non-perspective-bound) evidence-gathering pass.

2.9 Perspective specifications

A perspective specification is a registered typed artifact declaring an operator-specific or jurisdiction-specific profile for the traversal and verdict. Each perspective specification simultaneously declares four rules.

Rule Content
Aspect-activation rule Which aspects of the governing specification are activated under the perspective
Primitive-admissibility rule Which aspect-typed KB primitives are admissible under the perspective
Data-source-admissibility rule Which data sources are admissible under the perspective
Steering rule How the perspective contributes to next-step selection in the multi-guide traversal

Under a perspective specification, aspects not named in the activation rule are not consulted; inadmissible primitives are not eligible as evidence; inadmissible data sources are not consulted. The perspective is a registered artifact in the specification registry; its activation in a traversal is recorded in the traversal trace component of the recomputation witness.

Four-rule simultaneous gate is the structural requirement. A perspective specification simultaneously declares all four rules — aspect-activation, primitive-admissibility, data-source-admissibility, and steering. A traversal-control artifact that declares fewer than all four is structurally incomplete as a perspective specification: it does not simultaneously gate the full scope of traversal control. Non-conforming variants: (a) a jurisdiction lookup table that gates which aspects are consulted by value-lookup alone — without a registered primitive-admissibility rule, a data-source-admissibility rule, and a steering rule — is not a perspective specification; it is a static aspect-activation filter; (b) an attribute-based access-control policy that resolves to a permit/deny per request through combining algorithms is not a perspective specification — it gates access decisions, not traversal of an order-decomposed governing specification with aspect-typed primitive admissibility; (c) a design-time multi-stakeholder viewpoint that produces a different model or knowledge-graph view is not a perspective specification — it produces different models at design time, not independently recomputable verdicts on the same governing specification at traversal time. The test for conformance is the four-rule simultaneous gate producing observably different traversals, witnesses, and verdicts on the same governing specification under different perspective specifications.

The system produces a perspective-bound verdict: recorded with a perspective identifier and independently recomputable from its own three-invariant witness under the named perspective specification.

On the same artifact and same governing specification under different perspective specifications, the system produces observably different traversals, observably different recomputation witnesses, and observably different recomputable verdicts — each independently recomputable from its three-invariant witness.

Conforming jurisdiction example. The following illustrates a conforming jurisdiction-specific perspective specification for an EU-jurisdiction deployment, contrasted against a non-conforming jurisdiction lookup table over the same domain. The domain content is illustrative; the structural pattern is normative.

Non-conforming (jurisdiction lookup table): A table keyed by {jurisdiction: "EU"} that returns a list of aspect identifiers to consult. This declares an aspect-activation rule only. It does not declare which KB primitives are admissible under EU-specific standards, which data sources satisfy EU data-residency requirements, or how traversal is steered under EU constraints. It is a static aspect-activation filter — variant (a) above — and does not constitute a perspective specification regardless of how it is labeled.

Conforming (four-rule simultaneous declaration): A registered perspective specification for EU jurisdiction declares all four rules simultaneously:

Rule EU-jurisdiction declaration
Aspect-activation rule Activates aspects bound to the governing specification’s prescriptive and procedural orders that carry EU-applicability tags; aspects tagged as non-EU or global-only are not activated under this perspective
Primitive-admissibility rule Admits KB primitives whose provenance records cite EU-recognized sources (e.g., EMA guidelines, EU MDR articles, GDPR recitals) and whose aspect bindings fall within the activated aspect set; excludes primitives whose sole provenance is non-EU regulatory sources not recognized under the applicable EU framework
Data-source-admissibility rule Admits data sources whose characterization records declare EU data-residency compliance (storage and processing within declared EU jurisdictions); excludes data sources whose characterization records declare residency outside the declared EU jurisdictions or whose residency is undeclared
Steering rule At each traversal step, next-step selection weights aspects with EU-applicability tags above aspects with non-EU or global-only tags when both are in the activated set; where two equally-weighted paths are available, the path whose terminal aspect carries the narrower EU-specific scope is preferred

This perspective specification, registered in the specification registry, produces observably different traversals, witnesses, and verdicts on the same artifact under the same governing specification than a global-jurisdiction perspective specification would — because different aspects are activated, different primitives are admissible, different data sources are consulted, and traversal is steered differently. An inspector verifying EU-jurisdiction conformance checks: (1) that the four-rule declaration is present in the registered artifact; (2) that the traversal trace records activation under this perspective identifier; (3) that the evidence record contains only primitives and data-source results admitted under the declared rules; and (4) that the verdict carries the EU-jurisdiction perspective identifier and is recomputable from its three-invariant witness under this specification. A deployment presenting jurisdiction-specific verdicts without a registered four-rule perspective specification for the claimed jurisdiction does not conform.

2.10 Reinforcement loop discipline

The symmetric reinforcement mechanism (§2.8) emits typed signals and routes them to amendment actions. This subsection governs the loop that connects those actions back to the next verification pass.

Loop initiation. A reinforcement loop cycle is initiated when one or more typed signals are routed to amendment actions under the declared reinforcement policy. The loop is not initiated by signal emission alone — a signal that is recorded in the audit trail but not routed to an amendment action does not initiate a loop cycle.

Amendment ordering. Where a single verification pass emits multiple typed signals affecting more than one artifact class, the amendment actions are ordered by artifact-class dependency:

  1. Data-source amendments first — supply changes are resolved before downstream artifacts are rebuilt
  2. Domain-model amendments second — order-structure changes govern all downstream extraction and binding
  3. Knowledge-base amendments third — KB regeneration proceeds under the amended domain model
  4. Specification amendments last — specification changes are processed after the artifacts they govern have stabilized

An amendment that creates a new gap in a lower-ranked class restarts the sequence from that class. The sequence is not re-initiated by amendments whose downstream effect is only additive (scope-extending — as classified under the delta-attestation lifecycle §02b §5) relative to the current pass.

Conflict resolution for concurrent signals. Where two or more signals of the same class are emitted within a single pass, they are resolved into a single amendment event before routing. Resolution applies the following rule: signals affecting the same aspect are merged into a single amendment record; signals affecting different aspects within the same class are processed as independent amendment events ordered by their aspect-position in the order-decomposition tree (lower-order aspects first).

Loop termination. A loop cycle terminates when either: (a) all routed amendment actions complete without emitting new typed signals, or (b) the declared termination criterion is met. The declared termination criterion is a registered parameter of the reinforcement-policy record; it is not hard-coded. Non-limiting termination criteria: no new gap-on-insufficiency signals after re-verification, coverage-above-threshold, or fixed iteration count.

Where no termination criterion is declared, the default is: the loop terminates when a full re-verification pass completes without emitting any new signals of the same type as the signals that initiated the current cycle.

Non-termination. Where a loop cycle does not terminate within the declared criterion, the system emits a reinforcement-stall record: a single record identifying the affected artifact class, the aspect(s) under which signals continued to emit, and the last-stable evidence state. The reinforcement-stall record is a gap-on-insufficiency at the reinforcement-policy level; it does not produce a conformance verdict. The certificate path is held until the stall is resolved by authority action or the scope of the current pass is declared explicitly restricted.

Re-verification after amendment. After each amendment event, the next verification pass must be conducted under the updated artifacts. The re-verification pass uses the same governing specification version unless a specification amendment was among the events in the current cycle — in which case the delta-attestation lifecycle (§02b §5) governs whether the updated specification version constitutes a scope-preserving, scope-extending, scope-restricting, or scope-breaking change before the re-verification pass proceeds.

2.11 Data gap resolution lifecycle

A data gap is a gap whose locus set includes {data} — a domain aspect for which no supporting data-source structure exists or suffices, as emitted by semantic binding (§03-i §2.4) or evidence-gathering verification (§2.5). Data gaps are governed by the canonical gap governance mechanism (§2.0): the four canonical states, authority procedure contract, gap record structure, closure witness, and permanence-declaration record all apply as specified there. This subsection specifies the resolution paths available specifically for data-locus gaps.

Resolution paths. Resolution paths include, non-exhaustively, the following; any path is admissible provided it satisfies the same admissibility conditions (aspect-binding, semantic binding, closure witness). Each path carries its own specific admissibility conditions:

  1. Data source acquisition. A new or amended data source is introduced. Admissibility conditions: the data source must be characterized, aspect-bound, and accepted through the semantic binding operation before it may be used to close the gap. A data source introduced but not yet aspect-bound does not close the gap.

  2. Schema extension. An existing data source is extended with new fields or structure. Same admissibility conditions as acquisition; the extended source must complete semantic binding.

  3. Governed data generation (§03-iv §2). New data conforming to the governing specification is generated under the domain model. The generated corpus is subject to the full governed data generation requirements of §03-iv §2, including its own boundary, witness, and certificate. A generated data corpus that has not received a governing-data-generation certificate may not close a data gap.

  4. Benchmark-anchored evaluation (§03-iv §3). Where the gap is an evaluability gap — the domain aspect exists but no data source can be acquired or generated to fill it — the gap may be resolved by issuing a benchmark for the aspect (§03-iv §3) and declaring the benchmark as the operative evaluation surface. The certificate path proceeds against the benchmark, and the gap is declared resolved-by-benchmark with the benchmark identity in the gap closure record.

The resolution record (§2.0 closure witness) for a data gap carries: the resolution path taken (identified by name or declared path identity), the aspect(s) under which the gap was open, the data-source or benchmark artifact that closed it (identified by content hash and version), and the re-verification verdict confirming closure.

2.12 Attribution

Attribution is the act of binding an output — a forensic finding, a conformance verdict, a summary, an analysis — back to the artifact(s) that govern or support it, under the domain model. It is distinct from gap identification (which identifies an absence) and from the conformance verdict (which asserts conformance or non-conformance). Attribution localizes: it names which artifact, which aspect, and which layer of the asset relation is responsible for or supports the output.

Fallback hierarchy — canonical statement. The governing reference for any attribution act is supplied by a three-rung fallback hierarchy, applied in order:

  1. Governing specification — the active selection of adjudicated formal specifications (§03-ii §1.1) for the current context, condition, and time. This is the preferred governing reference.
  2. Domain-model-as-specification — when no governing specification has been constituted, the governing domain model serves as the governing reference. The domain model’s order structure, aspects, and perspectives supply the attribution frame.
  3. Reverse-synthesized-model-as-specification — when neither a governing specification nor a domain model is available, a domain model bootstrapped from available artifacts (KBs, data sources, observation-over-time telemetry) per §03-i and §03-ii serves as the governing reference. A reverse-synthesized model used in this role must be a registered artifact enrolled in the delta-attestation lifecycle (§03-iv §2.7a); it is the least-preferred fallback and must be identified as such in any attribution record and any certificate that references it.

The fallback is resolved once per attribution act and recorded in the attribution record. An attribution act that does not record which rung of the fallback hierarchy supplied its governing reference does not conform.

Rung supersession. When a higher rung becomes available — a governing specification is constituted where the domain model had served as the governing reference, or a domain model replaces a reverse-synthesized model — the transition is a versioned supersession event recorded in the registry. Verdicts and attribution records produced under the lower rung remain valid as of their recorded rung and governing-reference version; the supersession does not retroactively invalidate them. Subsequent acts resolve against the higher rung.

Domain model as cross-artifact join key. All artifact metadata — KB metadata (§03-ii §2) and data source metadata (§03-i §2.1) — is built and versioned against the governing domain model. The domain model’s aspect identifiers (order type, position in order-decomposition tree, domain model version) are therefore the natural shared index across artifact classes: a KB entry and a data source field bound to the same domain aspect are jointly resolvable against that aspect without a secondary lookup. This is what makes cross-artifact attribution possible: the domain model is the glue that makes the metadata of distinct artifact classes commensurable.

Two-layer KB × data-source attribution join. Where a finding is attributed across the relation between a knowledge base and a data source, the attribution is resolved at the order-structured join of knowledge-base governance and data-source instance-facts, keyed by the shared domain aspect identifier. Knowledge-base governance supplies the rule, obligation, or reference knowledge that governs what the data-source instance-facts mean relative to the finding; data-source instance-facts supply the concrete operational evidence. The join is resolvable because both layers carry the same aspect identifier — built against the same governing domain model — as their primary index. Neither layer alone is sufficient: KB governance without data-source facts establishes a reference but not an instance-level attribution; data-source facts without KB governance establish an operational observation but not a governed attribution across the relation.

The join applies only when both a KB and a data source are present in the asset relation. When only a KB is present, attribution is KB-layer only. When only a data source is present, attribution is data-source-layer only. In both single-layer cases the join requirement does not apply; the attribution record must declare which layers were present and which was used.

Join result record. The join produces a structured join result record carried in the evidence record of the recomputation witness (invariant ii, §2.7). The join result record carries: (a) the domain aspect identifier under which the join was resolved; (b) the KB entry identity and version supplying the governance layer; (c) the data source identity, query identifier, and returned value supplying the instance-facts layer; (d) the governing domain model version and governing reference identity (which rung of the fallback hierarchy was active); and (e) the join outcome — the attribution claim, order-typed and expressed as a structured record. An attribution act that does not produce a conforming join result record is not a governed two-layer attribution act under this section.

KB ↔ data-source divergence signal. Where the two-layer join is in effect, a divergence between the KB governance layer and the data-source instance-facts layer on the same finding’s referent is a named structured signal: the KB ↔ data-source divergence signal. This signal is distinct from a knowledge-base-gap signal (which identifies a deficiency in the KB relative to the governing specification) and from a data-source-gap signal (which identifies a deficiency in the data source relative to the governing specification). A KB ↔ data-source divergence signal identifies a conflict or inconsistency between what the KB governance layer asserts and what the data-source instance-facts show — on the same referent, under the same governing specification — where neither layer is individually deficient.

The divergence signal is emitted when the join resolution produces a KB governance value and a data-source instance-facts value that are semantically inconsistent under the governing domain model’s declared distance or consistency function for the bound aspect. The consistency function is a declared registered parameter of the attribution configuration record; it is not hard-coded. Non-limiting forms: a semantic distance threshold, a boolean contradiction check, a temporal inconsistency rule (KB asserts policy X is current; data source shows policy Y is in effect as of timestamp T). A divergence signal is not emitted when the two layers are merely different in content — they may express different aspects of the same referent; the signal is emitted when they are inconsistent on the same aspect under the governing domain model.

The divergence signal record carries: (a) the domain aspect identifier under which the divergence was detected; (b) the KB entry identity and the value it asserts; (c) the data source identity, query identifier, and the value it asserts; (d) the consistency function applied and the computed inconsistency measure; (e) the governing domain model version; and (f) the attribution act identifier linking it to the join result record. The divergence signal is recorded in the evidence record of the recomputation witness (invariant ii, §2.7) and tagged with the order-typed aspect under which it was detected. It is not a reinforcement signal and is not governed by the symmetric reinforcement policy (§2.8); it is an attribution-layer signal that contributes to the attribution claim and may, separately, inform gap identification if the inconsistency reveals a deficiency in either artifact class.

Attribution record. Every governed attribution act produces an attribution record carrying: (a) the output being attributed (finding, verdict, summary, or analysis — identified by content hash); (b) the fallback-hierarchy rung that supplied the governing reference; (c) the active formal specification identities and versions and their activation conditions, where the governing specification is a collection; (d) the join result record (where the two-layer join was in effect); (e) any KB ↔ data-source divergence signals detected; (f) the order type and aspect identifier of the attribution; and (g) a content hash over all preceding fields, making the record tamper-evident. The attribution record is a first-class registered artifact enrolled in the delta-attestation lifecycle. An independent inspector can re-derive the attribution from the retained record and the asset relation, without access to the deployment.

← What this section covers · Section index · The conformance certificate →