§7 Minimum Viable Record

v2.0.0 · Locked · L1 · March 19, 2026

Purpose

The Minimum Viable Record (MVR) is the minimal set of fields required for a Tier 1 primitive instance to be compliant with the Decision Lineage Protocol. If a record contains all MVR fields with valid values, it is DLP-compliant. If it is missing any MVR field, it is rejected at write time. This section defines the required fields for each of the nine Tier 1 primitives, specifies how MVR validation operates alongside behavioral invariant validation, and establishes the extension framework for optional fields beyond the MVR base.

Foundation

The MVR fields were derived from field necessity analysis across three dimensions: governance semantic necessity (is this field required to answer a governance question?), invariant enforcement necessity (is this field required by a behavioral invariant?), and cross-substrate interoperability necessity (would records be auditable and queryable across substrates without this field?). Fields that failed at least one dimension were excluded. The design principle is field minimalism — governance infrastructure should require no more data capture than necessary for decision support.

Governance

This section is owned by Cam (founder, GrytLabs). Changes to MVR field requirements for Tier 1 primitives require explicit decision with interoperability impact assessment. Extensions (Tiers 3–5 and Namespace-scoped) are governed by their respective authorities; the MVR base is protocol-immutable.

Substance

§7.1 MVR Scope

The MVR applies to Tier 1 primitives only. This is a deliberate scope boundary, not an omission.

Table 7.1.1: MVR Scope by Tier

Rationale

Tier 1 carries MVR because these nine primitives are the protocol's irreducible governance vocabulary. Every DLP-compliant substrate must represent them. A universal field standard ensures that records are interoperable across substrates and auditable against a common specification. Without MVR, two substrate implementations could represent the same Commitment with incompatible field sets, making cross-substrate governance impossible.

Tier 2 does not carry MVR because infrastructure primitives are substrate plumbing. Identifier, Entity, Context, and Namespace are the mechanism by which Tier 1 instances are addressed, attributed, situated, and scoped. Their structure is defined by infrastructure specifications (§4.6), not by governance field requirements. An Identifier needs to be unique and resolvable; it does not need a governance field set.

Tiers 3–5 do not carry MVR because their field requirements vary by organizational context. An enterprise assurance substrate (EAS) may require different Orientation fields than a public accountability substrate (PAS). Fixing MVR fields for these tiers would either over-specify (forcing fields irrelevant to some profiles) or under-specify (defining a lowest common denominator too thin to be useful). Instead, Tiers 3–5 are governed through the Namespace extension framework (§7.4), where domain and tenant extensions define field requirements appropriate to each profile.

§7.2 MVR Fields by Primitive

Each table below defines the required fields for one Tier 1 primitive. Every field listed is mandatory — a record missing any field is rejected at write time. The field definitions are authoritative; the TypeScript interfaces in mvr-definitions.ts and the SHACL shapes in mvr-validation-shapes.ttl are derived from this specification.

§7.2.1 Intent

Intent is the origin point of governance action. Every downstream Commitment traces to an Intent, establishing the organizational purpose that justifies resource allocation.

§7.2.2 Commitment

Commitment links intent to execution. The capacity_allocation field connects to the Capacity primitive, enabling B2 enforcement (§5). The intent_id field ensures every commitment traces to an organizational objective.

§7.2.3 Capacity

Capacity is the feasibility check that grounds commitments in reality. Without verified capacity, commitments are promises without substance — the governance failure B2 prevents.

§7.2.4 Work

Work is the state transformation primitive — the mechanism through which commitments become outcomes. The commitment_id field enables B1 enforcement (§5): no work without a commitment.

§7.2.5 Evidence

The truth_type field carries exactly three values from the truth type vocabulary (§6.1). This is the field enforced by invariant B3 (§5): every evidence artifact must be epistemically classified. The three truth types — Authoritative (canonical, append-only), Declared (human-asserted, versioned), Derived (AI-generated, ephemeral) — are the complete epistemic vocabulary. Verification state, claims graduation stage, and record lifecycle state are orthogonal vocabularies tracked independently (§6).

§7.2.6 Decision

Decision is the choice point where governance becomes action. The authority_source field links to an Authority instance, enabling verification that the decision-maker had the right to decide. Invariant B4 (§5) requires every Decision to link to an Account — that linkage is an inter-record relationship enforced by B4 shapes, not an MVR field on Decision itself.

§7.2.7 Authority

Authority records the right to act. The delegated_from field creates the delegation chain that B5 (§5) enforces: every non-root authority must trace through a chain that terminates at a root. Root authorities satisfy B5 through the isRootAuthority flag rather than delegated_from; the B5 shape handles this disjunction.

§7.2.8 Account

