§03-i Minerva — Semantic Binding — Semantic binding

Mars® Spec › §03-i Minerva — Semantic Binding › Semantic binding

← What this section covers · Section index · Outputs →

2. Semantic binding

2.1 Inputs and substrate uniformity

Semantic binding takes three inputs.

One or more characterized data sources. Structural metadata (“metadata-1”): entities, tables, collections, fields, types, keys, and statistics per source. Each source is characterized independently; the characterization may be native to the source (where the source is self-documenting) or produced by the structural characterization procedure (§2.1b) where it is not. Multiple sources are admitted and processed in parallel; the semantic-map artifact and query library span all characterized sources jointly.

Data source admission criterion. A data source is eligible for semantic binding if and only if it satisfies one of the two declared client contracts appropriate to its class (§2.1a): the connect/traverse/query contract (non-embedded sources — Pymnemon) or the connect/encode/decode contract plus the subchunk-level retrieval commitment (embedded sources — Impera). The connect/traverse/query contract requires: a stable declared connection interface, the ability to enumerate structure (schemas, collections, fields, or equivalent), and execution of structured queries over content returning typed results. The store type, hosting topology, and content modality are not admission criteria. Non-limiting examples of admitted store types: relational (SQL), document (NoSQL), key-value, object, graph, vector. Both embedded and non-embedded sources are admitted; these are distinct client classes with distinct structural contracts (§2.1a).

Domain model (“the map”) — one or more. The governing reference: one or more multi-order, multi-perspective, multi-variant models from §01 — their orders (functional dimensions), stakeholder perspectives, declared variants, and domain aspects (the order-decomposition products that are the structural primitives of each model). Multiple domain models may be active simultaneously; each is composable and independently operable (§01 §1). Semantic-map entries and query library entries are scoped to the specific domain model version that governed their derivation; a change to any active domain model propagates staleness only to entries derived under that model version.
One or more knowledge bases (optional). Where a KB is provided as input, it must be a previously-committed version, identified by its version identifier from §03-ii §3.4. A KB whose construction is in-flight in the same pipeline pass as the current semantic binding operation may not be used as input. This prevents circular input dependencies within a single pass. Iterative refinement across passes is permitted and governed by the KB versioning and incremental update mechanism.

Substrate uniformity (Property S5). A data source may be a relational database, object store, document, key-value, graph, vector, time-series, columnar, streaming, or any other store type satisfying the admission criterion appropriate to its client class (§2.1a); embedded or non-embedded; federated, unified, or disparate — including any combination of content modalities and embedding models. The enumeration of store types above is illustrative and non-limiting. Multiple sources of different types may be provided simultaneously. The downstream semantic-map artifact and query library operate identically across all substrate forms and across all combinations of sources. This invariance is an architectural commitment, not an implementation convenience.

Data source metadata is a property of the data source, built and versioned against the governing domain model. The structural characterization (“metadata-1”) and the semantic-map artifact (“metadata-2”) produced by semantic binding are not domain-agnostic descriptions of the data source — they are expressions of the governing domain model applied to the data source’s structure and content. The domain model’s orders, aspects, and perspectives determine what the characterization looks for, how fields are interpreted, and what bindings the semantic map produces. A data source’s metadata is therefore versioned jointly with the domain model version under which it was produced: a change to the governing domain model that affects the bound aspects invalidates the corresponding metadata entries and triggers scoped recomputation per §2.6. Two characterizations of the same data source produced under different domain model versions carry structurally distinct metadata and are not directly comparable without a model-version reconciliation step.

Observation-over-time telemetry as a data source variant. Observation-over-time telemetry — time-series operational signals, event logs, monitoring streams, behavioral traces, and equivalent time-stamped observational records — is a variant of data source admitted under the same semantic binding pipeline as any other data source. It satisfies the connect/traverse/query contract (non-embedded) or the connect/encode/decode contract (embedded) per §2.1a; the distinction is its temporal structure, which the domain model’s temporal or procedural orders govern. Temporal gating (§2.3) is the primary mechanism for scoping telemetry retrieval to declared time windows. Telemetry may participate in all semantic binding operations, query library construction, and higher-order synthesis on equal footing with other data source types.

