Skip to content
Universal Manifest

Reference Implementation

This page describes one reference implementation pattern for applying Universal Manifest without introducing new normative requirements.

Boundary: normative vs non-normative

Section titled “Boundary: normative vs non-normative”
  • Normative contract: Specification and Conformance sections
  • Non-normative guidance: this page

What you implement (minimum checklist)

Section titled “What you implement (minimum checklist)”

Inputs

Section titled “Inputs”
  • Manifest payloads conforming to v0.1 (or v0.2 when enabled)
  • Subject and policy data needed by display/admin surfaces
  • Change signal containing at least displayId and manifestId

Outputs

Section titled “Outputs”
  • Deterministic behavior driven by the current valid manifest
  • Operational telemetry keyed by manifest IDs
  • Explicit invalid/expired handling

Minimum behaviors

Section titled “Minimum behaviors”
  • Enforce TTL for use (expiresAt)
  • Ignore unknown fields safely
  • Cache full manifests only while in active use
  • Persist logs as ID references, not full payload history

Discovery and transport

Section titled “Discovery and transport”

Recommended discovery descriptor:

  • GET /.well-known/um/edge.json

Push signal minimum fields:

  • displayId
  • manifestId

Then pull the manifest by ID over HTTP.

Signature policy

Section titled “Signature policy”
  • v0.1: signature is optional (permissive placeholder)
  • v0.2: signature profile (JCS + Ed25519) can be required for trusted surfaces

Reference fixtures

Section titled “Reference fixtures”

Next

Section titled “Next”