§03-ii Minerva — Knowledge Base — §3 — Aspect-typed primitive extraction (Nucleus A)

Mars® Spec › §03-ii Minerva — Knowledge Base › §3 — Aspect-typed primitive extraction (Nucleus A)

← Inputs and corpus characterization · Section index · Outputs →

3.1 Aspect-typed primitive extraction (Nucleus A)

Corpus source-trust admission. Provenance to a source span establishes where a primitive came from; it does not establish whether that source is trustworthy. A poisoned or adversarially-authored corpus document enters characterization cleanly and becomes ground truth with impeccable span provenance — the poisoning root that provenance alone does not close. Each corpus document admitted to extraction therefore carries a declared source-trust tier: attested (the document carries an attestation from a named authority with standing for its domain, verifiable by the same joint-authority discipline as §02c anchors), first-party (the document originates from the licensee’s own governed systems under a declared chain of custody), or unattested (neither). The source-trust tier is assigned at admission, recorded in the extraction record, and propagates unstripped — exactly as the lossy-provenance flag propagates (§01 §14 D24) — from the corpus document into every primitive and variant extracted from it, and from those primitives into every evidence record and verdict they ground. A primitive derived from an unattested document carries an unattested trust tier that an inspector observes on any verdict it grounds; the governing specification declares, per aspect, the minimum source-trust tier admissible as grounding evidence, and a verdict grounded at an aspect on evidence below its declared minimum tier is non-conforming. This makes corpus trust a first-class, propagating, gate-able property rather than an assumption absorbed silently at characterization time. Where a primitive, variant, or other derived artifact draws on two or more inputs of differing tiers — a traversal-surfaced primitive’s declared inputs, or a variant generated from multi-source context — the derived artifact carries the minimum tier present among its inputs, and a verdict grounded on entries of mixed tiers carries the minimum tier present in its grounding set. A corpus document admitted to extraction without a source-trust tier assignment is a structurally incomplete admission.

Map-governed extraction. The corpus is analyzed through the domain model to extract primitives typed by the orders of the model. The order types are those declared in the governing domain model; non-limiting examples of common order types and their characteristic primitive types:

Order type (example)	Characteristic primitive type
Descriptive	Entities, roles, systems
Prescriptive	Considerations and constraints (with required facts, severity, evaluation logic)
Procedural	Procedures (with steps, prerequisites, outputs, context)

The actual orders and their primitive types are determined by the governing domain model, not fixed by this specification. A domain model with different or additional orders produces correspondingly different primitive types. The model governs which primitive types to look for per order and how to interpret content. This is different from ungoverned entity-relation extraction and from flat-ontology triple extraction, neither of which produces order-typed primitives governed by an order-decomposed model.

Extraction mechanism. The extraction act applies the domain model’s aspect definitions and characteristic vocabulary to the corpus to identify candidate spans and type them to aspect identifiers. For each aspect in the governing domain model, the extraction act operates with: (a) the aspect’s definition — its declared scope, order type, membership criteria, and characteristic vocabulary as specified in the domain model’s order-decomposition tree; (b) exemplars drawn from the KB (where the KB contains previously-extracted primitives for this aspect — see governed exemplar traversal below); and (c) semantic data anchors drawn from the query library (where a data source carries structured ground-truth values for this aspect — see semantic data anchor below). The aspect definition is the governing specification of what to look for; the exemplars and semantic data anchors are the evidence of what it looks like in practice. Together they make the extraction act domain-specific, consistent across corpus additions, and resistant to the boundary-ambiguity and false-positive rates that definition-only extraction produces.

Governed exemplar traversal — KB as extraction guide. Where the KB contains previously-extracted primitives for an aspect, those primitives serve as extraction exemplars: concrete instances that operationalize the aspect definition and demonstrate what a correctly-identified primitive of that type looks like in this domain. The extraction act traverses the KB for the target aspect’s primitives, acquires a governed set of exemplars, and uses them to govern interpretation of candidate spans in the new corpus. This is structural few-shot extraction: the exemplars are not hand-selected arbitrary examples — they are aspect-typed, domain-model-bound primitives drawn from the KB’s registered, versioned content via the aspect-binding index of the metadata fabric. The traversal is bounded: the extraction act declares the aspect identifier(s) it is extracting for, traverses the KB’s aspect-membership index to retrieve the registered primitives for those aspects, and uses the retrieved set as the extraction-time exemplar context. Where §02a §4b governed traversal is used for this traversal — with declared traversal inputs, declared parameters, and a steering-composition function — the §02a §4b traversal witness requirements apply and the traversal witness link is carried in the extraction record (see below). The quality and consistency of extraction improves as the KB accumulates primitives: each new primitive, once registered, becomes available as an exemplar for future extraction passes, making the KB self-reinforcing as an extraction guide.

Semantic data anchor — data source as extraction validator. Where a data source (via the query library, §03-i §2.3) carries structured ground-truth values for a domain aspect, those values serve as semantic data anchors during extraction: they constrain what is admissible as a candidate primitive for that aspect by supplying operational instances of the aspect’s values. For example, if the domain model declares a prescriptive aspect whose characteristic value is a dosage range, the query library’s semantic data for that aspect supplies the actual dosage ranges observed in structured data; the extraction act uses these to validate candidate spans from the corpus — a span claiming to express that aspect is validated against the operational range before being typed and registered as a primitive. Semantic data anchors are not required; they are operative when the query library carries entries for the target aspect and a data source is admitted. Where used, the extraction record carries the query library entry identifier(s) consulted and the data-source characterization version at the time of extraction. Cross-artifact extraction guidance — traversable KB as exemplar source, semantic data as validation anchor — is a structural capability unique to this architecture: neither input alone is sufficient (KB exemplars without data anchors may extract plausible but operationally incorrect values; data anchors without KB exemplars may validate values but not identify the correct span), and neither is available to generic extraction pipelines that lack domain-model-governed traversal of aspect-indexed stores.

Order-structured organization. Primitives are organized along the orders of the domain model. A procedural order yields a procedure registry; a prescriptive order yields considerations and constraints; a descriptive order yields entities; other order types yield their own characteristic primitive structures. The KB’s internal structure reflects the order-decomposition of whatever domain model governs it. Perspective-constituted relational elements and variant-typed expressions are co-indexed alongside order-typed primitives.

Extraction record. Each extracted primitive carries an extraction record at the moment of extraction, recording: the corpus span from which it was extracted (document, boundary, and location); the aspect identifier under which it was extracted (encoding the domain model version per §3.2); the domain model version active at extraction time; the corpus version (corpus snapshot identifier per §3.4); the embedding model version under which the original vector for this entry was produced; the exemplar set consulted from the KB (as a list of KB primitive identifiers and the KB version from which they were retrieved, or null where no KB exemplars were used); the query library entry identifier(s) and data-source characterization version consulted as semantic data anchors (or null where not used); and the traversal witness link(s) for any §02a §4b governed traversal performed during exemplar acquisition. This extraction record is the provenance of the typed primitive: an inspector can re-derive the extraction decision from the recorded corpus span, aspect definition, exemplars, and semantic data anchors without re-running the full extraction pipeline.