Bootstrapping the domain model from data sources and observation-over-time telemetry. When a governing domain model is absent, it can be bootstrapped from one or more data sources or observation-over-time telemetry inputs. Bootstrapping proceeds by applying the corpus-seed mode of §01 §3 to the available data sources: the structural characterization procedure (§2.1b) is run first to produce “metadata-1,” and the upward interpretation phase is then applied without a pre-existing domain model — instead, the structural signals (field names, value distributions, inter-field relationships, temporal patterns in telemetry) are used to derive candidate orders, aspects, and perspectives that constitute the bootstrapped domain model. The bootstrapped model is a first-class registered artifact enrolled in the delta-attestation lifecycle (§02b §5). Once registered, it governs data source metadata construction identically to an externally-provided domain model, and the semantic binding pipeline proceeds normally under it. Iterative refinement is permitted: the bootstrapped model may be refined across passes as additional data sources or telemetry are introduced, with each refinement producing a new registered domain model version.

2.1a Non-embedded and embedded data source client classes

Non-embedded and embedded data sources are two structurally distinct client classes. The distinction is not a storage property; it determines the connection interface, the query mechanism, the result type, and the accuracy requirements of retrieval. Each class is implemented by a Causum client project that is governed by its own project specification; only the Mars® contract requirements are stated here.

Non-embedded data sources — Pymnemon contract. A non-embedded data source stores content in structured, human-interpretable form: rows, documents, key-value pairs, object records, graph nodes and edges. Retrieval is by structured query returning typed, discrete results. Mars® requires that the client for a non-embedded source satisfy the connect/traverse/query contract: it must expose a stable declared connection interface, enumerate the source’s structure (schemas, tables, collections, fields, and types), and execute structured queries over content returning typed results. The Causum Pymnemon project (gitlab.com/causum/pymnemon) is the reference implementation of this contract. A non-embedded source accessed through a Pymnemon-conforming client is structurally interchangeable in the semantic binding and query library operations regardless of the underlying store type. Licensees may implement the contract independently — through a unified client library, a collection of native per-store clients, or any other arrangement of the licensee’s choice — provided conformance with the connect/traverse/query contract is maintained. Mars® requires the contract, not any specific client implementation.

Embedded data sources — Impera contract. An embedded data source stores content as vectors in an embedding space. Retrieval produces ranked results from the embedding space by a declared similarity or proximity measure. Mars® requires that the client for an embedded source satisfy the connect/encode/decode contract and commit to retrieval at the subchunk level: the returned unit is not the chunk (the segment encoded as a unit) but the subchunk — the minimal semantically coherent span within a chunk containing the specific supporting evidence. Retrieving the enclosing chunk inflates token overhead and admits irrelevant intra-chunk context. The Causum Impera project (gitlab.com/causum/impera) is the reference implementation; it governs federation across multiple vector stores, embedding model management, metadata co-indexing, and subchunk-level retrieval accuracy. Impera’s project specification is the authoritative source for those mechanisms; what Mars® requires here is the subchunk-level retrieval commitment and the connect/encode/decode interface. Licensees may implement the contract independently — through a unified client, a collection of native per-store clients, or any other arrangement of the licensee’s preference — provided the subchunk accuracy commitment and structural contracts are met.

Subchunk retrieval accuracy gap in current evaluations. State-of-the-art retrieval evaluation benchmarks — including BEIR, MTEB, and standard RAG evaluation harnesses — measure retrieval quality at the chunk level: whether the correct chunk appears in the top-k returned results. They do not measure whether the specific subchunk containing the supporting evidence was identified and returned. The Mars® subchunk-level retrieval commitment is not captured by current standard evaluation measures. Evaluation of subchunk accuracy requires a benchmark instrumented at the subchunk level; the governed benchmark generation mechanism (§03-iv §3) is the operative path for producing such a benchmark.

2.1b Structural characterization procedure

Where a data source is not self-documenting — its field names are obfuscated, abbreviated, or otherwise non-interpretable without context — the structural characterization procedure produces the characterization input for semantic binding. It is a two-phase operation.

Phase 1 — Structural inventory. The system enumerates the source’s structure through the connect/traverse/query contract:

A flat list of all schema, table, collection, index, or equivalent structural unit names present in the source, per the source’s schema model.
For each table, collection, index, or equivalent structural unit: a list of field names or equivalent element identifiers, the declared type where available (from schema metadata), and a sampled type where the declared type is absent or generic (derived from a bounded sample of field values).
For each field: summary statistics where computable from the sample (cardinality estimate, null fraction, value distribution sketch, min/max for ordered types). These are not required where the store type or access permissions do not support sampling.

The structural inventory is the characterization substrate — “metadata-1.” It is produced from the source alone, without consulting the domain model.

Phase 2 — Upward interpretation. The domain model is applied to the structural inventory to derive meaning from available signals:

