Skip to content
Universal Manifest

Conformance v0.1

This page defines what it means to claim Universal Manifest v0.1 conformance.

If you are validating an external implementation, start with the language-neutral Standalone Conformance Suite workflow.

v0.1 goals:

  • easy to adopt (even without JSON-LD tooling)
  • safe in local-first environments (TTL + bounded caching)
  • forward compatible (unknown fields MUST be ignored)

Conformance targets

Section titled “Conformance targets”

Consumer

Section titled “Consumer”

A consumer receives a manifest and uses it to drive a surface (display, admin, web profile, etc.).

Consumer MUST:

  • Treat a value as a v0.1 Universal Manifest when it has the required fields and @type includes um:Manifest.
  • Ignore unknown fields safely (top-level, shard/entity shapes, and section item shapes).
  • Enforce TTL for use: MUST NOT use if now > expiresAt.
  • Sanity-check issuedAt / expiresAt formats and ordering (issuedAt <= expiresAt).

Issuer

Section titled “Issuer”

An issuer produces a manifest for a subject and delivers it to consumers (directly or via an intermediary).

Issuer MUST / SHOULD:

  • Set @id to a globally unique URI (recommended: urn:uuid:<uuidv4>).
  • Set subject to a stable identifier URI.
  • Use short TTLs appropriate to the surface.

Fixtures (conformance tests)

Section titled “Fixtures (conformance tests)”

To claim v0.1 conformance, an implementation MUST:

  1. Accept all valid fixtures
  2. Reject all invalid fixtures

Valid fixtures (v0.1)

Section titled “Valid fixtures (v0.1)”

Invalid fixtures (v0.1)

Section titled “Invalid fixtures (v0.1)”

Quick visual check

Section titled “Quick visual check”

Use the harness to load these fixtures and inspect shape quickly:

Next

Section titled “Next”