KB self-generation — traversal-surfaced primitives. The KB is not only an extraction output from external corpus; it is also an extraction substrate in its own right. During traversal of the KB’s existing content (§3.2 traversability, §3.2a controlled transformations), higher-order synthesis (§01 §11) may surface inter-primitive relationships, compositional patterns, and derived assertions that are not explicitly present in any single primitive or source span. These traversal-surfaced findings are extractable as new primitives: each is typed to the domain aspect under which it was surfaced, carries a composition provenance record (§01 §11) as its derivation basis rather than a corpus span, and is registered as a first-class KB primitive with its own primitive identifier and aspect binding. The extraction record for a traversal-surfaced primitive carries: the composition provenance record of the higher-order synthesis act that surfaced it; the KB version at the time of traversal; the domain model version; and the §02a §4b traversal witness link where governed traversal was used. Traversal-surfaced primitives participate in all downstream KB operations — they may serve as exemplars for future extraction passes, be retrieved during evidence-gathering, and be targeted by typed reinforcement signals — on equal footing with corpus-extracted primitives.

Aspect-bound synthetic variant generation. From a primitive and its bound domain aspect, the system generates derived artifacts — extended or paraphrased questions, derived tasks, hypothetical queries, counterexamples, negative examples — each bound to the same domain aspect and co-indexed with the originating primitive (see §3.2). Variants increase aspect coverage and retrieval recall while remaining traceable to their originating primitive and source span. Where KB exemplars and semantic data anchors were used during the originating extraction, the same governing context is available during variant generation: the variant generation act may consult the KB’s existing variants for the same aspect as additional exemplars, producing aspect-consistent variants rather than generic paraphrases.

A synthetic artifact that is generated to augment retrieval coverage for a chunk — such as a hypothetical query or hypothetical document encoding generated at index time to improve similarity-search recall over that chunk — without being bound to the same domain aspect as the originating primitive and without being traceable to an aspect-typed primitive is not an aspect-bound synthetic variant as defined here. The binding to the domain aspect of the originating primitive is the structural requirement, not the generation of a hypothetical or paraphrase alone. A retrieval-coverage augmentation system that generates per-chunk hypotheticals without aspect-binding to an order-decomposed model is not practicing aspect-bound synthetic variant generation under this section and does not produce a conforming KB artifact.

Per-artifact provenance. Every extracted primitive, every traversal-surfaced primitive, and every synthetic variant carries provenance to its origin: corpus-extracted primitives carry provenance to their source span; traversal-surfaced primitives carry their composition provenance record; synthetic variants carry provenance to their originating primitive and source span. Any entry in the KB is traceable to its origin via this provenance chain.

Generate/consume/reconcile continuum. The governing order-structure may be (i) generated from the corpus, (ii) provided externally, or (iii) reconciled — a provided structure extended and conflict-resolved against structure discovered in the corpus. These are points on a continuum. The governing structure is always order-decomposed; its source is variable.

3.1a KB variant mechanism and variant consistency map

Adoption of the domain model variant schema

The aspect-bound synthetic variant generation described in §3.1 is the KB’s variant generation procedure. This section formalizes that procedure under the same variant mechanism as the domain model (§01 §5), making KB variants first-class registered artifacts subject to the same structural requirements, consistency map, and calibration obligations.

Every synthetic variant produced from a KB primitive is a KB variant declaration governed by the six-field variant declaration record (§01 §5). The six fields apply to KB variants as follows:

Field	Domain model meaning	KB variant instantiation
Variant identifier	Stable identifier for this variant within the model	Stable identifier for this variant within the KB, scoped to the KB version and domain model version
Source element identity	The canonical model element this is a variant of	The originating primitive identifier and its aspect binding
Variation axis	The axis along which this variant differs from canonical	Declared variation axis from the non-limiting set: register, granularity, syntactic structure, domain vocabulary, language binding, counterexample, negative example, hypothetical query, derived task
Admissibility constraints	Constraints on admissible content in this variant	The aspect binding constraint: the variant must remain bound to the same domain aspect as its originating primitive and must not introduce content outside the declared aspect scope
Lossiness declaration	Whether this variant is lossy; structured record of what is not carried	Whether this variant omits information present in the originating primitive; if lossy, what information is not carried and which other variants carry it; lossy-provenance flag is propagated through all downstream uses of this variant
Canonical form reference	Identity of the canonical element this variant expresses	Identity of the originating primitive in the non-embedded store, carrying source-span provenance and aspect identifier

A synthetic artifact that does not carry all six fields as populated content is structurally deficient as a KB variant and is not admitted as a variant declaration. The existing aspect-bound synthetic variant generation procedure produces conforming KB variant declarations when all six fields are populated at generation time.

KB variant consistency map

The KB variant consistency map is a registered artifact co-located with the KB, adopting the structure of the domain model variant consistency map (§01 §5.1) applied to KB primitives and their variants. It is a required KB artifact; a KB that contains synthetic variants but does not carry a variant consistency map is structurally incomplete.

Per-element entries. For each KB primitive that has one or more variants, the map carries a per-element entry recording:

Field	Content
Primitive identity	The originating primitive identifier and aspect binding
Variant set	The ordered set of variant identifiers declared for this primitive, each with their variation axis and lossiness declaration
Canonical form	A reference to the canonical form of the primitive’s content — the source-span extraction or traversal-surfaced composition provenance — against which all variants are grounded

Per-pair entries. For every ordered pair of variants expressing the same underlying primitive, the map carries a per-pair entry with the seven required fields from §01 §5.1:

Field	Content
Variant pair identity	Identifiers of the two variants in this pair, with their variation axes
Correspondence type	`equivalent` (both variants faithfully express the same content under their declared axes), `lossy` (one variant omits information carried by the other — identified in the lossiness declaration), or `conflict` (the variants assert incompatible content — a gap signal at the KB variant locus)
Ground-truth basis	The external canonical source from which both variants were derived; for corpus-extracted primitives, the source span; for traversal-surfaced primitives, the composition provenance record
Mechanism scores	Per-declared relational quantification mechanism (§01 §3.1): the mechanism’s scored similarity or equivalence determination for this pair; at least one mechanism score is required per entry
Calibration signal	Whether the mechanism’s score for this pair is consistent with the declared correspondence type; a mechanism that scores an `equivalent` pair as dissimilar, or a `conflict` pair as equivalent, produces a miscalibration signal for that mechanism on this pair
Attestation record	The named-authority attestation of the correspondence type (see §3.1a attestation below)
Version binding	The KB version, domain model version, and corpus version under which this entry was produced