Name-quality assessment. Field and table names are evaluated for interpretability: fully spelled-out names with recognizable vocabulary are high-quality; abbreviated, numeric, or encoded names are low-quality. Low-quality names reduce the binding confidence of any domain-aspect assignment derived from them.
Value-sample interpretation. Sampled values are inspected for format patterns (dates, identifiers, currency amounts, codes, free text) and for vocabulary overlap with the domain model’s aspect vocabulary and order-typed terms. A field whose sampled values match a domain aspect’s characteristic value vocabulary is a candidate binding even if its name is uninformative.
Inter-field relationship inference. Key fields, foreign-key-like patterns, and co-occurrence patterns in sampled rows are used to infer relationships between fields and tables. These inferred relationships are recorded in the characterization as candidate joins and are forwarded to semantic binding as hints rather than asserted facts.
Upward refinement. Where name quality is low and value sampling is uninformative, the system may emit a hint request: a structured prompt to the operator (a human expert, a domain-knowledgeable model, or a registered hint source) requesting disambiguation for a specific field or table. The hint and its source are recorded in the characterization alongside the field entry. A characterization that contains unresolved low-quality fields emits a data locus gap for each such field in the multi-locus gap report (§2.4).

The characterization produced by this procedure is a registered artifact carrying: the source identity and version, the inventory timestamp, the domain-model version under which Phase 2 was run, the name-quality assessments, the inter-field relationship hints (inferred joins, key relationships, and co-occurrence patterns) produced by Phase 2, and for each field where a hint request was emitted, the hint text and declared hint source timestamped. It is subject to staleness on data-source schema change (see §2.6).

2.2 Map-governed semantic binding (Nucleus A)

Function inference. Governed by the domain model, the system infers the function and meaning of non-self-documenting data-source structure by relating structural metadata — field names, types, keys, sampled values, inter-field relationships — to the model’s orders, perspectives, and vocabulary. The domain model determines what functions to look for and how to interpret obscured structure. This is not generic schema description; the governing reference is the distinction.

Domain-aspect binding → the semantic-map artifact (“metadata-2”). The system binds data-source fields and entities to domain aspects of the model, recording per bound element: its domain role, the perspectives it participates in, and its participation in specific tasks, procedures, questions, considerations, and validations. The result is the semantic-map artifact: an external metadata layer joining data-source structure to the model’s aspect vocabulary. It may include multi-dimensional views (by perspective, by consideration, by validation, by activity) and inferred relationships and keys.

What a domain aspect is, and what it is not. Binding to domain aspects — not to ontology classes or free-text descriptions — is the load-bearing distinction. A domain aspect is an order-decomposition product: its identity and membership boundaries are defined by the order-decomposition operation of §01 (modeling), not by taxonomic classification. An aspect’s membership criteria are procedurally derived from the order structure of the domain model. They are not defined by necessary-and-sufficient conditions on field properties.

An annotated ontology class that carries role, perspective, or task attributes but whose membership is defined by taxonomic necessary-and-sufficient conditions does not constitute a domain aspect. Attaching role labels to ontology classes is not map-governed semantic binding.

Access substrate as admissibility criterion, not independently claimable artifact. The connect/traverse/query contract (non-embedded sources) and the connect/encode/decode contract plus subchunk commitment (embedded sources) are admissibility criteria for the semantic binding operation: they define which data sources may enter the binding pipeline. The access substrate — the client, connector, or interface that satisfies the contract — is not independently claimable as a separable artifact from the semantic binding operation it feeds. A connect/traverse/query client that does not feed a domain-aspect binding operation is a data-integration component, not a governed semantic binding substrate. A domain-model-governed self-characterization procedure (§2.1b) that does not feed a domain-aspect binding is a schema inference procedure, not governed characterization. The domain-model governance of the self-characterization and the domain-aspect binding of the semantic map are inseparable: the governed characterization is governed by the same domain model that governs the binding, and the two are governed acts of the same artifact-production pipeline. An implementation that separates the access substrate from the binding pipeline — offering the governed self-characterization as a standalone schema-inference service without the domain-aspect binding — is not practicing governed semantic binding as defined in this section.

2.3 Aspect-keyed query library (Nucleus B)

Query generation inputs — domain mapping and KB traversal. Query generation draws from two input sources, usable individually or in combination: the domain model alone, a knowledge base traversal alone, or both together. Neither is required to the exclusion of the other; the number of each is not limited.

