§03-ii Minerva — Knowledge Base — What a knowledge base is and what distinguishes it
Mars® Spec › §03-ii Minerva — Knowledge Base › What a knowledge base is and what distinguishes it
Section index · Inputs and corpus characterization →
Mars® Protocol — §03-ii: Knowledge Base
Version 1.0-draft
1. What a knowledge base is and what distinguishes it
A knowledge base is a governed, aspect-typed, chunked representation of a corpus, organized for retrieval and traversal. Its fundamental unit is the chunk: a bounded span of corpus content stored simultaneously in two co-indexed forms — as text (or as native-form content with a language-bound interpretation) in a non-embedded store, and as a vector embedding in an embedded store. The metadata fabric binds these two representations on shared identifiers and carries the aspect typing, source provenance, and navigability structure that makes the KB traversable.
Purpose. The KB’s purpose is to make corpus knowledge retrievable and traversable in a form governed by the domain model. It is the artifact from which ground truth and reference data are extracted during evidence-gathering (§03-iii), query generation (§03-i §2.3), and higher-order synthesis (§01 §11). It is not itself an assertion about the domain; it is the organized substrate from which assertions are derived and against which they are verified.
What distinguishes the KB from other artifacts:
| Artifact | What it is | What it is not |
|---|---|---|
| Knowledge base | Chunked corpus content, aspect-typed and co-indexed across non-embedded and embedded stores, organized for retrieval and traversal | An assertion about the domain; a specification; a derived analytic structure |
| Governing specification | A dynamic, context/condition/time-sensitive active selection from a collection of one or more formal specifications (§03-ii §1.1), constituting the global source of truth for a governed operation; see §03-iii §2.2 for the full definition | A store of corpus content; a retrieval substrate; a single flat artifact |
| Higher-order output (hypergraph) | A derived analytic structure produced by higher-order synthesis (§01 §11) over a declared input selection drawn from any combination of: order outputs, perspective outputs, variant outputs, KB primitives, data source retrievals, and prior higher-order outputs. A higher-order output may act as a hypergraph spanning multiple orders and artifact types simultaneously — it is not bounded to model-layer inputs alone. “Hypergraph” is an alternative name for this artifact type; the two terms are equivalent. | A storage artifact; corpus content; a retrieval substrate |
| Data source | Operational or reference data in its native storage form | A governed, aspect-typed, chunked representation of that data |
The KB is the retrieval substrate; the governing specification and higher-order outputs are what is derived from it. A system that retrieves from the KB without governing the retrieval by the domain model’s aspect structure is not using a KB as defined here — it is using an unstructured similarity index.
What this section covers. KB construction: the corpus input and its characterization, aspect-typed primitive extraction, the co-indexed bidirectional store, controlled embedding-space transformations, map-governed chunking, and the KB lifecycle including versioning, dual-store sync, and the portable package. This section also defines the formal specification as a KB variant and specifies KB metadata as a property built and versioned against the governing domain model.
Dependencies:
- §01 (modeling) — provides the domain model (one or more, composable and independently operable; see §01 §1) — its orders, perspectives, variants, and aspects — that governs extraction, co-indexing, and chunking. Where multiple domain models are active, each carries its own registered artifact identity; KB entries, aspect identifiers, and lifecycle records are scoped to the domain model version under which they were produced.
- §02b §5 (delta-attestation lifecycle) — governs the amendment lifecycle for KB versions and all registered KB configuration artifacts
- §03-i (semantic binding) — KB versions may serve as optional input to semantic binding; aspect identifier structure (§3.2) must satisfy §01 §3
Produces: order-structured knowledge base (aspect-typed primitives, co-indexed across non-embedded and embedded stores, navigable metadata fabric, per-artifact provenance); portable package; subchunk-indexed entries consumed by §03-i (Impera, §03-i §2.1a) and §03-iii (evidence-gathering verification).