Conflict entries. A conflict correspondence type is a gap signal at the KB variant locus. It is recorded as a KB-variant-locus gap in the multi-locus gap report (§03-iii §2.5) and is eligible for gap referral (§02a §7). A conflict entry does not block KB use; it must be resolved or declared permanent before the variant consistency map may be used as a benchmark source (§02a §5a.6) for the affected variants.

Attestation of the KB variant consistency map

The correspondence type for each per-pair entry is attested by a named human authority with domain standing, applying the same faithfulness-attestation procedure as predicate faithfulness (§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-pair correspondence type 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 for the affected pair set; no attested correspondence type is emitted for those pairs until the agreement threshold is met. The declared statistic must satisfy the five agreement-statistic properties (§01 §8): scale-appropriate, rater-count-appropriate, chance-corrected, independently recomputable, and threshold-bound.

The attested KB variant consistency map is a registered artifact enrolled in the delta-attestation lifecycle (§02b §5). Its version is bound to the KB version, domain model version, and corpus version under which it was produced. A scope-breaking amendment to any of these bound versions cascades re-attestation of affected per-pair entries.

The attested KB variant consistency map is the primary benchmark source for the calibration attestation gate (§02a §5a.6). Its per-pair entries — with their external canonical ground truth, their attested correspondence types, and their mechanism scores — are the test cases against which operator-declared thresholds and functions are evaluated for calibration. Because the map derives from external canonical text attested by a named authority, it is not operator-configurable and cannot be corrupted without producing an observable scope-breaking amendment cascade.

Lifecycle

On KB version increment. When a KB version increment affects primitives that have variants in the consistency map, the affected per-pair entries are scheduled for re-attestation. Stale entries carry a staleness marker and remain queryable but are excluded from benchmark use (§02a §5a.6) until re-attestation completes.

On domain model amendment. A scope-breaking amendment to the governing domain model invalidates per-pair entries whose variant pairs were derived under the prior model version. Those entries enter pending-re-attestation state. The calibration attestation gate (§02a §5a.6) treats pending-re-attestation entries as inconclusive inputs rather than calibration-passing inputs.

On corpus amendment. A corpus version increment affecting the source spans from which primitives were extracted triggers re-extraction of affected primitives, re-generation of their variants, and re-attestation of their per-pair entries. The cascade follows the same lifecycle as the KB version increment above.

3.2 Co-indexed bidirectional store (Nucleus B)

Co-indexed representations. Primitives, variants, and source content are recorded across two or more co-indexed representations: at minimum a symbolic representation (a relational or structured store of typed primitives, relationships, and metadata) and a retrieval-indexed representation enabling proximity- or similarity-based lookup over a declared representational space (such as a vector embedding index, a learned sparse index, a locality-sensitive hash structure, or any other architecture satisfying the navigability and bidirectional round-trip properties of §3.2). A graph representation is optional. Different domain aspects or primitive types may be co-indexed in different stores. No single representation is primary.

Navigable metadata fabric. A metadata fabric binds the co-indexed representations on shared identity — primitive, chunk, subchunk, and embedding identifiers — and on aspect and order membership. Any representation may serve as entry point and any other as lookup target. Navigation is entry-point-agnostic and N-way: text → similarity search → embedding match → metadata lookup → symbolic primitive, and any reverse or chained traversal. This is not a one-directional ID mapping for filtering; it is a genuinely N-way navigable fabric.

Bidirectional symbolic-embedding round-trip. The metadata fabric preserves identity through the symbolic-to-embedding transformation and enables the return path from embedding space back to a specific symbolic primitive. This is a first-class architectural property, not a consequence of N-way navigation. What it requires: each entry in the retrieval-indexed representation carries a stable identifier that references its originating primitive and subchunk in the symbolic store; the identifier survives the representational transformation and is associated with the retrieval-indexed entry in a manner that allows it to be returned without a secondary similarity search; retrieval returns the identifier alongside the result, enabling a direct lookup in the symbolic store. A fabric that stores identifiers only on the symbolic side — requiring a reverse similarity search to map from a retrieval result back to a primitive — does not satisfy the bidirectional round-trip requirement. The round-trip is: symbolic primitive → representational encoding → retrieval-indexed entry (with identifier) → metadata lookup → symbolic primitive. Each direction is a direct lookup, not a similarity approximation.

A co-indexed store whose embedded entries carry identifiers used solely for post-retrieval filtering — where the identifier is a metadata annotation that narrows a result set but does not enable a direct symbolic lookup without a secondary similarity pass — is not a conforming co-indexed bidirectional store under this section. The requirement is direct-lookup identity preservation in both directions, not identifier annotation for filtering. An implementation that satisfies filtering-by-identifier without satisfying direct-lookup round-trip is a hybrid relational-plus-vector index with metadata filtering, not a co-indexed bidirectional store as defined here, and is not a conforming KB artifact under this section.

This bidirectional identity preservation is the enabling condition for controlled embedding-space transformations (§3.2a below and §03-iii §2.5(a)): a transformation that moves a vector to a neighboring position in embedding space is only semantically interpretable if the return path — from the neighbor’s position back to its originating symbolic primitive — is a direct lookup. Without the round-trip, the neighbor’s identity is unknown and the transformation is not traversal; it is noise.

Distinction from graph RAG. The KB is traversible; it is not a graph RAG store. Graph RAG retrieves by graph proximity: it follows edges between nodes and returns content reachable within k hops. The KB’s traversal is governed by the order structure and aspect bindings: the traversal follows the domain model’s order-decomposition tree and the metadata fabric’s aspect-membership index, not adjacency in an undirected graph. The governing principle is order-typed relevance, not topological proximity. An autonomous system traversing the KB acquires content according to what the domain model declares relevant — not according to what happens to be connected in a graph whose edges were derived from co-occurrence or embedding similarity. This distinction makes the KB’s traversal recomputable: the traversal path is determined by the order structure and aspect bindings, both of which are registered artifacts, not by a graph whose edge weights may shift as the embedding model changes.

Traversibility as an autonomous-knowledge-acquisition property. Because the KB’s traversal is governed by the order structure and aspect bindings — and because both of these are registered, version-stable artifacts — an autonomous system can follow the order-decomposition tree from any entry point, acquire aspect-typed primitives that satisfy its declared purpose, and build new knowledge by composing acquired primitives under higher-order synthesis (§01 §11). The KB is not a static retrieval artifact; it is a navigable knowledge substrate that enables an autonomous system to acquire and build new knowledge within the bounds declared by the governing specification. The bounds are enforced by the aspect-activation rule and primitive-admissibility rule of any active perspective specification (§03-iii §2.9).

Aspect identifier structure. Co-indexing on aspect and order membership requires that each entry carry a non-nullable index field referencing an order-decomposition product — specifically, an aspect identifier issued by the domain model’s order-decomposition operation (§01). The aspect identifier is a structured identifier encoding: (a) the order type as defined in §01 (the domain’s declared functional dimensions — non-limiting examples: descriptive, prescriptive, procedural; the actual order types are those declared in the governing domain model), (b) the aspect’s position in the order-decomposition tree, and (c) the domain model version under which it was issued. Higher-order outputs are not order-decomposition products and do not carry aspect identifiers; they carry composition provenance records (§01 §11) as their identity anchor.

A store that uses arbitrary category labels, free-form tags, or UUIDs with category annotations on entries — even if navigable across multiple representations — does not constitute a co-indexed bidirectional store as defined here. The structured identifier encoding is required.

Primitive-level and subchunk-level retrieval. Retrieval and reasoning operate over aspect-typed primitives bound to source content. A typed primitive is located — by similarity or symbolic query — and then expanded along the metadata fabric to its related primitives, source spans, and aspects. The primitive is the unit of retrieval; the chunk is the substrate behind it. Within each chunk, the subchunk is the minimal semantically coherent span carrying the specific evidence. The metadata fabric indexes subchunks as first-class entries alongside primitives: each subchunk carries its subchunk identifier, its enclosing chunk identifier, its aspect binding, and its embedding vector identifier. Retrieval at the subchunk level is the default for evidence-gathering operations (§03-iii §2.4); chunk-level retrieval is available as a fallback but must be declared explicitly in the retrieval specification.

Embedding model and navigability. The embedded representation and metadata fabric may be optimized for navigability — the embedding model tuned such that the embedding geometry aligns with the order structure and aspect bindings. Controlled transformations (projection, re-weighting, reduction, quantization, re-ranking, prompt-conditioned re-embedding, learned transforms) may be applied to input or embedding to surface related traversal paths at optimized latency, compute, and cost. The admissibility conditions for controlled transformations used as traversal operations are specified in §3.2a.

3.2a Controlled embedding-space transformations

The embedded representation of the KB admits a class of operations called controlled embedding-space transformations: bounded, declarable operations on a vector in the embedding space that return a neighboring vector whose originating primitive is semantically related to the source. These are not post-hoc filtering or re-ranking operations applied to retrieval results; they are operations that navigate the embedding space directly, using the geometry of the space to surface related content without issuing a new similarity query.

Role in the KB. Controlled transformations are an operation over the KB’s embedded representation, not a traversal-time operation external to the KB. They require the bidirectional round-trip (§3.2) to be in place: the neighbor vector must carry an identifier that enables a direct lookup of its originating primitive in the symbolic store. Without that identifier, the transformation produces a vector position whose semantic content is unknown. The transformation is therefore a KB-layer operation, not a query-layer operation.

Admissibility conditions. A controlled embedding-space transformation T applied to vector e is admissible as a KB traversal operation if and only if:

Boundedness. The displacement is bounded under the KB’s declared distance function: D(T(e), e) ≤ δ, where D is the distance function declared for the KB’s representational space (non-limiting examples: Euclidean L2, cosine distance, hyperbolic distance, inner-product distance, or any other metric or pseudo-metric appropriate to the representation), and δ is a declared bound registered in the KB’s transformation configuration. D(·,·) is the general case; Euclidean norm (‖T(e) − e‖) is one admitted instance. The bound is not inferred from the result; it is a precondition on the operation.
Semantic coherence. The originating primitive of T(e) — retrieved via the bidirectional round-trip — is semantically related to the originating primitive of e. The semantic relation is measured by a declared semantic distance function d over the symbolic representations: d(prim(T(e)), prim(e)) ≤ ε, where ε is a declared semantic tolerance and prim(·) denotes the symbolic primitive retrieved via the round-trip identifier. The semantic distance function is declared at KB construction time and registered as a KB configuration artifact.
Interpretability bound. The transformation remains within the locally coherent neighborhood of e in the embedding space. The locally coherent neighborhood is the region in which the embedding geometry reflects semantic structure: vectors in this region are encodings of semantically related content. Transformations that exit this region produce vectors whose nearest-neighbor retrievals are semantically unrelated to e — the transformation has escaped the locally coherent neighborhood and is no longer a traversal operation. Formally: a transformation is within the locally coherent neighborhood if condition 2 (semantic coherence) holds for the declared ε. A transformation that satisfies condition 1 (boundedness) but not condition 2 (semantic coherence) is geometrically bounded but semantically inadmissible.

Mathematical bounding principle. In a well-structured representational space — whether a dense embedding space, a learned sparse space, a hyperbolic space, or any other representational geometry — semantically related content occupies a locally coherent neighborhood under the declared distance function D: the mapping from symbolic content to its representational encoding preserves semantic proximity within that neighborhood. A small displacement in representational space — one that remains within the locally coherent neighborhood under D — therefore returns to an entry whose originating content is semantically related to the source. As the displacement D(T(e), e) increases, the probability that the neighbor’s content is semantically related to the source decreases; at sufficient magnitude, the neighbor’s content is drawn from outside any semantically coherent neighborhood of the source under D, and the result is effectively random. The transition from semantically coherent to semantically incoherent is not sharp; it depends on the representational model, the domain, the declared distance function, and the density of the representational space in the relevant region. The declared bounds δ (displacement magnitude under D) and ε (semantic tolerance) together define an operating region within which transformations are reliable as traversal operations. Outside this region, the transformation is inadmissible.

This is the formal basis for the pondering mechanism of §03-iii §2.5(a): pondering is bounded traversal of the locally coherent neighborhood of the KB’s embedded representation. The rubik’s cube analogy is structurally accurate — small, controlled moves in a structured space return related positions; unconstrained moves escape the structured region and produce positions with no interpretable relationship to the start.

Embedder-migration state. The distance and semantic-coherence conditions above hold only among vectors produced by the same embedding model — the transformation record carries the embedding model version precisely because comparability is embedder-scoped, and cross-embedder comparison without a registered calibration mapping is foreclosed at the boundary (§02c NB1). An embedding-model upgrade therefore produces, mid-migration, exactly the foreclosed condition inside a single KB index: a partially re-embedded index holds vectors from two embedders whose displacements and neighborhoods are not mutually comparable. A single KB index containing vectors from two or more distinct embedder versions, with no registered cross-embedder calibration mapping covering the pair, is non-conforming: displacement bounds and semantic-coherence measures computed across the mixed vectors are undefined, and a traversal over such an index is not a governed traversal. Two migration disciplines are admitted: (a) atomic version cut — the index is re-embedded in full and the KB version advances as a single delta-attestation event, with no operating window in which the index is mixed; or (b) dual-index migration — the prior-embedder index and the new-embedder index are maintained as distinct registered indices during migration, each internally single-embedder, with cross-index operations governed by a registered calibration mapping (§02c Path B) exactly as for federated distinct-embedder stores. A traversal over a KB in migration records which index (and thus which embedder) each step drew from, on the same terms as §02c NB1 cross-store provenance. A deployment that operates a mixed-embedder single index without a registered mapping is refused at the transformation-configuration gate.

Traversal record. Each controlled transformation applied during KB traversal is recorded in the traversal trace component of the recomputation witness (§03-iii §2.7(i)): the transformation identity (declared operation type and parameters), the source entry identifier, the displacement magnitude D(T(e), e) computed under the KB’s declared distance function, the neighbor entry identifier, the semantic distance d(prim(T(e)), prim(e)) measured against the declared semantic distance function, the admissibility decision (within-neighborhood or inadmissible), the embedding model version identifier under which the source and neighbor vectors were produced, and the transformation configuration version (the version identifier of the registered transformation configuration artifact — δ bound, ε tolerance, and declared distance functions — under which the transformation was evaluated). A transformation recorded as inadmissible is not used as a traversal step; it is recorded as a boundary encounter in the traversal trace.

Relationship to §02a §4b governed traversal. Where KB traversal using controlled embedding-space transformations is performed as §02a §4b governed traversal — with declared traversal inputs, declared parameters, a steering-composition function, and navigating the KB’s metric space under the §02a §4b 5-condition structural invariant — the §02a §4b traversal witness requirements apply in full and are additive to the traversal record above. The §02a §4b traversal witness is a first-class registered artifact (§02a §4b.4) with its own minimum required fields including domain model version, governing spec version, steering-composition function, steering-conflict entries, and positions reached; it is distinct from the per-transformation traversal record in this section, which captures the embedding-space transformation details. Both records are produced simultaneously when §02a §4b governed traversal uses controlled embedding-space transformations as its navigational mechanism. In the §02a §5a.2 witness chain, the §02a §4b traversal witness link appears between the IR stage links and the analysis-act links; the per-transformation traversal records of this section are constituents of the traversal trace within that witness.

3.3 Map-governed chunking (Nucleus C)

The corpus is segmented into units governed by the domain model. This nucleus is independently practicable.

The boundary-indeterminacy problem and why the domain model solves it. Generic chunking strategies — fixed token count, sentence boundary, paragraph break, heading level — share a structural deficiency: they cannot determine when a semantically coherent piece of evidence spans a generic boundary. A prescriptive consideration may open mid-paragraph and close after the next heading. A procedural step may continue across a section break. A descriptive entity may be qualified by a constraint in a subsequent sentence that, under generic segmentation, lands in a different chunk. These are domain-structure facts: whether a span of text constitutes a complete piece of evidence of a given type is determined by the domain’s order structure, not by its surface formatting. Generic chunking methods have no access to that structure and therefore cannot place boundaries correctly — they split coherent evidence spans and merge incoherent ones, producing chunks that are either over-fragmented (evidence split across multiple chunks, requiring multi-chunk assembly at retrieval time) or under-specified (unrelated evidence merged into one chunk, increasing retrieval noise and hallucination surface). The domain model is the artifact that makes domain-structure facts knowable: its order-decomposition tree, aspect definitions, and order-typed primitive types specify exactly what a procedural step, a prescriptive consideration, and a descriptive entity are. Map-governed chunking applies this knowledge at boundary-placement time — which is the only time at which the placement can be corrected, because once content is chunked and embedded, the original boundary decision is encoded into the retrieval substrate and cannot be recovered without re-chunking. A post-hoc aspect annotation applied to chunks placed by a generic method is not the same as map-governed chunking: the annotation labels an already-misplaced boundary but does not correct the fragmentation or merging that occurred at placement time. The observable differentiator for an inspector is the subchunk structure: in a map-governed KB, each subchunk is expressed as a first-class entry with its own subchunk identifier and independently-produced embedding vector, generated simultaneously with the chunk during the construction-time act. A post-hoc annotator cannot produce first-class subchunk identifiers with independently-produced embedding vectors without re-chunking the content from scratch — reassigning annotation labels to generically-placed chunks does not produce independent subchunk vectors; it produces at most a slice or proxy of the enclosing chunk’s vector, which is not an independently-produced embedding. The inspector test is: does the KB contain subchunk-level entries with independently-addressable embedding vectors whose production timestamps and embedding model invocation records are contemporaneous with the enclosing chunk’s construction? A KB in which subchunk identifiers were assigned after the enclosing chunk was embedded — where the subchunk vector is a slice, projection, or proxy of the chunk vector rather than a vector produced by encoding the subchunk span independently — does not satisfy map-governed chunking as defined here, regardless of whether annotation labels appear at aspect or order transition points (S7).

Chunk boundaries. Primary chunk boundaries are placed at aspect or order transitions — where a procedural sequence begins or ends, where a prescriptive consideration opens or closes, where a descriptive entity is introduced or concludes — rather than solely at fixed token counts or generic structural cues (sentence boundaries, paragraph breaks, heading levels). The domain model determines what constitutes a meaningful boundary; the same corpus segmented under different domain models produces different chunk boundaries.

Map-governed chunking as construction-time act, not standalone segmentation. Map-governed chunking as specified here is the construction-time segmentation act that produces units for map-governed analysis into aspect-typed primitives (§3.1). A segmentation system that places boundaries at aspect or order transitions but does not feed those units into a map-governed extraction pipeline producing aspect-typed primitives organized along the orders of the same domain model is not practicing map-governed chunking as defined in this section. The segmentation and the analysis are governed acts of the same KB-creation pipeline under the same domain model; their governance is inseparable. A chunking system offered independently — without the aspect-typed primitive extraction and order-structured organization it is specified to feed — is a domain-aware segmentation utility, not a map-governed KB chunking operation under this section.

Chunk size is configurable. The target chunk size — expressed in tokens, characters, or semantic units — is an operator-declared configuration parameter. The domain model governs where boundaries are placed; the size parameter governs how much content is included within those boundaries. The two interact: a semantic boundary that falls within a declared size limit is honored; one that would exceed the limit may be deferred to the next eligible boundary or the size limit applied as a hard constraint, per the declared chunking policy.

Chunk size tradeoff. Smaller chunks yield higher retrieval precision: the returned span is tightly scoped to the relevant evidence, reducing irrelevant context presented to the consuming operation and generally reducing token usage per retrieval. However, if chunks are too small they may lose semantic coherence — splitting a single piece of evidence across multiple chunks — and increase the number of retrieval passes required to assemble sufficient context for a given operation. Larger chunks preserve more context per retrieval but include more content irrelevant to the query, increasing token overhead and the surface area for hallucination. The operator selects the chunk size that best suits the domain’s semantic density and the consuming operation’s context requirements. The subchunk structure (below) partially mitigates the tradeoff: a chunk can be larger while subchunk retrieval scopes the returned evidence to the minimal relevant span within it.

Subchunk expression. Within each chunk, the map identifies subchunks: the minimal semantically coherent spans that carry a single, identified piece of evidence bound to a specific domain aspect. A chunk may contain multiple subchunks bound to the same aspect (successive steps of a procedure, successive conditions of a consideration) or to adjacent aspects (a descriptive entity followed by a prescriptive constraint that applies to it). Each subchunk is expressed as a first-class unit in the KB: it carries its own subchunk identifier, its aspect binding, its order type, its enclosing chunk identifier, and its embedding vector identifier (when embedded). The subchunk is co-indexed in the metadata fabric alongside the chunk and the primitive (§3.2).

Multi-aspect spans. A corpus span may be simultaneously relevant to two or more aspects from the same or different orders — for example, a sentence that both describes a procedural step (procedural order) and asserts a constraint that governs that step (prescriptive order). The domain model’s order-decomposition tree makes this dual relevance detectable: the map identifies that the span satisfies the aspect criteria of both a procedural aspect and a prescriptive aspect simultaneously. In such cases, the span is expressed as two co-indexed subchunks — one bound to each aspect — sharing the same source span and the same enclosing chunk identifier, each carrying its own subchunk identifier, aspect binding, order type, and embedding vector identifier. The two subchunks may be retrieved independently by their respective aspect bindings; their shared source span is recoverable from their enclosing chunk. A map-governed chunking implementation that assigns only the dominant aspect to a multi-aspect span and discards the secondary — without expressing the secondary as a co-indexed subchunk — produces an incomplete KB: the secondary aspect’s evidence is present in the corpus but not navigable by its aspect binding, and evidence-gathering traversal under that aspect will not surface it. The domain model’s ability to identify multi-aspect spans at chunking time is a structural capability that generic chunking and post-hoc aspect annotation do not replicate: without the model’s simultaneous multi-order analysis at boundary-placement time, the secondary aspect binding is not detectable from the chunk alone.

Rationale: accuracy, hallucination reduction, token efficiency. Three properties follow from subchunk-level expression:

Accuracy. Retrieval at the subchunk level surfaces the specific evidence span rather than its enclosing chunk. A chunk that contains both the relevant evidence and surrounding context irrelevant to the query causes the model to attend to and potentially reason over the irrelevant context. Subchunk retrieval bounds the evidence to what is actually relevant.
Hallucination reduction. Irrelevant context within a retrieved chunk is a source of hallucination: the model may incorporate context-adjacent content as if it were evidence. Subchunk-level retrieval reduces the surface area of irrelevant content presented to the model.
Token efficiency. Returning a subchunk rather than its enclosing chunk reduces the token count of the retrieved context. For operations over many retrieved spans, this reduction composes: N subchunk retrievals at fraction f of their enclosing chunk sizes yield a token cost of f × N chunks rather than N chunks.

Non-language corpus chunking. Where a corpus item is non-language data — a figure, image, audio recording, tabular record, or structured record — it is first bound to a language-bound interpretation before chunking, as specified in §2. Map-governed chunking then operates on the language-bound interpretation using the same aspect/order transition rules as for text: boundaries are placed where the interpretation transitions between aspects or orders as identified by the domain model. The domain model governs boundaries on the interpretation, not on the native form; the native form is retained alongside the interpretation in the non-embedded store (§2) and is co-referenced from each derived chunk and subchunk. A chunking implementation that applies generic segmentation to the language-bound interpretation — placing boundaries at sentence or paragraph transitions in the interpretation without consulting the domain model’s aspect structure — is not practicing map-governed chunking on non-language content; it is applying the same generic boundary-indeterminacy problem to the interpretation that generic chunking applies to text. The domain model’s aspect/order transition rules are the operative boundary criterion regardless of the input modality.

Connection to subchunk retrieval (Impera). Map-governed chunking produces the subchunk structure that the Impera client class (§03-i §2.1a) is specified to retrieve. The subchunk identifiers, aspect bindings, and embedding vector identifiers produced during chunking are the metadata entries that Impera’s subchunk-level retrieval operates against. Map-governed chunking is the construction-time operation; Impera’s subchunk retrieval is the use-time operation. The two are coupled: subchunk-level retrieval is only possible when subchunks have been expressed and indexed as first-class entries at construction time.

3.4 KB lifecycle (Nucleus D)

Gap governance. All gaps emitted by KB operations — KB-locus gaps from absent primitives, consistency-failure gaps from unresolvable aspect identifiers, coverage gaps from self-diff — enter the canonical gap governance mechanism (§03-iii §2.0) at Open state. The gap record structure, authority procedure contract, closure witness, and permanence-declaration record defined there apply to all KB-locus gaps.

Dual-store sync invariant. The KB is always both a non-embedded store and an embedded store. These two stores are not independent: they are co-indexed by the metadata fabric, and their co-indexing is a structural invariant that must hold at all times. Any operation that adds, modifies, or retires a chunk or subchunk must update both stores atomically with respect to the metadata fabric: the non-embedded store entry and its corresponding vector entry in the embedded store must be in the same state (active, stale, retired, or pending-re-embedding) at any point at which the KB is available for use. The pending-re-embedding state is a permitted transient state — not a consistency violation — provided: the entry is excluded from similarity search, both stores are updated atomically when re-embedding completes, and the pending state is bounded to the duration of the declared re-embedding operation for the embedding model change event. A KB in which the non-embedded store and embedded store are in divergent states — one updated and the other not — is structurally inconsistent and may not be used for retrieval or traversal until the inconsistency is resolved. The metadata fabric is the consistency oracle: any entry present in one store but absent from the metadata fabric, or present in the metadata fabric but absent from one store, is a consistency violation.

Content-addressed versioning. Every registered version of the KB is identified by a stable, deterministic identifier computed over its full artifact — the symbolic store, the retrieval-indexed representation, the metadata fabric, and the accessor jointly — such that any change to any component produces a distinct identifier. No version is mutable. The prior version is retained in the specification registry as a historical record. The KB version identifier used in all downstream internal references (§03-i §2.6 composition records; §03-iii §2.7 traversal trace) is this content-derived identifier, not a monotonic counter. The form of the identifier — content hash, Merkle root, cryptographic commitment, or equivalent — is the licensee’s choice; the required properties are determinism, stability, and change-detectability.

Entry-level versioning and dual-store atomicity. A version event at the KB level is produced by one or more entry-level changes. An entry-level change — adding a chunk, modifying a primitive, retiring a subchunk — constitutes a single version event that updates both stores jointly. The non-embedded store entry and its corresponding vector entry in the embedded store are updated as one atomic operation with respect to the KB’s version record: the new KB version is not registered until both store updates are complete and the metadata fabric reflects the updated state. A partial update — one store updated, the other not — does not constitute a new version; it is an in-progress state that must not be exposed to consumers. This is the version-level expression of the dual-store sync invariant.

Each KB entry — primitive, synthetic variant, chunk, subchunk — carries an internal reference to the domain-model version, embedding model version, and corpus version under which it was produced. The domain-model version is encoded in the structured aspect identifier (§3.2); the corpus version is carried in the extraction record (see corpus versioning below); the embedding model version is a per-vector metadata field in the embedded store (see embedding model versioning below). These internal references are the index into any diff — model, embedding model, or corpus — that may affect the entry.

Corpus versioning. The corpus is a versioned input to the KB. Each corpus item ingested carries its citation and source location provenance (§2). The corpus as a whole at any point in time is identified by a corpus snapshot: a stable, deterministic identifier computed over the full set of ingested corpus item identifiers and their citation provenance records, such that any addition or modification to the corpus produces a distinct identifier. When new corpus is added, the prior snapshot identifier and the new snapshot identifier together with the set of added items constitute the corpus version event. The corpus snapshot identifier is carried in the extraction record of every primitive extracted from the corpus at that ingestion event. An inspector can determine which corpus snapshot a given KB entry was extracted from by reading its extraction record.

Corpus versioning is the operator’s choice in terms of mechanism: an operator using a document management system with built-in versioning uses that system’s version identifiers as corpus item identifiers; one managing corpus as files may use a VCS commit hash; one without either carries explicit snapshot identifiers. This Mars® specification requires that the corpus snapshot is identifiable and that the extraction record carries it; it does not require a specific versioning mechanism.

Embedding model versioning. The embedded store’s vectors are produced by a declared embedding model at a declared version. The embedding model identity and version are registered KB configuration artifacts enrolled in the delta-attestation lifecycle (§02b §5). Every vector entry in the embedded store carries the embedding model version under which it was produced as a metadata field.

When the embedding model changes — version upgrade, replacement, or parameter change — the new model produces vectors in a different embedding space. Vectors produced under the prior model and vectors produced under the new model are not directly comparable: similarity search across mixed-model vectors produces unreliable results. An embedding model change therefore triggers a full re-embedding obligation for all existing vector entries: every chunk and subchunk in the non-embedded store must have its vector re-produced under the new embedding model, and the metadata fabric updated to reflect the new vector identifiers. This is a scope-breaking configuration delta: it invalidates all existing similarity search results and traversal records that rely on cross-vector comparisons.

The re-embedding obligation is bounded to the embedded store; the non-embedded store entries (text content, metadata, provenance) are unaffected by an embedding model change and do not require re-extraction or re-chunking. The dual-store sync invariant requires that re-embedding complete atomically per entry: a chunk whose text entry exists in the non-embedded store but whose vector has not yet been re-embedded under the new model carries a pending-re-embedding marker and is excluded from similarity search until re-embedding completes.

Traversal records produced under a prior embedding model version carry that version identifier. An inspector can determine whether a recorded traversal step used vectors produced under the current embedding model by comparing the traversal record’s embedding model version against the KB’s current registered embedding model version.

Chunk size configuration versioning. The chunk size parameter (§3.3) is a registered KB configuration artifact with its own version identity, enrolled in the delta-attestation lifecycle (§02b §5). When the chunk size changes, existing chunks produced under the prior size parameter are not automatically re-chunked: they carry their original chunk size as a metadata field and remain valid entries in the KB. New corpus ingested after the configuration change is chunked under the new size parameter. The KB may therefore contain chunks of different sizes produced under different configuration versions; each chunk’s metadata carries the configuration version under which it was produced.

Where the operator requires a uniformly-sized KB — all chunks produced under the same size parameter — a full re-chunking of the existing corpus under the new configuration is required. Re-chunking produces new chunk identifiers, new subchunk identifiers, and new vector embeddings for all re-chunked content; this constitutes a KB version event equivalent in scope to a full corpus re-ingestion. The dual-store sync invariant applies: re-chunked entries must be updated in both stores atomically.

Domain-model amendment → KB diff-and-match → scoped recomputation.

Where multiple domain models are active, each domain model version carries its own registered artifact identity and its own delta-attestation chain; a KB built against one domain model version is not affected by an amendment to a different domain model version. The diff-and-match below is scoped to the specific domain model version under which the affected KB entries were produced, as encoded in their aspect identifiers (§3.2).

When a domain model is amended, the KB does not reprocess its full contents. The amendment produces a typed structural-difference record (§01 §9) enumerating changed nodes — added aspects, removed aspects, modified aspects, repositioned aspects. The KB executes a diff-and-match in two steps:

Match. For each changed node in the structural-difference record, retrieve all KB entries whose internal aspect identifier references that node. This produces the affected set: the exact entries that are potentially stale. Entries whose aspect identifiers reference only unchanged nodes are not in the affected set and require no reprocessing.
Classify and act per entry in the affected set. The action depends on the nature of the change to the referenced node:

Model change at referenced node	Action on affected KB entries
Aspect added (new node in order-decomposition tree)	No existing entries affected. New aspect has no primitives yet; an extraction pass is required against the existing corpus to populate primitives for the new aspect. Absence of primitives for a newly declared aspect emits a KB-locus gap in the multi-locus gap report.
Aspect removed	All primitives, variants, chunks, and subchunks bound to the removed aspect are retired: marked inactive in the symbolic store, excluded from similarity index queries, retained as archived records with their aspect identifier marked tombstoned. Both stores are updated atomically per the dual-store sync invariant. Downstream query library entries referencing these entries are flagged stale (§03-i §2.6).
Aspect modified (scope narrowed or widened)	Primitives bound to the aspect are re-evaluated against the amended aspect definition. Primitives that no longer satisfy the amended scope are retired. Primitives newly admitted by a scope widening are candidates for extraction from the existing corpus. Modified aspects trigger re-generation of synthetic variants derived from affected primitives.
Aspect repositioned (moved within order-decomposition tree)	The aspect identifier encodes position; repositioning changes the identifier. Affected entries have their aspect identifiers updated to the new position. No re-extraction is required if content is unchanged; the metadata fabric’s index over aspect identifiers is rebuilt for the affected entries. Downstream artifacts carrying the prior-position identifier are matched and their references updated or flagged for re-derivation.

The recomputation obligation is bounded to the affected set. The remainder of the KB is provably unaffected and is consumed from the existing version without re-derivation.

KB self-change → self-diff → model-match → consistency enforcement.

When the KB changes independently — new corpus ingested, primitives added or revised, subchunks re-expressed — the change produces a new KB version. Before the new version is registered, a self-diff is computed: the new version is compared against the prior version to produce a typed entry-level structural-difference record enumerating added entries, removed entries, and modified entries (by primitive identity and aspect identifier).

The self-diff is then matched against the current domain model version:

Consistency check. For each added or modified entry in the self-diff: verify that the aspect identifier carried by the entry is a valid aspect in the current domain model version (position exists in the order-decomposition tree, order type matches). An entry carrying an aspect identifier that does not resolve in the current model is a consistency failure — it is admitted with a consistency-failure marker and emits a KB-locus gap.
Coverage update. The self-diff’s additions and removals update the KB’s coverage record: which aspects have primitives, how many, and at what provenance depth. Coverage changes are propagated to the multi-locus gap report (§03-i §2.4) and to any registered downstream consumers of the KB’s coverage record.
Downstream propagation. The entry-level self-diff is used to scope downstream recomputation obligations across all artifact types that carry references to KB entries:
- Query library entries (§03-i §2.3) whose composition records declare a KB traversal input from the prior KB version are matched against the self-diff: if the KB entries consulted during their construction are in the self-diff’s changed set, those library entries are flagged for re-evaluation. Library entries whose consulted KB entries are not in the changed set are unaffected.
- Higher-order outputs and governing specifications whose composition provenance records (§01 §11) declare KB primitives as declared inputs are matched against the self-diff by KB entry identity. A higher-order output referencing a changed KB entry enters a conditionally-attested state and is added to the recomputation obligation set. Re-synthesis executes only over the changed portion of the KB input; KB entries whose identity is unchanged are consumed from the existing version.
- Governing specifications derived with KB traversal input carry the KB version used at derivation time. A KB version increment triggers a staleness check against those specifications: if the KB entries they were derived from are in the self-diff’s changed set, the governing specification is flagged pending-re-evaluation under the updated KB version.

Incremental extraction for new aspects and corpus additions.

Extraction is not all-or-nothing. When a new aspect is added to the model, extraction runs against the existing corpus scoped to that aspect alone — not the full corpus. When new corpus is added to the KB, extraction runs against the new corpus scoped to all current aspects — not re-extracting from the existing corpus. The aspect identifier is the key that scopes both directions: model-driven and corpus-driven.

The extraction record for each primitive carries: the corpus span from which it was extracted, the aspect identifier under which it was extracted, the domain-model version active at extraction time, the corpus version (a content hash of the corpus snapshot), and the embedding model version under which the original vector for this entry was produced. This five-part provenance is sufficient to re-derive the extraction without re-running full corpus processing.

Versioning of configuration artifacts. The KB’s transformation configuration (δ and ε bounds for controlled embedding-space transformations — §3.2a) and the declared semantic distance function are registered artifacts with their own version identities, enrolled in the delta-attestation lifecycle (§02b §5). When the δ bound is tightened, the structural-difference record for the configuration artifact enumerates the bound change. Traversal records produced under the prior (wider) bound are not retroactively invalidated; they carry the configuration version under which they were produced, and an inspector can verify whether any recorded transformation would be inadmissible under the current (tighter) bound. A configuration amendment that would reclassify prior traversal steps is a scope-restricting delta on the configuration artifact.

Synthetic variant provenance and incremental regeneration. Synthetic variants carry a two-part provenance: (a) source-span provenance inherited from their originating primitive, and (b) derivation provenance recording the aspect identifier and domain-model version under which they were generated. On model amendment, variants in the affected set (those whose derivation provenance references a changed aspect) are scheduled for regeneration. Regeneration executes per-variant, not per-KB: each variant is regenerated independently under the amended aspect definition and domain-model version. Stale variants remain queryable but carry a staleness marker and a reference to the prior derivation provenance until regeneration completes and produces a new version with updated derivation provenance.

Conflict resolution in merge applies derivation provenance: variants derived under the same aspect from the same source span at different domain-model versions are resolved by retaining the variant generated under the later version, with the superseded variant archived.

Merge and conflict resolution. Two or more knowledge bases, or a KB and new analysis, may be merged. The merge produces a self-diff of the merged result against each input KB. Conflict resolution applies the internal reference index: entries with the same aspect identifier and overlapping source span are conflict candidates.

Symbolic conflict resolution. For symbolic entries (primitives, variants, chunks, subchunks), resolution retains the entry generated under the later domain-model version, with the superseded entry archived.

Embedded representation conflict resolution. Where two input KBs have independently embedded the same source span — whether under the same or different embedding models — the resulting vector entries may carry colliding identifiers (both referencing the same symbolic primitive) or divergent vectors (produced under different models). The metadata fabric cannot hold two active vector entries with the same symbolic primitive identifier without violating the bidirectional round-trip property. The operator declares a conflict-resolution policy for embedded conflicts, selecting from the following admitted resolution modes:

Resolution mode	Behavior
Pass with warning	One vector entry is retained (selected by the declared tiebreak rule: later embedding model version, or higher fitness score if available); the superseded entry is archived; a conflict record is written to the merge provenance record and flagged for inspector review
Block as error	The merge is halted; the conflict is surfaced as a merge-blocking error requiring explicit resolution before the merge can be registered as a new KB version
Programmatic simulation	Both vector entries are retained temporarily; a declared simulation procedure is run to assess their relative fitness (e.g., retrieval accuracy against a held-out query set); the higher-fitness entry is retained and the other archived; the simulation result is recorded in the merge provenance record
Autonomous re-analysis	The conflict is resolved by re-embedding the source span under the current declared embedding model, producing a new vector entry that supersedes both conflicting entries; the re-embedding is recorded as a new extraction event in the merge provenance record; an optional verification flag may be set to require inspector sign-off on the re-embedded entry before the merged KB is released for use

The four modes above are non-limiting examples. An operator may declare any conflict resolution procedure — including hard-coded rules, deterministic tiebreak functions, third-party adjudication services, or custom programmatic logic — provided the procedure is: (a) declared and registered as the KB’s merge policy before the merge is executed, (b) enrolled in the delta-attestation lifecycle so that changes to the resolution procedure are versioned, and (c) its decision for each conflict recorded in the merge provenance record. The contract is the declaration, registration, and recording; the implementation is the operator’s choice.

A merge that does not declare a resolution procedure defaults to Pass with warning. Regardless of resolution procedure, every conflict and its resolution decision is recorded in the merge provenance record. A merged KB is a first-class artifact with its own content-hash version identifier and provenance record declaring the input KB versions, the conflict instances, the resolution procedure applied, and the resolution decisions.

Portable package. The knowledge base is packageable as a portable, self-contained artifact comprising the symbolic store, the embedded index, the metadata fabric, the extraction records, the configuration artifacts, and an accessor for direct or hosted consumption. The package version identifier is the KB content hash. This is the form in which a KB is delivered as a licensable product.

← Inputs and corpus characterization · Section index · Outputs →