Domain mapping alone. The domain model’s orders, aspects, and perspective-constituted relational elements supply the governing vocabulary and structure. The query is constructed from aspect-bound field mappings in the semantic map without consulting any KB.
KB traversal alone. The KB’s aspect-typed primitives are traversed to acquire contextual metadata about an aspect: what the aspect is (descriptive primitives), why it matters (prescriptive considerations), when it applies (temporal or procedural scope), and how it is used (procedural steps and relations). This contextual metadata governs query construction: the query is built to retrieve data that fulfills the aspect’s role in the domain model’s aspect structure. A KB used alone as the query-generation input must be structured under the same domain model (or a compatible version) as the semantic-map artifact.
Domain mapping and KB traversal combined. The domain model provides the structural skeleton; KB traversal enriches each aspect’s query with the contextual metadata (what, why, when, how) that makes the query semantically specific rather than structurally general. This combination produces the highest-fidelity queries.

Query body — declared executable expression per client class. The query body in a library entry is a declared, executable query expression in the form appropriate to the source’s client class. For a non-embedded source (Pymnemon contract), the query body is a structured query expression executable via the connect/traverse/query contract: a SQL statement, filter specification, aggregation pipeline, graph traversal expression, key-value lookup, or equivalent structured form. For an embedded source (Impera contract), the query body is an encoding specification: what to encode (the declared input text or representation), under what embedding model version, at what retrieval granularity (subchunk-level commitment per §2.1a), and with what similarity measure and top-k parameters. The two client classes produce structurally distinct query body forms; a library entry carries the client class identifier of the source it targets, and its query body must conform to the declared form for that class. A query body that does not conform to the declared form for its source’s client class does not constitute a query library entry under this section — it is an unstructured retrieval instruction, not a governed query expression.

Embedded-source query entry. A query library entry targeting an embedded source (Impera) carries, in addition to the common composition record fields: the encoding specification (the declared input representation to be encoded — the domain aspect’s characteristic query surface, expressed as a text or other encodable form); the embedding model identity and version in effect at construction time (distinct from the KB’s current embedding model version, which may have advanced; staleness is detectable by comparison); the similarity measure and top-k parameters declared for this entry; and the subchunk-level retrieval commitment (the entry asserts that retrieval will return subchunks, not enclosing chunks, per the Impera contract). A change to the embedding model version is a staleness event for embedded-source entries: the encoding of the query surface under the prior embedding model is not comparable to vectors produced under the new model, and the entry must be re-evaluated under the new model before it may be used as evidence.

Query construction discipline — simple queries over complex queries. Two construction strategies are admitted:

Single-table/collection queries. A query targets one table, collection, or index at a time. These are structurally simpler, more robust under schema variation, and easier to validate. A collection of single-table queries bound to the same domain aspect may stand in for one complex composite query — and in general yields better flexibility, lower brittleness, and more predictable results, at the cost of a higher query count.
Composite queries. A single query spans multiple tables, collections, or indexes through joins, aggregations, or nested sub-queries. These are more expressive but more brittle: schema changes, key mismatches, or optimizer behavior can silently produce incorrect results. Composite queries are generated through a governed iterative construction-and-validation process that builds and tests the composite structure under the domain model’s constraints.

The simple-query strategy is preferred. The composite-query strategy is available where the domain model’s relational structure requires it and the fitness-validation mechanism can confirm correctness.

Cross-source query coordination. The query library is indexed by domain aspect: multiple entries bound to the same domain aspect may target different sources. At use time, the reverse-path selects all entries bound to the activated aspect(s), across sources, subject to fitness rank and temporal gating. Cross-source findings — correlations, discrepancies, patterns not present in any single source — are produced by executing the selected entries across their respective sources and combining the results as declared inputs to higher-order synthesis (§01 §11). The query library is the governed access layer for this cross-source composition: it supplies the per-source query expressions; the composition and attribution join are performed at the higher-order synthesis and attribution layers (§03-iii §2.12). An implementation that performs cross-source retrieval by directly joining query results post-hoc on arbitrary keys — without routing through the aspect-keyed query library and the attribution join — is not practicing governed cross-source query coordination as defined here. The aspect-keyed indexing is what makes the cross-source composition governable and independently recomputable. The observable test for governed cross-source coordination is the reverse-path activation record (§2.3, S14): every downstream verification evidence record for an operation claiming governed cross-source query coordination must carry a conforming activation record naming the activated domain aspects, selected library entry identifiers, and governing upstream versions. An operation whose evidence record lacks a conforming reverse-path activation record does not demonstrate governed cross-source coordination regardless of how its query results were labeled or routed — including where a nominal query library entry was inserted post-hoc to label results already joined by other means. The activation record is not a provenance annotation; it is a structural requirement that makes the fork observable and independently testable by an inspector.

