§03-v Minerva — Governed Services — Governed-service discipline

Mars® Spec › §03-v Minerva — Governed Services › Governed-service discipline

← What this section covers · Section index · Externally-observable properties →

2. Governed-service discipline

2.1 What a governed service is and what it is not

A governed service exposes one or more generation operations — dataset generation, model training, KB creation, benchmark derivation, or any other governed artifact-production act — as a callable, registered interface under the following structural requirements:

Registration. Each generation operation is a registered operation in the specification registry. Its registration record declares: the operation identity and version, the governing asset(s) it operates relative to (domain model, specification, data source, knowledge base, or any combination with governing-bound fallback), the artifact class(es) it produces, and the witness discipline in effect.
Versioning. Each operation is versioned under the delta-attestation lifecycle (§02b §5). A change to the governing assets, the generation specification, or the operation’s declared scope constitutes a versioned amendment to the operation’s registration record, classified under the four-valued delta lifecycle. A generation operation whose governing assets are updated without a corresponding version event in the operation’s registration record is not a conforming governed-service operation.
Audit-emission. Each invocation of a generation operation emits an audit record carrying: the operation identity and version, the governing asset identities and versions at the time of invocation, the artifact class(es) produced, the content hash(es) of the produced artifact(s), and the invocation timestamp. The audit record is a first-class governance artifact enrolled in the specification registry. An invocation that does not emit an audit record is not a governed-service invocation.
Recomputability. Each generation operation is recomputable: an independent inspector re-derives the produced artifact’s provenance and conformance to the governing assets from the retained recomputation witness, without access to the deployment. The recomputation witness must establish both provenance (which governing assets produced this artifact) and conformance (that the artifact satisfies the order-typed scope declared in the governing assets). A witness that establishes provenance but not conformance is structurally incomplete as a governed-service witness.

Ungoverned generation registered post-hoc is not the governed-service discipline. The registration, versioning, and audit-emission requirements apply to the generation operation itself — they are properties of the act, not of a subsequent registration step applied to the act’s outputs. Running an ungoverned generation pipeline and then registering its outputs in the specification registry does not constitute a governed-service operation. The operation is the governed act; post-hoc registration of its outputs is a recording act, not a governing act, and does not produce a conforming governed-service audit record or a conforming recomputation witness.

2.1a Summarization and analysis as governed-service operations

Summarization and analysis operations, when exposed as callable services, are subject to the same four governed-service discipline requirements as generation operations (§2.1): registration, versioning, audit-emission, and recomputability. A party offering a summarization or analysis service under the Mars® governed-service discipline must satisfy all four requirements; a service that satisfies registration but omits audit-emission or recomputable witnesses does not conform.

The two distinctions from generation operations are:

Output artifact class. For summarization operations, the produced artifact is a summary artifact — an order-typed, asset-bound summary of one or more governed inputs — not a generated corpus. The audit record carries the summary artifact identity and content hash in place of the generated-corpus identity. For analysis operations, the produced artifact is an analytical finding — an order-typed, evidenced, attributed finding produced by the analysis battery (§02a) over governed inputs. The audit record carries the analytical finding identity and content hash. Both artifact classes are first-class registered artifacts enrolled in the delta-attestation lifecycle (§02b §5).
Recomputation witness requirement. The recomputation witness for a summarization or analysis operation must satisfy the §03-iii §2.7 three-invariant witness requirements — traversal trace (invariant i), evidence record (invariant ii), and uncertainty-reduction record (invariant iii) — not the §03-iv §2.4 generation witness requirements. These are structurally distinct witness obligations: the generation witness records the generation procedure and per-item content hashes; the §03-iii §2.7 witness records the evidence-gathering traversal, the evidence retrieved, and the per-step uncertainty reduction that grounds the verdict. A summarization or analysis operation whose recomputation witness satisfies only the generation witness requirements — recording what was produced but not the evidence-gathering traversal and uncertainty-reduction that governed it — does not produce a conforming governed-service witness for a summarization or analysis operation.

Claiming governed-service status without satisfying §03-iii §2.7 is not the governed-service discipline. A summarization or analysis service that registers its operations in the specification registry and emits audit records but produces witnesses that do not carry the three-invariant §03-iii §2.7 structure is not practicing the governed-service discipline for summarization or analysis. The §03-iii §2.7 witness requirement is the structural property that makes the output recomputable and independently verifiable; without it, the service is registering outputs without governing the operation that produces them.

2.2 Heterogeneous data-model class

A governed data-models service generates, under one governed-service discipline, a heterogeneous class of artifacts: datasets, analytical or statistical models, probabilistic models, and deep-learning models (including embedding models, large-language models, and other natural-language models). The enumeration of model subclasses is non-limiting and extensible; the structural requirement is that the same governed-service discipline — the same registration, versioning, audit-emission, order-typing, and asset-binding witness requirements — governs generation across all model subclasses under one declared service registration.

Single-class generation pipeline is not a governed data-models service. A service that governs generation of only one model subclass — datasets alone, embedding models alone, or any other single subclass — under a class-specific registration and policy is not a governed data-models service under this section. It is a single-class governed generation pipeline. The distinguishing structural property of the governed data-models service is that the same governed-service discipline applies across the full heterogeneous class under one service registration record. An implementation that operates separate governed pipelines for each model subclass, each with its own registration and witness discipline, does not compose them into a single governed-service act and does not practice the governed data-models service as defined here.

