§03-iv Minerva — Governed Production — Governed data generation

Mars® Spec › §03-iv Minerva — Governed Production › Governed data generation

← What this section covers · Section index · Governed benchmark generation →

2. Governed data generation

2.1 What it is

Governed data generation is the production of new data — training data, augmentation data, synthetic evaluation data — under the governance of a domain model and governing specification. It is a first-class governed artifact-production act: the production act itself has a boundary, a recomputation witness, and a certificate path.

This is distinct from the corpus-consumption operations of §03-ii (knowledge-base creation), which take a pre-existing corpus as input. Governed data generation produces the corpus. The produced corpus is subject to the same artifact-class treatment as any other data source: it may be characterized, aspect-bound, used as evidence, and targeted by typed reinforcement signals.

2.2 Governing conditions

A governed data generation act requires:

A governing specification. The generation is bounded by the governing specification: only content consistent with the governing specification’s declared scope and order-typed structure is admissible as output. Generated content that would fail the conformance verdict against the governing specification is inadmissible.
A domain model — one or more. Generation proceeds under the model’s orders, perspectives, and declared variants. Multiple domain models may be active simultaneously; each generated item records the domain model version that governed its production in its domain aspect identifier (the aspect identifier encodes the domain model version per §03-ii §3.2). Each generated item is typed at generation time — its domain aspect, order type, perspective tag, and variant identifier are not assigned post-hoc; they are the governing parameters under which the item was generated.
A declared generation specification. A registered artifact declaring: the generation method (such as model-based, rule-based, hybrid, or other declared generation method), the source material (real corpus, KB primitives, specification clauses, none, or other declared source material), the aspect-coverage target (which aspects the generation is intended to fill), and the admissibility constraints (what content is inadmissible under the governing specification). The generation specification is a structural contract: its declared method, admissibility constraints, and coverage targets together define the encoding contract under which every generated item is produced. An item produced under generation specification version N is encoded against that version’s contract. A change to the generation specification is a change to the contract, not merely a change to a configuration parameter. The generation specification is enrolled in the delta-attestation lifecycle (§02b §5) as a registered artifact with its own version identity; its amendment lifecycle is governed by §2.6.

2.3 Inbound and outbound boundary

Inbound. The inbound boundary of a governed data generation act records: the governing specification identity and version, the domain model identity and version, the declared generation specification identity and version, and the source material identity (or null if no source material is used).

Outbound. The outbound boundary of the act is a generated data corpus with per-item provenance. Each item in the corpus carries: its domain aspect identifier (from the order-decomposition tree, §03-ii §3.2), its order type, the generation specification identity and version under which it was produced, and a generation-act identifier linking it to the act’s recomputation witness. The generation specification version is a per-item field, not a corpus-level field alone: if a corpus is produced across multiple generation acts under different generation specification versions (for example, following an incremental amendment), each item carries its own generation specification version, and the corpus-level record carries the set of generation specification versions represented. Each item also carries a content hash computed over its full content — the generation-act identifier together with the item’s content hash constitute the item’s version identity. The generated corpus as a whole carries a content hash computed over the ordered collection of item content hashes, where items are ordered lexicographically by their content hash for the purpose of computing the aggregate. These content hashes are the basis for downstream re-identification, staleness detection, and delta-attestation enrollment: if the generation act is re-run (e.g., on governing specification amendment), the new corpus’s per-item hashes are compared against the prior corpus’s hashes to produce a typed item-level structural-difference record, scoping any downstream reprocessing to the changed items.

2.4 Recomputation witness for governed data generation

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

Invariant	Canonical component	What it requires
Generation trace	(i)	For each generated item: the aspect-typed prompt or rule that governed its generation, the order type of the governing parameter, the generation specification version, and the content hash of the generated item — the hash of the item’s full content as it appears in the outbound corpus. The content hash is the tamper-evidence link between the witness and the corpus: a witness whose per-item content hashes do not match the corpus handed over does not cover that corpus.
Admissibility record	(ii)	For each generated item: whether it passed the admissibility check against the governing specification, and if so, the aspect binding and conformance classification
Coverage record	(iii)	For each aspect in the declared aspect-coverage target: the number of generated items bound to that aspect, the coverage fraction achieved against the target, and any gap-on-insufficiency where coverage targets were not met

Tamper-evidence binding. The content hash in invariant (i) is the binding between the recomputation witness and the generated corpus. An inspector verifying the witness must: (a) recompute the content hash of each item in the corpus as received, and (b) compare against the per-item content hash in invariant (i). A mismatch on any item indicates that either the corpus or the witness has been altered. The aggregate corpus content hash (§2.3 outbound) provides a single-value check over the full corpus; the per-item hashes in invariant (i) scope any mismatch to the specific item(s) affected.