Operational task binding and time-gating. A query library entry may be bound to a declared operational task: a named governance, verification, or certification operation for which the query is the appropriate data-acquisition mechanism. The binding declares: the task identity, the aspect(s) the query serves within that task, the purpose and objective of the query within the task context, and any temporal or relational constraints that gate the query’s validity.

Temporal gating. A query entry carrying a temporal gate is valid only when the gating condition is satisfied at the time of execution. Temporal gates are non-limiting in form: they may declare a time window, a recency bound (data must have been produced within N time units of the operation), a cadence constraint (the query must be re-executed at a declared interval), or a relational temporal constraint (the data’s timestamp must satisfy a declared relationship to another element’s timestamp). A temporally-gated query executed outside its declared gate is not admitted as evidence in the governing operation; it is recorded as a time-gate-miss in the multi-locus gap report with locus data.

This binding enables the query library to function as a governed context-acquisition mechanism for operations that require data at a declared temporal resolution — for example, a certification operation that requires current-state data rather than cached or stale data.

Sample-data validation and fitness signal. Each generated query is executed against sample data — live, historical, analytical, pre-captured, or equivalent, per the licensee’s preference and the nature of the data source. The system records an execution outcome (at minimum: validity, row count, and sample rows, or equivalent indicators for the source type) and derives a fitness signal from it. On failure, the query is repaired under a bounded repair loop whose maximum iteration count is a named registered parameter with library-level scope; each query library entry carries the value of this parameter that was in effect during its construction.

The fitness signal is a structured record in the value domain {validity: boolean, row_count: integer, sample_rows: list} (or equivalent indicators for the source type), derived from the recorded execution outcome. It is a labeled attribute of the library entry. It is not a construction gate. The fitness threshold is a named registered parameter with library-level scope; each library entry carries both its fitness score and the threshold value that was in effect at construction time. An entry whose fitness falls below the declared threshold is admitted to the library with its fitness score recorded, and a corresponding gap is logged to the multi-locus gap report (§2.4). If fitness does not converge within the repair bound, the entry is committed with its best-achieved score and a gap is emitted. Rejection-on-failure is not the mechanism; admission-with-scored-gap is.

Composition record and aspect binding. Each library entry carries: a stable entry identifier (a content-derived hash of the query body, domain aspect identifier, and source identity tuple, whose hash algorithm is a declared registered parameter; the identifier must be stable across re-use of the same entry and must change when the entry is re-generated under a new upstream version); the identity of its domain aspect, the source identity, a composition record declaring which perspectives participate, which keys are joinable, and which related procedures apply; the construction strategy (single-table or composite); the list of specific KB primitive identifiers (aspect-typed primitive keys) consulted during KB traversal for this entry’s generation, where KB traversal was used (null otherwise); the traversal witness link(s) (§02a §4b.4) for any governed traversal (§02a §4b) used during query generation — null where KB traversal was not used or did not involve §02a §4b governed traversal; the formal specification version(s) of any formal specifications (lowered from a domain model and enrolled in the delta-attestation lifecycle) that were resident in the KB and whose primitives were consulted during KB traversal (null where not applicable); the operational task binding (if declared); and any temporal gate condition. The library is indexed by domain aspect, not by consumer request.

KB traversal and §02a §4b governed traversal. Where KB traversal during query generation 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 5-condition structural invariant — the §02a §4b traversal witness requirements apply in full. The traversal witness is a first-class registered artifact produced by that traversal act; its link is required in the composition record. The witness chain for a query library entry generated via governed KB traversal is: [KB traversal witness link(s)] → [query construction act link] → [library entry registration link]. A query library entry whose composition record does not carry the traversal witness link where §02a §4b governed traversal was used does not satisfy the re-derivability requirement of this section.

Evolvability. The library is built upfront and evolves. Entries are added, reinforced, improved, updated, or deprecated in response to gap-report findings, domain-model amendment, data-source change, or new sample-data evidence. It is not a static lookup table.

Fitness signal without aspect-keyed library admission is not Nucleus B. The validate-and-repair mechanism for generated queries — executing a query, detecting failure, repairing under a bounded loop, and re-executing — is a known technique. The inventive element is the use of that mechanism to derive a fitness signal that scores and admits a query into a persistent, domain-aspect-indexed library, where the library entry is keyed to the domain aspect, not to the individual request that triggered the query. A system that validates and repairs queries per-utterance — producing a fitness signal but not admitting the query into a domain-aspect-indexed persistent library — is not practicing the aspect-keyed query library as defined here. The fitness signal is an attribute of the library entry; a fitness signal that is not an attribute of a domain-aspect-indexed library entry is not a governed fitness signal under this section. Similarly, a per-utterance query cache indexed by utterance rather than by domain aspect, even if it carries fitness scores, does not constitute an aspect-keyed query library and does not close the fork.

