Skip to content

ADR-0007: Value Types — MVP runtime, full-shaped manifest

ADR-0007: Value Types — MVP runtime, full-shaped manifest

Status

Accepted

Date

2026-06-24

Context

Value Types are the kernel’s type-safety atom: every Attribute, Action parameter, Event payload member, and Statement value has one, and storage/index/UI/SDK/agent/migration behavior derives from it. The source pack specifies this in extreme depth — per-type identity, version, constraints, canonical form, serialization, storage mapping, indexing, operators, aggregation, validation, normalization, privacy classification, authority hooks, migration/upcasting, UI hints, SDK generation, agent-tool schemas, projection behavior — plus a 5-phase rollout.

It is intellectually correct and also the single biggest hidden-scope risk in the plan: it is exactly where the architecture could vanish for months before a single fiber span ships. The proof lifecycle needs roughly a dozen types (Text, Timestamp, EntityRef, Confidence, Distance, LineString, Point, Polygon, Status, Money, Capacity, FiberCount). Most of the heavy machinery — versioning/upcasting (no v2 of anything exists yet), aggregation-inference safety (a SmartOps concern), per-type UI renderers — is premature for the proof.

Decision

MVP runtime, full-shaped manifest. Author ~12 Value Types using the complete manifest schema (so the on-disk shape is future-proof and won’t need rewriting), but implement only:

  • validation,
  • storage mapping,
  • SDK codegen.

Defer the implementation of: versioning/upcasting (until a real v2 forces it), aggregation-inference safety (until SmartOps), per-type UI renderers (fall back to type-family defaults).

This is the project’s guiding discipline applied to types: shape for the vision, size the runtime for the proof.

Alternatives Considered

Full system up front (all 5 phases)

  • Rejected: maximal type-safety, but a real risk of stalling for months before any domain value ships.

Thin types, defer the registry

Plain typed columns + lightweight validation now; formal registry later.

  • Rejected: fastest to first domain value, but retrofits type-safety into a working system — and the manifest shape would then be invented late and inconsistently.

Trim the vision permanently

Semantic types only for dangerous values; plain primitives elsewhere forever.

  • Rejected: gives up the platform-level consistency the kernel exists to provide.

Consequences

  • The manifest schema is designed once, in full; only its interpreter grows over time. Adding deferred behavior later does not require re-authoring existing Value Types.
  • Branches (ADR-0005) are the mechanism for testing Value Type version changes when versioning is eventually implemented.
  • The extension compiler must validate that every Attribute/parameter/payload/statement references a known Value Type from day one, even though only validation/storage/SDK are implemented.
  • Sensitive to: a premature customer demand for aggregation-safety or live migration would pull a deferred phase forward.