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 any single runtime), 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 / constrained device)

• 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 captured (vision-level)

Vision captured (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

2026-03-06 — Composite-stack and active-runtime direction

• Treat Universal Manifest architecture as a composite stack with separate trust, data, and interaction layers.
• Keep the manifest pointer-first and storage-neutral; large or mutable artifacts stay behind references.
• A subject-controlled runtime (wallet, client, agent, or local-first sync layer) is a valid non-normative implementation pattern for consent mediation and push/pull exchange.
• Closed-surface bridge adapters remain implementation detail, not UM conformance behavior.

2026-03-06 — Volatile protocol selection, proximity presentation, and federation strategy remain Research-First

• Keep current architecture guidance and lane caveats, but do not promote any single protocol family, proximity transport, or federation substrate into stronger UM guidance without explicit promotion evidence.
• Treat protocol recommendation governance, proximity presentation boundaries, and federation/bridge strategy as separate Research-First topics.
• Do not add new core-schema obligations for these areas at this stage.

2026-03-06 — Time-sensitive protocol-family status belongs in a dated matrix

• Keep standards-positioning docs focused on relationship and scope.
• Track volatile protocol-family maturity and recommendation strength in a dated currency matrix instead of freezing those judgments inline across many docs.
• Propagate only matrix-approved wording into narrative or integration pages.

2026-03-06 — Federation and bridge strategy is role-based

• Keep the subject-controlled runtime as the canonical private-state authority for current consent, pointer routing, freshness, and disclosure decisions.
• Evaluate external substrates by role, not as a single winner: canonical private state, public projection, trust federation, relay/sync, edge availability, and closed-surface bridging.
• Do not present any one substrate as “the UM federation layer”.
• Closed-surface bridge adapters remain implementation detail, not UM conformance behavior.

2026-03-06 — OMB Wiki is discovery-only for spatial-fabric detail

• Treat omb.wiki as a discovery map, not the source of record.
• Keep the current RP1/MSF boundary: no new required UM core fields, optional pointers/facets only, and runtime-managed live spatial state.
• Refresh primary RP1/MSF sources before strengthening integration guidance from the wiki’s newly surfaced detail.

2026-03-06 — RP1/MSF scope composition and asset delivery stay non-normative

• Keep parent/root scope, child scope, and attachment-point behavior in optional pointers and compact facets only.
• Keep live scope trees, tool state, and session/view state out of the UM core contract.
• Keep gltf/glb asset delivery external and pointer-first, with only lightweight profile hints in the manifest.

2026-03-06 — RP1/MSF stale attachments and revoked sessions fail closed

• Keep RP1/MSF freshness/revocation behavior in integration guidance and executable proof, not in the v0.1 core contract.
• Optional pointer metadata such as observedAt, expiresAt, and status is acceptable for RP1/MSF examples.
• Stale rp1.attachmentIndex evidence blocks child-scope traversal.
• Expired or revoked rp1.sessionContext evidence blocks replay/reuse.