Reverse-path use. At use time, a request is reverse-pathed through the domain model — and optionally through knowledge bases — to one or more domain aspects. Those aspects index the semantic map and query library. A library entry is selected and ranked by fitness signal, filtered by any applicable temporal gate. The reverse-path is available to any consuming operation at the query-generation layer.

Reverse-path activation record. Each reverse-path activation at use time produces a typed activation record that is carried as part of the evidence record in the recomputation witness (§03-iii §2.7(ii)) of any downstream verification operation that consumed the selected library entries. The activation record declares at minimum: a stable content-derived identifier for the request (such as a content hash or equivalent stable identifier); the domain aspect(s) activated (by structured aspect identifier from the order-decomposition tree); the selection rationale (fitness rank, temporal gate status, and whether KB traversal contributed to the aspect selection); the library entry identifiers selected; the governing domain-model version and KB version (if KB traversal was used) at the time of activation; and the traversal witness link(s) (§02a §4b.4) for any §02a §4b governed traversal performed at use time as part of the reverse-path KB traversal step — null where no §02a §4b governed traversal was used. Additional provenance fields may be included at the licensee’s discretion. A verification operation that consumed query library entries but carries no activation record in its evidence record does not satisfy the re-derivability requirement of §03-iii §2.7.

Data source retrievals as input to higher-order synthesis. Query results retrieved from data sources via the query library are admissible as declared inputs to higher-order synthesis (§01 §11). A higher-order synthesis act may declare query results — from one data source, from multiple data sources in combination, or from data sources combined with KB traversal — as elements of its input selection. Each such input is identified in the composition provenance record by the query library entry identifier, the source identity, and the data-source characterization version at the time of retrieval.

Traversal combinations surface analytically distinct capabilities:

Traversal combination	Analytical capability
Single data source alone	Quantitative signals, operational evidence, and field-level patterns within the scope of one source’s schema and content
Multiple data sources combined	Cross-source correlations, discrepancies, and patterns not present in any single source; coverage of aspects split across sources
Data source(s) combined with KB traversal	Cross-artifact findings: operational evidence from data sources interpreted against reference knowledge from the KB; nontrivial relationships and hidden patterns that neither source alone can yield

Higher-order synthesis over these combinations produces findings — correlations, emergent patterns, cross-source contradictions, derived classifications — that are not explicitly present in any single source and are not producible by the query library alone. The query library is the governed access mechanism that makes data source content available to higher-order synthesis; the synthesis act is what produces the nontrivial finding. Each such finding carries a composition provenance record (§01 §11) declaring its input selection, making it independently recomputable and verifiable.

2.4 Multi-locus gap report

Semantic binding emits a gap report. Each gap carries one or more locus tags from the set {data, domain-model, KB, specification}:

Locus	Meaning
data	A domain aspect for which no supporting data-source structure exists or suffices
domain-model	Structure present in the data with no corresponding aspect in the model
KB	An aspect or datum lacking supporting reference material in any available knowledge base
specification	A provision in a formal specification (lowered from a domain model and enrolled as a governing artifact) that lacks data, model aspect, or KB support; or a data element for which no provision exists in any active formal specification. “Specification” here means formal specification — the lowered output of the domain model — not an externally-provided specification before domain model creation.

Cross-locus gaps span two or more loci simultaneously — for example, a domain-model gap that also produces a specification gap and a knowledge-base gap. A multi-locus gap event is represented as a single record with a locus-set field (a non-empty subset of the four loci). It is not decomposed into per-locus records. The typed reinforcement signal for a multi-locus event is the union of typed signals corresponding to each locus in the set.

Where a gap’s locus set is ambiguous at detection time, the detecting operation assigns a provisional locus-set and marks the record as pending-refinement. Refinement is resolved during the next evidence-gathering verification pass.

The gap report is block-agnostic: the number and kind of aspects, data sources, and knowledge bases do not constrain its structure. It composes with the completeness and gap-referral mechanism of §01 (modeling) and with the gap-on-insufficiency emitted by evidence-gathering verification (§03-iii §2.5). All gaps emitted by semantic binding enter the canonical gap governance mechanism (§03-iii §2.0) at Open state. The pending-refinement annotation on an ambiguous gap record is an in-progress qualifier on an Open-state gap, not a separate state; refinement is resolved during the next evidence-gathering verification pass, after which the gap record’s locus-set is updated.

