Quick Start

This is the implementer quick start for Universal Manifest v0.1.

If you are brand new to the project, read Getting Started -> What Is Universal Manifest? first.

Want to see working code? Check out the code examples — start with the hello-world example to create your first manifest in under a minute.

For implementers in other languages

The examples on this page use the TypeScript reference implementation for convenience. You can implement the same validation logic in any language. The specification, conformance requirements, and fixtures are language-neutral. See Build Your Own Implementation for a language-neutral checklist, then use the Implementation Guide and Quick Reference for the conformance-level decision flow and report-ready checklist. If you are upgrading an existing implementation, follow the Migration Guide: v0.1 to v0.2.

1) Understand the format (15 minutes)

Read:

• Getting Started -> Concepts
• Specification -> v0.1

Key takeaways you need:

• A Universal Manifest is a JSON-LD document with a unique identifier (@id, also called a UMID — Universal Manifest Identifier), a subject (who or what the manifest is about), and a validity window (issuedAt/expiresAt timestamps that define when the manifest was created and when it expires).
• Consumers must ignore unknown fields safely. This is what makes the format forward-compatible: older systems will not break when new fields are added.
• The manifest is a container: it has standard header fields and can hold different kinds of data inside. It can contain embedded shards (optional, named data sections) and/or pointers (URL references to data stored at its authoritative source, so you link to data instead of copying it).

2) Implement the minimum viable consumer (v0.1)

Your consumer (any system that reads and acts on a manifest) should:

1. Require core fields: @context, @id, @type, manifestVersion, subject, issuedAt, expiresAt
2. Enforce the validity window (check whether the manifest has expired):
   • reject if now > expiresAt
   • (recommended) reject if issuedAt > expiresAt
3. Treat unknown fields as ignorable
4. Read only the parts you understand:
   • shards — optional, named data sections (include only the ones relevant to your use case)
   • pointers — URL references to data at its authoritative source
   • claims, consents, devices — optional sections for verified assertions, user permissions, and device records

3) Validate against spec files and test examples

Official spec files

• JSON-LD vocabulary file (defines what fields in a manifest mean)
• JSON Schema validation file (checks the structure of a manifest)
• Auto-discovery config file (a .well-known URL, per RFC 8615, for automatic discovery of UM configuration)

Test examples (fixtures)

Start with:

• Getting Started -> Stub Manifests (near-real examples showing the intended structure)
• Conformance -> v0.1 (what a consumer must do to claim support)

Visual sanity check (optional)

Open the interactive test tool, which loads and displays manifest examples in your browser:

• Interactive test tool (harness)

Use the Manifest Workbench when you need a browser-based tool for creating, editing, validating, and exporting manifests:

• Manifest Workbench

If you are testing a resolver (a web service that looks up manifests by UMID) implementation too, read:

• Conformance -> Resolver (myum.net)