Account is a per-event linkage record. Each Account instance captures one governance action: who did what, when, to which primitive, and with what outcome. This is not a periodic aggregation — Account does not contain period boundaries, rollup counts, or summary statistics. When temporal framing is needed, aggregation queries scope by Cycle (§28).

The context_snapshot field captures the conditions under which the action was taken. This enables post-hoc audit to determine reasonableness: not just what was decided, but what was known at decision time. The authority_chain field records the delegation path from the actor's immediate authority to the root, enabling verification that the actor had the right to act.

Invariant B4 (§5) requires every Decision to link to an Account. The Decision references the Account event that captures state context at decision time. This relationship is enforced by B4 shapes as an inter-record constraint, not as an MVR field.

§7.2.9 Constraint

Constraint records the rules that govern governance itself. The applies_to field and enforcement_mode field together satisfy B6 (§5): every constraint must bind at least one primitive target and specify how it is enforced. The four enforcement modes correspond to the enforcement mode specification in §5.4.

§7.3 Validation Architecture

MVR validation ensures that every Tier 1 record contains the fields required for governance. It operates alongside behavioral invariant validation (§5) as two complementary layers of SHACL enforcement.

Two Layers of Validation

MVR shapes and invariant shapes target the same primitive classes. A dlp:Evidence instance is validated against both dlpmvr:EvidenceShape (are all MVR fields present?) and dlps:B3-EvidenceRequiresTruthType (is the truth type from the controlled vocabulary?). Both must pass for the record to be valid.

Conjunction Semantics

SHACL applies all shapes that target a given class via conjunction — a node must conform to every applicable shape, not just one. When a substrate loads both the MVR shapes graph and the invariant shapes graph, every primitive instance is validated against both layers automatically. No explicit join or ordering is required.

This conjunction produces the complete validation picture:

Intent, Capacity, and Account have MVR shapes but no dedicated invariant shapes targeting them directly. They participate in invariant enforcement as link targets — Capacity is referenced by B2 through Commitment, Account is referenced by B4 through Decision.

Shape Overlap

Some fields appear in both MVR shapes and invariant shapes. The truth_type field on Evidence is constrained by both dlpmvr:EvidenceShape (field must be present) and dlps:B3-EvidenceRequiresTruthType (field value must be in the three-value vocabulary). Similarly, the applies_to and enforcement_mode fields on Constraint appear in both dlpmvr:ConstraintShape and dlps:B6-ConstraintBindsPrimitives.

This overlap is intentional and harmless. SHACL conjunction semantics apply both constraints. If the constraints agree (and they do — the MVR shape checks presence, the invariant shape checks the value), conjunction produces correct combined validation. The overlap serves documentation clarity: each shapes file is self-contained and readable without cross-referencing.

Validation Timing

MVR validation runs on every write operation. It is a Pass 1 check (§5.3) — SHACL Core, always Blocking, O(1) per instance. A record missing an MVR field is rejected before invariant shapes are evaluated. This ordering is pragmatic: checking field presence before checking inter-record relationships avoids confusing error messages (a missing commitment_id field would trigger both the MVR shape and the B1 shape; running MVR first reports the root cause).

§7.4 Extension Framework

Extensions add optional fields beyond the MVR for specialized functionality. Extensions do not change MVR compliance — a record with all required MVR fields is compliant regardless of whether extension fields are present or absent.

Namespace-Scoped Extensions

Extensions connect to the Namespace four-tier governance model (§4.6):

MVR fields are Core namespace by definition. They are the protocol-level field requirements that every substrate must enforce. Domain, Tenant, and Sandbox extensions layer additional fields on top of the MVR base without modifying it.

SHACL Extension Layering

Extensions are expressed as SHACL shapes layered on top of MVR validation shapes. Each extension field maps to a sh:property constraint within an extension shape that targets the same primitive class as the base MVR shape.

The layering model:

Layer 1: MVR base shapes (dlpmvr: prefix). Always loaded. Enforce the universal field requirements defined in §7.2. These shapes are the same for every substrate, every profile, every organization.

Layer 2: Extension shapes (scoped by Namespace). Loaded per-profile. Add field requirements beyond the MVR. An extension shape for the Evidence primitive adds properties to dlp:Evidence — SHACL conjunction semantics apply the extension constraints alongside the MVR constraints automatically.

Layer 3: Profile-specific extension sets. Each substrate profile (EAS, BAS, PAS) activates a different combination of extension shapes based on organizational context. An enterprise assurance substrate might activate Domain extensions for GAGAS terminology plus Tenant extensions for organization-specific risk categories. A public accountability substrate might activate all four scopes.

Extension shapes follow the same naming convention as MVR shapes, scoped by Namespace tier:

Extension Graduation

Extensions graduate upward through Namespace tiers: Sandbox → Tenant → Domain. Core extensions require protocol lock and are not part of runtime graduation.