2.5 Data source metadata contract

Data source metadata — the structural characterization (§2.1b) and the semantic-map artifact — must be persistent and available for load and use. The form of storage is the licensee’s choice: metadata may be held internally within a unified data source (a table or schema within the same database), distributed across federated sources (each source managing its own metadata internally), unified in an external store (a separate database, file, or index spanning all federated sources), or any combination. The system is agnostic to storage form, engine, and whether a version control system is used.

What the contract requires, regardless of storage form:

Requirement	Description
Addressability	Every metadata entry is addressable by a stable identifier: source identity + structural element identity (table, field, or collection name). Entries must be retrievable individually, not only as a full scan
Source-scoped isolation	In a federated system, each source’s metadata is independently addressable and isolable. A query against one source’s metadata does not require loading another source’s metadata
Field/table reference	Each query library entry carries explicit references to the specific source identity, table/collection, and field(s) it targets. These references are the index into the metadata for staleness detection and scoped recomputation
Change detectability	The metadata must make changes detectable: either through a version control mechanism chosen by the licensee, through explicit version markers on metadata entries, or through comparison against a prior snapshot. The form of change detection is the licensee’s choice; the requirement is that a change produces a detectable diff
Persistence and loadability	Metadata must persist across sessions and be loadable for use without re-running characterization from scratch

Metadata versioning is the licensee’s choice. A licensee using a database with built-in row versioning uses that. One managing metadata as files may use a VCS. One without either mechanism carries explicit version markers on metadata entries (source version, characterization timestamp, schema snapshot identifier). Mars® does not require a specific mechanism; it requires that the current metadata state is known and that changes from a prior state are detectable.

2.6 Versioning, staleness, and propagation

The semantic-map artifact and query library are downstream of three independent upstream artifacts: the domain model (§01), the data source(s), and the knowledge base(s). Each upstream change source has a distinct propagation path and distinct staleness consequence.

The semantic-map artifact and query library are versioned registered artifacts. Each version carries: the domain-model version under which it was produced, the data-source characterization version(s) for each source included, and the KB version(s) used in query generation (if any). A semantic-map artifact or query library entry is valid against the specific upstream versions it references; it does not automatically absorb changes to those versions.

Query library entries carry four upstream references. Each query library entry references: (a) the domain aspect it serves (model reference — aspect identifier from the order-decomposition tree, including the domain model version encoded in the aspect identifier); (b) the specific source identity, table/collection, and field(s) it targets (metadata reference — into the data source metadata contract); (c) the KB version(s) and specific KB primitive identifiers used in query generation (KB reference — null where KB traversal was not used); and (d) the formal specification version(s) of any formal specifications (lowered from a domain model, enrolled in the delta-attestation lifecycle) resident in the KB whose primitives were consulted during KB traversal (formal specification reference — null where not applicable). All applicable references are required. A change to any upstream triggers scoped recomputation for matched entries only; entries whose model reference, metadata reference, KB reference, and formal specification reference are all unchanged are provably unaffected.

Domain-model amendment → semantic-map and query library staleness. When the domain model is amended, the staleness consequence depends on the delta-attestation classification (§02b §5.2):

Delta class	Consequence for semantic-map and query library
Scope-preserving	No staleness. Existing bindings remain valid; no re-derivation required
Scope-extending	Partial staleness. Bindings to aspects unaffected by the extension remain valid. New aspects added by the extension have no bindings yet; semantic binding must be re-run for those aspects against the existing data sources
Scope-restricting	Partial staleness. Bindings to aspects whose scope was narrowed must be re-evaluated; library entries bound to restricted aspects are flagged pending-re-evaluation and may not be used as evidence until cleared. The flag is cleared by re-running the query construction loop (§2.3) for the affected entries under the amended domain model; a cleared entry is recorded as a new registered artifact version with updated upstream version references.
Scope-breaking	Full staleness of any binding whose governing aspect was broken. Those bindings are invalidated; re-running semantic binding under the new model version is required before the affected entries may be used

Data-source change → characterization and downstream staleness. Changes to a data source fall into two categories with distinct consequences: changes that require recomputation, and deletions that require retirement.

Changes that require recomputation (field addition, type change, table addition):

The structural characterization for the affected source is stale. Re-characterization is required for that source before re-running semantic binding. In a federated system, only the characterization of the changed source is stale; other sources’ characterizations are unaffected.
Field additions create new unbound structure (emitting domain-model locus gaps if no corresponding aspect exists). Type changes invalidate library entries referencing the affected field.
For each stale library entry: the system identifies the domain aspect binding(s) of the affected field(s) via the entry’s metadata reference, re-runs the query construction loop (§2.3) for those aspect bindings under the current schema, and replaces the prior entry with the re-generated entry. The re-generated entry is a new registered artifact version with updated upstream version references. An entry flagged stale that has not completed re-generation may not be used as evidence in any governed operation.