An independent inspector can re-derive from this witness: what items were generated, under what governing parameters, that the generated corpus handed over is exactly the one the witness covers (via content hash matching), and whether the generated corpus satisfies the declared coverage targets — without access to the generation infrastructure.

2.5 Conformance certificate for generated data

A governed data generation act that satisfies its declared aspect-coverage targets and passes admissibility checks against the governing specification may receive a governing-data-generation certificate: a conformance certificate (§02b §2) whose target identity is the generated corpus, whose recomputation witness is the three-invariant generation witness of §2.4, and whose grounded verdict reflects the coverage and admissibility outcomes.

This certificate is required before the generated corpus may be used to close a data gap (§03-iii §2.11 resolution path 3) or serve as training data in a governed model-development context.

2.6 Generation specification amendment lifecycle

The generation specification as structural contract. The generation specification is not a generation-time configuration parameter that can be changed freely. It is the structural contract that defines what items produced under it mean: what method produced them, what admissibility constraints they satisfy, what aspects they were intended to fill. A change to any of these three components is a change to the encoding contract. Items produced under the prior contract are encoded differently from items produced under the amended contract — and in the case of a breaking change, may be structurally inconsistent with the new contract.

This is structurally analogous to a versioned programming language specification or compilation target: artifacts compiled under version N are encoded against that version’s semantics. Upgrading the language version may preserve compatibility (scope-preserving or scope-extending), require shims for legacy artifacts (scope-restricting), or require full recompilation (scope-breaking). The generation specification plays the same role for generated items that a language specification plays for compiled artifacts.

Delta-attestation classification. An amendment to the generation specification is classified under the four-valued lifecycle (§02b §5.2). The classification has generation-specification-specific semantics:

Delta class	Meaning for generation specification	Effect on existing generated items
Scope-preserving	The amended method, admissibility constraints, and coverage targets produce items that are compatible with the prior version’s contract; no existing item’s admissibility changes	No effect on existing items or their certificates; new generation proceeds under the amended version
Scope-extending	The amended generation specification admits items that the prior version would have excluded; no prior-admitted item is excluded by the amendment	Existing items remain valid under their generation specification version; new generation under the amended version may produce additional items not produceable under the prior version
Scope-restricting	The amended generation specification tightens admissibility constraints such that one or more items that were admissible under the prior version would not be admissible under the amended version	Existing items produced under the prior version enter a conditionally-valid state pending a consistency determination (see below)
Scope-breaking	The amended generation specification changes the generation method or coverage targets in a way that makes the prior version’s items structurally inconsistent with the new contract — not merely inadmissible but incomparable	Existing items produced under the prior version are retired; the governing-data-generation certificate for the affected corpus is invalidated; a new generation act is required under the amended generation specification

Consistency determination for scope-restricting amendments. When a generation specification amendment is classified as scope-restricting, the governing-data-generation certificate for any corpus produced under the prior generation specification version enters conditionally-valid state. A consistency determination is required before the certificate may be used for gap closure, training, or any other downstream act. The consistency determination is a governed act with its own recomputation witness:

Scope of determination. The consistency determination applies to every item in the affected corpus whose item-level generation specification version field matches the amended prior version. Items in the corpus produced under other versions are not in scope.
Per-item admissibility check. Each in-scope item is evaluated against the amended generation specification’s admissibility constraints. The evaluation produces a per-item admissibility record: admissible (item satisfies the amended constraints), inadmissible (item violates one or more amended constraints), or indeterminate (the amended constraint does not apply to the item’s aspect or order type).
Consistency determination witness. The consistency determination produces a recomputation witness carrying: the governing specification version in effect at the time of determination (so an inspector can retrieve the admissibility constraints actually applied), the prior generation specification version, the amended generation specification version, the list of items evaluated (by content hash), and the per-item admissibility record — where for each item the per-item admissibility record includes, where a shim was applied, the shim identity and version as a declared sub-record.
Outcome. Three outcomes are defined:
- Fully consistent. All in-scope items are admissible under the amended constraints. The governing-data-generation certificate is re-issued under the amended generation specification version with a cross-version reference to the prior certificate and the consistency determination witness. The prior certificate is superseded.
- Partially consistent. Some in-scope items are inadmissible under the amended constraints. Inadmissible items are retired from the corpus, with retirement recorded in the governing data store(s) per the licensee’s registered storage architecture. The governing-data-generation certificate is narrowed in declared scope to the remaining admissible items and re-issued with the consistency determination witness. The prior certificate is superseded. A coverage gap-on-insufficiency is emitted for any aspect whose item count falls below the declared coverage target after retirement.
- Fully inconsistent. All in-scope items are inadmissible. The certificate is invalidated. A new generation act is required. This outcome has the same effect as a scope-breaking amendment.