2.3 Order-typing of generated artifacts

Each artifact generated under the governed-service discipline carries an order-type declaration: the orders (from the governing domain model) that the artifact expresses relative to its governing assets. The order-type is a per-artifact metadata field, not a corpus-level or service-level annotation. A generated dataset whose items are typed at the domain-aspect level (§03-iv §2.3) satisfies this requirement; a dataset carrying only a service-level tag does not. A generated model whose behavior profile is characterized against the orders of the governing specification satisfies this requirement; an untyped model registered in the specification registry without an order-type declaration does not.

2.4 Asset-binding recomputation witness

Each generated artifact is bound to its governing assets by a recomputation witness. The witness must enable an independent inspector to re-derive both:

Provenance: which governing assets, at which versions, were the inputs to the generation operation that produced this artifact; and
Conformance: that the artifact satisfies the order-typed scope declared by those governing assets — i.e., that the artifact’s content is consistent with the governing specification’s aspect structure and does not assert content outside the declared governing scope.

A witness that records only the governing asset identities (provenance) without a derivation record sufficient to verify conformance does not satisfy the asset-binding witness requirement. The distinction: provenance establishes what was used; conformance establishes whether what was produced is what the governing assets require. Both are required. An implementation that treats the asset-binding witness as a provenance label — recording which assets were used but not providing the re-derivation path for conformance — is not producing a conforming asset-binding witness.

Amendment cascade. When a governing asset is amended, the delta-attestation lifecycle (§02b §5) propagates through all artifact registrations whose asset-binding witnesses reference the amended asset version. The cascade is scoped to artifacts referencing the amended version; artifacts whose witnesses reference prior unaffected versions are not in the cascade scope.

2.5 Governed-service composition and hand-off

A generated artifact may be handed to a consuming governed service — an analysis battery, a benchmark evaluation service, a model-moderation service — for evaluation or further governed use. The hand-off is at a registered boundary: the producing service emits the artifact and its audit record; the consuming service receives them by reference and verifies the audit record before operating on the artifact. A consuming service that operates on a generated artifact without verifying its governed-service audit record is not consuming the artifact through the governed-service boundary.

The producing service and the consuming service are distinct governed acts. The governing-service discipline of the producing service (registration, versioning, audit-emission, order-typing, asset-binding witness) does not carry over to the consuming service; the consuming service must satisfy its own governed-act requirements. The hand-off at the boundary is the interface; neither service’s governance substitutes for the other’s.

2.6 The governed decision service

A governed decision service exposes, as a callable, registered, versioned, audit-emitting interface, an operation whose output is not a generated artifact but a governed decision: a query over knowledge bases and data sources, verified against the governing specification, yielding an order-typed verdict that authorizes or informs a downstream act. Real-time APIs that make decisions on knowledge or operational data — eligibility determinations, routing and dispatch, targeting and prioritization, admit/deny gates over live state — are governed decision services. The output artifact class is the decision bundle: the order-typed verdict together with its §03-iii §2.7 three-invariant recomputation witness, the as-of timestamps and freshness dispositions of its operational-data evidence (§03-iii §2.7 freshness invariant), and the governing asset versions in effect.

The decision service is subject to the four governed-service discipline requirements (§2.1) — registration, versioning, audit-emission, recomputability — on the same terms as generation and summarization/analysis operations. It is not exempt on the ground that it produces a verdict rather than a stored artifact: the decision bundle is a first-class registered artifact enrolled in the delta-attestation lifecycle (§02b §5), and a query→decision API that registers no operation, emits no audit record, or produces no recomputable decision bundle is not a governed decision service — it is an ungoverned decision pipeline, and its verdicts are not governed decisions.

Freshness and degradation are declared, not implicit. A governed decision service operating on operational data declares, per decided aspect, the evidence-freshness bound it enforces (§03-iii §2.7) and its degradation mode — the governed behavior when fresh-enough evidence cannot be obtained within the service’s latency budget. Admitted degradation modes, non-exclusively: fail-closed (emit an evidence-staleness gap and REFUSE the decision), fail-stale-declared (emit the decision annotated with the exceeded freshness bound and the actual evidence age, as an explicitly non-fresh governed decision that a downstream actuation gate may refuse), or fail-to-authority (route to a named authority per §02f investigate discipline). Silent emission of a decision on stale evidence — a decision whose bundle does not disclose that its grounding evidence exceeded the declared freshness bound — is non-conforming. The degradation mode is a registered parameter of the service; the decision bundle records which mode governed each decision.

Actuation continuity. Where a governed decision authorizes a downstream non-linguistic or persistent-state effect, the decision bundle is the originating verification record consumed at the §02c actuation anchor (§02c §4, Field 1). The freshness disposition of the decision propagates into the actuation gate: a decision emitted under fail-stale-declared carries its non-fresh annotation to the actuation gate, which may refuse the effect on that basis under its declared conditions. The decision service does not terminate the governance chain; it is a link consumed by the outbound boundary.

← What this section covers · Section index · Externally-observable properties →