Deletions that require retirement (field removal, table or collection removal, source removal):

A deleted field or table orphans every query library entry whose metadata reference includes that element. Those entries are retired: marked inactive, excluded from use as evidence, retained as archived records with their metadata reference marked tombstoned.
Retirement is not recomputation. A retired entry is not re-generated; it is closed. If the domain aspect it served still has other data sources or fields that can serve it, a new entry must be constructed through the query construction loop (§2.3) for that aspect under the remaining sources.
In a federated system, removal of one source retires only entries whose metadata reference is scoped to that source. Entries referencing other sources are unaffected. Entries spanning multiple sources are re-evaluated with the removed source’s contribution excluded.

Content change only (no schema change):

The characterization is not stale; schema-level bindings remain valid. Fitness signals for library entries may degrade if content distribution changes substantially; a re-validation pass against new sample data is the appropriate response, not re-characterization.

Knowledge-base amendment → query library staleness. A KB version increment propagates to the query library only for entries generated using KB traversal input. Entries generated from domain mapping alone are unaffected. Staleness is determined at the primitive level: each entry carries the list of specific KB primitive identifiers consulted during its generation (recorded in the composition record per §2.3); if those primitives are unchanged between KB versions, the existing entry remains valid; if they have changed, the entry is flagged pending-re-evaluation. An entry flagged pending-re-evaluation due to KB amendment may not be used as evidence in any governed operation until the flag is cleared. The flag is cleared by re-running the query construction loop (§2.3) for the affected entry under the amended KB version; a cleared entry is recorded as a new registered artifact version with updated upstream version references.

Formal specification amendment → query library staleness. A formal specification (lowered from a domain model and enrolled in the delta-attestation lifecycle) may reside in a KB as a formalized artifact whose primitives are consulted during KB traversal for query generation. When a formal specification is amended, its delta-attestation classification (§02b §5.2) determines staleness consequence for query library entries that carry a formal specification reference (composition record per §2.3) to that specification’s version:

Delta class on formal specification	Consequence for query library entries referencing it
Scope-preserving	No staleness. Existing entries remain valid against the prior formal specification version reference
Scope-extending	Partial staleness. Entries bound to aspects covered by the extension may benefit from re-generation; entries outside the extended scope are unaffected
Scope-restricting	Partial staleness. Entries whose KB primitives were drawn from aspects now restricted are flagged pending-re-evaluation
Scope-breaking	Full staleness for entries referencing the broken aspects. Those entries are invalidated; re-generation under the amended formal specification version (via the KB containing the updated formal specification) is required before the affected entries may be used as evidence

Formal specification staleness propagates through the KB: an amended formal specification produces a KB version event for the KB in which it resides (the formal specification’s primitives are updated under the new version), and the KB version event then propagates to query library entries per the KB amendment path above. The formal specification version reference in the query library entry’s composition record is the index into this propagation chain.

Embedding model change → embedded-source query library entry staleness. Query library entries targeting embedded sources carry the embedding model identity and version in effect at construction time (§2.3 embedded-source query entry). When the embedded source’s embedding model changes — version upgrade, replacement, or parameter change — the encoding of the entry’s declared query surface under the prior model is not comparable to vectors produced under the new model. All entries targeting the affected embedded source are flagged pending-re-evaluation: their encoding specifications must be re-evaluated under the new embedding model version before they may be used as evidence. The staleness flag is set by comparing the embedding model version recorded in the entry’s composition record against the current registered embedding model version of the targeted embedded source. An entry flagged pending-re-evaluation due to embedding model change may not be used as evidence in any governed operation until the flag is cleared by re-evaluation under the new embedding model version; a cleared entry is recorded as a new registered artifact version with updated upstream version references.

Propagation is recorded, not inferred. Each semantic-map artifact entry and each query library entry carries the upstream version identifiers from which it was derived — model version, data-source characterization version per source, KB version if applicable, formal specification version if applicable, and embedding model version for embedded-source entries. Staleness is determined by comparing those recorded versions against the current registered versions of each upstream artifact, not by re-running the derivation speculatively. In a federated system, each source’s version is tracked independently; a change in one source’s characterization version does not affect the staleness assessment of entries bound exclusively to other sources.

← What this section covers · Section index · Outputs →