Graduation follows the same evidence-accumulation model as claims graduation (§6.5): an extension proves its value at one tier before promotion to the next. The graduation lifecycle:

Sandbox extensions carry an expiration date enforced by the substrate. If a Sandbox extension is not graduated to Tenant or Domain before its deadline, it expires — the extension shape is deactivated and the fields are no longer validated. This prevents experimental fields from accumulating indefinitely.

Extension Constraints

Extensions are subject to the same validation rules as MVR fields:

1. Type enforcement. Extension fields specify a data type. The extension shape enforces it.
2. Cardinality enforcement. Extension fields specify whether they are required within their scope. A Domain extension marked as required is enforced for all organizations in that domain.
3. Scope isolation. A Tenant extension for organization A does not affect organization B's validation. Extension shapes are activated per-Namespace — they validate only within the Namespace where they are defined.
4. No MVR interference. Extensions cannot weaken MVR constraints. An extension shape may add fields to a primitive but cannot remove or relax existing MVR field requirements. SHACL conjunction semantics enforce this structurally: the MVR shape always applies regardless of extension configuration.

Boundaries

This section specifies field requirements for Tier 1 primitives only. It does NOT specify: how Tier 2 infrastructure primitives are implemented (§4.6.1), how Tiers 3–5 are extended beyond the MVR (§7.4), the detailed SHACL shape definitions (shapes graph, separate artifact), or operational validation procedures (substrate-specific).

Positions

Locked. MVR for nine Tier 1 primitives with defined field sets. Field minimalism principle: no required field without governance semantic necessity, invariant enforcement necessity, or cross-substrate interoperability necessity. Two-layer validation architecture: MVR shapes (intra-record) + invariant shapes (inter-record). Extension framework with Namespace-scoped extensions graduating from Sandbox to Domain.

Lineage

v1.0.0 (February 25, 2026): Base lock. MVR field definitions for all nine Tier 1 primitives. Two-layer validation. v2.0.0 (March 19, 2026): Post-lock composition. Extension framework formalized with Namespace tiering and graduation lifecycle.

Commitments

SDK implementations MUST enforce all MVR fields as mandatory at write time. SDK implementations MUST reject records missing any MVR field before invariant validation begins. SDK implementations MUST support the extension layering model with SHACL conjunction semantics. SDK implementations MUST enforce Sandbox extension expiration dates.

Coverage

All nine Tier 1 primitives fully specified with: required fields, field types, field descriptions, semantic grounding. Validation architecture with two-layer enforcement and conjunction semantics. Extension framework with Namespace scopes, layering model, and graduation lifecycle. Field minimalism rationale for each primitive.

Addressing

Document ID: s07-minimum-viable-record. Part: II (Core Protocol). Individual primitive MVR specifications addressable as Intent-MVR, Commitment-MVR, etc. Extension shapes addressable by naming convention. Cross-references use [s07-minimum-viable-record.{section-id}] notation.

Attribution

Primary author: Cam (founder, GrytLabs). Research and composition support: Claude (Anthropic).

Situational Frame

MVR fields were selected through three-dimension necessity analysis across 17 sprints. The extension framework emerged from organizational diversity analysis showing that Tier 3–5 field requirements vary by domain and organizational context. Namespace tiering with Sandbox graduation was designed to enable safe experimentation without accumulating technical debt.

Scope Governance

Core namespace: dlp. MVR fields are core-namespace objects immutable after protocol lock. Domain, Tenant, and Sandbox extensions operate via the Namespace governance model (§4.6). Each extension scope has its own governing authority and graduation pathway.

Framing

MVR is the protocol's data minimalism layer — the set of fields every DLP-compliant substrate must enforce, enabling interoperability and auditability without forcing over-specification. Extensions provide the flexibility mechanism for organizational and domain variation without compromising the universal field standard.

Adaptation

The extension framework with Namespace tiering and graduation lifecycle was added post-lock when organizational analysis revealed diversity in field requirements across profiles (EAS, BAS, PAS) and domains. This enables Sandbox experimentation with automatic expiration, preventing extensions from becoming technical debt while supporting innovation.

Readiness

This section is ready for SDK implementation. All MVR field definitions are translatable to TypeScript interfaces and SHACL shapes. The extension framework with Namespace scoping and SHACL layering is implementable with standard RDF tooling. Sandbox expiration enforcement requires timestamp tracking on extension shapes.

Meaning Resolution

No meaning resolution for this document.

Perception Surface

No perception surface for this document. MVR is internal protocol specification. External systems provide data that enters as Evidence or Account records; MVR validation occurs on that data before it becomes part of the governance substrate.

Temporal Governance

No temporal governance for this document. MVR fields are not time-bounded; they apply to all records regardless of creation time. Sandbox extension expiration dates are the only temporal constraint, enforced per-extension by the substrate.