Scope-breaking amendments. Where an amendment is classified as scope-breaking, no consistency determination is performed. All items produced under the prior generation specification version are retired and all governing-data-generation certificates referencing that version are invalidated. The structural-difference record for the generation specification amendment identifies this as a scope-breaking event. A new generation act under the amended generation specification is the only path to a new certificate.

Shim provision for scope-restricting amendments. Where a scope-restricting amendment would retire a significant portion of the corpus, the licensee may declare a generation specification shim: a declared transformation procedure that brings inadmissible items into conformance with the amended constraints without full regeneration. The shim must be: (a) declared and registered before application, (b) enrolled in the delta-attestation lifecycle as a registered transformation artifact, and (c) its application recorded per-item in the consistency determination witness. A shim-transformed item carries the amended generation specification version in its generation specification version field and a transformation record identifying the shim version applied. A shim is not a substitute for a consistency determination; it is a resolution path within it.

Cross-version certificate reference. Every governing-data-generation certificate re-issued following a consistency determination carries a cross-version reference record: the prior certificate identity and version, the generation specification amendment that triggered the determination, the consistency determination witness, and the outcome (fully consistent, partially consistent, or fully inconsistent). This record is carried in the certificate’s certification-path record (Field 3). An inspector can trace the full amendment and consistency chain for any governing-data-generation certificate by following these cross-version references.

2.7 Relationship to the reinforcement loop

Governed data generation is a resolution action within the reinforcement loop (§03-iii §2.10). A data-source-gap signal may route to a governed data generation act as its amendment action. The generated corpus, once certified, closes the gap and triggers re-verification under the updated data source set. The loop proceeds as specified in §03-iii §2.10.

2.7a Reverse-synthesized data sources and knowledge bases

The canonical specification of reverse-synthesized artifacts as the third rung of the fallback hierarchy — including the fallback-only constraint, the hardening discipline, and the three-component recomputation witness — is in §03-iii §2.12. This subsection cross-references that canonical statement and records the governed-production-specific obligations that apply when a reverse-synthesized artifact is produced within the governed-production layer.

Where a data source or knowledge base required by a governed service is absent or insufficient, the governing-production layer may synthesize one from the available governing assets — the domain model, the governing specification, or both — order-typed and witness-bound, as specified in §03-iii §2.12. A reverse-synthesized artifact produced here is a registered artifact in the specification registry, enrolled in the delta-attestation lifecycle (§02b §5), and must satisfy the three-component witness requirement of §03-iii §2.12: (i) governing asset identity and version, (ii) per-element order-typed derivation record, (iii) per-element content hash. A witness that records only the governing asset identity without the per-element derivation record does not conform.

Hardening as a governed act. A data source or knowledge base — whether provided, generated under §2, or reverse-synthesized — may be hardened before service use. Hardening is a governed act only when the hardened artifact is subsequently bound to gap identification, reinforcement, and grounded verification (§03-iii) before the artifact is handed to the consuming service, in that order. Hardening not followed by this binding sequence before service use is a data transformation, not a governed hardening act; the transformed artifact may not be used as evidence in any governed operation.

2.8 Generation environment capsule

Purpose. The recomputation witness (§2.4) records what was done — the procedure, the governing parameters, and the per-item content hashes. A separate question is whether the generation act can be recreated de novo: given that the generation environment may be dynamic — data sources queried at generation time, KB versions that may have advanced, model versions that may have changed, source material that may have drifted — the inputs present at generation time may not be recoverable from the procedure record alone. The generation environment capsule addresses this: it is a content-addressed artifact capturing the minimal set of pinned inputs sufficient to recreate the generation act from scratch, without access to live infrastructure.

What a capsule is. A generation environment capsule is a self-contained, content-addressed artifact carrying:

