Decisions

This page records high-signal decisions that shape Universal Manifest’s direction and constraints.

2026-02-11 — v0.1 bootstrap decisions

Separate spec repository

• Universal Manifest is maintained as its own repository (independent of LAN), to keep the standard adoptable by third parties.

Manifest ID generation (@id)

• v0.1 recommendation: issuers generate @id as urn:uuid:<uuidv4>.
• Rationale: globally unique, offline-safe, and avoids premature content-addressing commitments.

Device caching + logging (public display / Shield)

• Cache the full manifest while actively in use.
• Persist only manifest ID references (@id) in logs/telemetry.
• Future recovery workflows may use those IDs, but recovery is intentionally out of scope for v0.1.

Security scope (v0.1)

• signature exists only as a permissive placeholder envelope.
• Interoperable signing/verification is deferred until canonicalization is explicit (v0.2 direction).

2026-02-12 — Public domain split

Standards and docs

• Canonical standards/docs domain: universalmanifest.net.

UMID resolver

• Canonical resolver domain: myum.net, with lookup pattern https://myum.net/{UMID}.

2026-02-13 — Official done-done framework adopted

• Adopt a formal, gate-based done-done framework as the release-readiness authority (see Governance → Done-Done).

2026-02-13 — Record-primitive vision direction captured (vision-level)

CEO direction captured as vision (not yet normative spec):

• UM composition should center on a Record primitive:
  • records can be leaf or nested/container
  • records can be exchanged via push and pull/request
  • records may declare their own schema/standards context
  • records/attributes require permission states with field-level policy control

Policy:

• treat this as vision guidance until translated into versioned spec + conformance artifacts

2026-02-17 — Journeys → tests as proof

• Canonical user journeys must map to an executable end-to-end proof suite.
• Rationale: prevent “done by documentation” without runnable proof.

2026-02-17 — v0.2 signature profile baseline

• Adopt a pragmatic v0.2 integrity baseline:
  • canonicalization: JCS (RFC 8785)
  • signature: Ed25519
  • encoding: base64url
• Data Integrity is a future additive profile, not an either-or decision.

2026-02-17 — TypeScript helper package policy

There is a TypeScript helper package used as a reference validator/proof runner.

Current policy:

• keep it private/internal for now (do not publish yet)
• treat it as a developer-experience artifact, not the standard itself