Component	Content
Artifact manifest	The identity and content hash of every registered artifact active at generation time: governing specification (identity, version, content hash), domain model (identity, version, content hash), generation specification (identity, version, content hash), KB (identity, version, content hash — per KB if multiple), and where an embedding model is employed: embedding model (identity, version, content hash); omitted where no embedding model is used
Dynamic input record	For each dynamic input consumed during generation: the input type (including but not limited to: data source query result, KB retrieval, source material span, or other live-infrastructure-dependent input), the query or retrieval specification (the exact query or retrieval parameters), the result at generation time (the returned value or content span, stored in full or by content hash with the full value appended), and the data source or KB version at the time of retrieval. Dynamic inputs are those whose value depends on live infrastructure state at the moment of the generation act — they are not derivable from the artifact manifest alone.
Generation model binding	The identity and version of the model or generation mechanism used to execute generation; where applicable: any prompt template version and sampling parameters declared in the generation specification; for non-model generation mechanisms (such as rule engines or deterministic procedures), the rule set or procedure identity and version in place of prompt template and sampling parameters
Environment timestamp	The declared timestamp of the generation act; used to establish the temporal state of all live inputs
Generated corpus binding	The aggregate content hash of the generated corpus (§2.3 outbound) and the per-item content hash table — the same values carried in invariant (i) of the recomputation witness (§2.4), replicated in the capsule to make the capsule independently verifiable without the witness
Capsule content hash	A content hash computed over all preceding capsule components; the capsule’s own version identity

Relationship to the recomputation witness. The capsule and the witness are complementary, not redundant. The witness records the procedure; the capsule records the environment. Together they are sufficient for independent reconstruction: the witness specifies what to do, the capsule provides the exact inputs to do it with. A capsule without a witness is a frozen environment but not a governed procedure record. A witness without a capsule is a procedure record but not independently executable against dynamic inputs that have since drifted.

Where a capsule is produced, the governing-data-generation certificate (§2.5) carries the capsule content hash in its certification-path record (Field 3). This binding makes the certificate tamper-evident at the environment level: altering any input in the capsule changes its content hash, which falsifies the certificate’s Field 3 binding.

Capsule form. The capsule is a content-addressed binary or structured-data artifact. Its internal format is the licensee’s choice subject to the following requirements: (a) all components in the manifest table above are present and addressable within the capsule, (b) the capsule content hash covers all components, (c) the capsule is self-contained — no component requires a live network request to resolve, and (d) the capsule is portable — it can be transferred, stored, and consumed without modification to its content hash. Admitted forms include a content-addressed archive (tar+hash, zip+hash), a content-addressed structured record (JSON-LD, CBOR), or a content-addressed database export. The form is the licensee’s choice; the properties are required.

Dynamic input completeness. A capsule that omits a dynamic input — a data source query result that was consumed during generation but not recorded — is an incomplete capsule. An incomplete capsule does not satisfy the de-novo-recreation requirement: an inspector cannot reconstruct the generation environment from an incomplete capsule if the omitted input has since changed. The completeness obligation is strict: every input whose value depends on live infrastructure state at generation time must be recorded in the dynamic input record. The generation specification (§2.2 item 3) declares the source material; the capsule records what was actually retrieved, which may differ from what was declared (e.g., if a declared source was unavailable and a fallback was used). The capsule is the authoritative record of what was present, not what was declared.

Capsule production. Capsule production is the licensee’s option, not a mandatory requirement of every governed data generation act. However, where a generation act produces items that will be used as training data in a governed model-development context, or where the governing-data-generation certificate is expected to support de-novo verification by a third-party inspector or an autonomous governance component (AIGP, §02c), capsule production is required. The certificate’s declared scope (Field 5) must note capsule status — produced or absent — for every governing-data-generation certificate regardless of the context in which it was originally issued. A Field 5 entry that does not declare capsule status is a structurally incomplete certificate. Capsule absence does not block issuance in non-mandatory contexts; it blocks re-use in capsule-required contexts. Where a governing-data-generation certificate carrying a capsule-absent Field 5 note is re-used in any context that would have required a capsule at original production time — including training data use or de-novo verification by a third-party inspector or autonomous governance component — the re-use is blocked until a capsule is produced for that certificate. The capsule-production event is recorded as a registered artifact version update to the certificate’s Field 3 binding; it does not require re-issuance of the certificate unless the underlying generation act has been superseded. A certificate re-used in a capsule-required context without completing this capsule-production event does not conform.

Capsule lifecycle. A capsule is enrolled in the specification registry as a versioned registered artifact. Its version identity is its capsule content hash. The capsule is retained for the full lifecycle of the governing-data-generation certificate it supports: it is not retired when items in the corpus are retired unless the certificate itself is invalidated. A scope-breaking amendment (§2.6) that invalidates the governing-data-generation certificate also retires the associated capsule.

← What this section covers · Section index · Governed benchmark generation →