Universal Manifest

Use cases

UM in the RP1 Spatial Fabric

RP1 publishes the browser engine, the spatial fabric, the service protocol, and the scene object model. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt taxonomy the audit layer produces, and the projection contracts the receiver roles enforce.

An RP1 spatial fabric diagram with the browser holding the manifest and multiple sandboxed services receiving distinct projections; receipt chain emerging from the boundary.

Load-bearing thesis

UM is the portable signed envelope that RP1's open-metaverse-browser architecture describes but does not standardize.

Universal Manifest is the portable signed credential and state envelope that RP1's open-metaverse-browser architecture describes but does not standardize. Every time RP1's documentation says "the browser caches credentials and presents them to services," it describes a Universal Manifest.

UM is the crucial missing piece of the RP1 stack. Not a competitor, not a fork, not an identity wrapper bolted on, but the layer the architecture assumes exists. RP1 publishes the browser engine, the spatial fabric, the service protocol, the scene object model, and the developer roadmap. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt structure the audit layer produces, and the projection contracts the receiver roles enforce. They fit together without either side bending.

The browser holds the envelope. The fabric reads it. The services receive only what their receiver-role contract authorizes. The receipt records what happened.

This thesis is not aspirational. It is the result of three rounds of integration analysis covering 14 primary surfaces, 8 secondary surfaces, a typed receipt taxonomy, a normative performance-engineering profile, a category-trust security refactor, two enterprise worked examples, and three convergent external reviews. The thesis is what falls out of doing the work.

Watch the series

The RP1 integration series, in viewing order.

Six short explainers that walk the RP1 integration from the top down. Start with the overview, then follow each piece of the fabric in order.

Pillar

RP1 Integration

How Universal Manifest gives RP1 a portable envelope for identity, assets, and permissions.

Deep dive

Universal Manifest and RP1: Spatial Addressing

How an RP1 place address becomes a consent-gated bookmark.

Deep dive

Universal Manifest and RP1: RMAP Service Credentials

How visitors prove RP1 service access locally.

Deep dive

Universal Manifest and RP1: SOM Branch Authorization

How RP1 checks permission before anything is built into a sub-world or overlay.

Deep dive

Universal Manifest and RP1: The Content Trust Chain

How RP1 worlds verify imported assets before loading.

Deep dive

Universal Manifest and RP1: Primary and Secondary Fabric Composition

How layered RP1 worlds stay permissioned as you move.

Scene

A spatial fabric in operation. The browser mediating every service boundary.

A spatial fabric is running. Inside the fabric, multiple services execute in sandboxed WASM instances: a map service, a navigation service, a safety service, an inventory service, a wayfinding service, a commerce service. They share no memory. They do not trust each other by default. The browser mediates everything that crosses a service boundary.

A user arrives. Their identity service provider issued a UM manifest this morning. The browser holds the manifest in cache. As each fabric service comes into proximity, the browser presents the projection that service's receiver role authorizes. The safety service reads safety credentials. The map service reads location consent. The commerce service reads payment attestation. None of them see fields outside their contract. Inter-service messages cross the browser-mediated channel only when the inter-service authorization manifest names the source, the target category, and the message type. The receipt chain extends with one signed event per decision.

Nothing about that scene is hypothetical. RP1's architecture describes a browser that caches credentials and presents them to services. UM is the credential format the browser caches. Every service interaction the architecture diagrams is a projection of the manifest the browser holds.

What changes

For RP1, for the broader open-metaverse-browser cohort, and for enterprise readers.

For RP1, adopting UM means adopting one cryptographically verifiable format for the identity, consent, trust, and audit data the architecture already requires but has not yet standardized. The browser stops needing to invent its own credential cache shape; the services stop needing to define their own credential read paths; the audit layer stops needing to design its own event taxonomy. The portable-credential decision becomes "use UM," not "design a credential format."

For the broader open-metaverse-browser cohort (using RP1's own term for the implementer community), UM becomes a profile-able envelope that other browser engines can adopt. The same manifest the RP1 browser caches works in a different browser-engine implementation, with the same projection contracts, the same consent vocabulary, the same receipt taxonomy. The credential becomes portable across browser engines, not just across services within one engine.

For enterprise readers, the manifest becomes the audit-trail anchor. A worker's shift produces a signed chain of receipts: who entered which zone, which services authorized which capabilities, which sensors stayed denied, which inter-service messages crossed which categories, which mandatory services activated, which expired credentials triggered alerts. The chain is hashed locally and sealed into a departure manifest at end of shift. Compliance with HIPAA, OSHA, the EU Accessibility Act, and similar regulated regimes stops being a per-fabric implementation problem and becomes a structural property of the credential format.

Three scenes

The thesis, made tangible.

Three concrete moments where UM does the work inside an RP1 fabric. Each one follows a person or a module through a single boundary, so you can see exactly what the browser presents and what the receipt records.

Scene 01

Service-to-service handoff at a fabric boundary

You walk into a spatial fabric. Your browser has been holding your manifest since you signed in this morning, so there is nothing to scan and no form to fill. The fabric asks for proof over RMAP, your browser presents the manifest once, and the session stays open until the manifest expires.

The fabric checks the signature, confirms it has not expired, sees that a trusted provider vouched you are a real person, and lets you in.

Three services light up around you, and each one gets only its slice. The map service sees where you are. A retail kiosk by the door sees your display name and position, nothing more. A bar wants to know you are over 18, so it gets a yes to that one question and never sees your birthday. One envelope, three different views.

The browser brokered every handoff, no service saw a field outside its contract, and each decision left a signed line on the receipt.

Touches identity, entity type, RMAP service credentials, consent, zero-knowledge age proof, and spatial addressing, each step logged to the receipt.

Three fabric services receiving distinct projections of the visitor's manifest while the browser mediates between them.
Scene 02

A maintenance shift on the factory floor

A technician puts on AR glasses to start a shift on a big plant floor. Their manifest already carries the things the job depends on: signed safety certifications, an equipment-access credential for the gear and zones they are cleared for, the plant's own policy, and a list of which sensors stay on and which stay off. Eye tracking and the camera are off, and the plant policy keeps them off.

At the door the fabric checks all of that, then switches on the two services the plant requires: safety alerts and emergency evacuation.

At a hydraulic press, the monitoring service gets just enough to confirm the technician is cleared, and full telemetry appears in the glasses. That service writes only to its own corner of the scene tree and cannot reach into the safety service's branch.

A training guide walks them through a pump swap. Before it runs, the fabric checks the module the same way an app store checks a signed app: right fingerprint, real publisher, not revoked.

Then a forklift rolls into the next aisle. The safety service needs to warn the navigation service to reroute foot traffic. That message only goes through because the plant pre-approved exactly that channel for exactly that kind of alert. A warning lights up in the glasses, and because safety is mandatory here, the technician cannot wave it away.

When the shift ends, the manifest expires, every service drops its access, and the whole run is sealed into a signed end-of-shift record.

Touches identity, equipment-access credentials, consent, the content-trust check, scene-tree write permissions, and service-to-service messaging.

Factory floor in AR: maintenance technician at a hydraulic press station; safety overlay rendering; equipment-access credential bound into the manifest.
Scene 03

Vetting code before it runs

A new fabric is coming together, and a vendor offers a predictive-maintenance module. The browser will not run it on trust. First it checks three things: the file matches the fingerprint the publisher signed, the publisher is who they claim to be and has not been revoked, and their signature on the code is real.

All three pass. The module runs, but only with the access its publisher actually declared, writing to its own branch of the scene and nowhere else.

A second module shows up from a publisher the fabric revoked after the manifest was issued. The browser blocks it cold. The block and the reason go into the audit log, and the code never reaches the runtime.

Touches the content-trust check, the package and service catalog, and scene-tree write permissions, with a signed receipt either way.

A WASM module being verified at the content trust check: module hash, publisher DID resolution, signature verification, all happening before the module reaches runtime.

Connection to standards

RP1's stack names its components by their own terms. UM occupies the credential layer the stack assumes but does not standardize.

RP1's open-metaverse-browser stack (the proper-noun name for RP1's architecture) is the most architecturally complete published specification of its kind to date. Below, each RP1 component is named in RP1's own terms.

  • MBE (Modular Browser Engine, "Sneeze")

    The five-layer browser engine. Layer 5 is content creation, Layer 4 is services and identity providers, Layer 3 is the browser engine itself (RMAP, SOM, WASM runtime, ANARI, OpenXR, SPIR-V validation), Layer 2 is OS drivers and runtimes, Layer 1 is hardware. UM operates at the Layer 3 / Layer 4 boundary: identity service providers (Layer 4) issue manifests; the browser (Layer 3) caches them; spatial fabrics and services (Layer 4) verify and consume them.

  • RMAP (Remote Model Access Protocol)

    RP1's three-layer service protocol: a Service layer (session management, authentication), a Model layer (observable objects), a Source layer (wire-protocol adapter). UM is presented and consumed at the Service layer during session establishment. UM does not travel through the Source layer. The credential is verified once at session admission and the verified session is retained until the manifest's expiresAt.

  • MVMF (Metaversal Model Foundation)

    RP1's underlying service driver model: the open-standard real-time API foundation RP1's services are built on. UM is consumed within the service-driver authentication step. (Earlier RP1 documentation references SMAP under what may be the same protocol's prior name; UM's integration anchors to the authoritative current naming.)

  • SOM (Scene Object Model)

    RP1's authority-scoped scene tree. UM's SOM branch authorization facet declares which branch a service is permitted to write to. The SOM enforces the authorization; UM provides the verifiable claim.

  • UM (the credential, consent, trust, and audit envelope)

    UM is not an alternative to any of the above. UM is the credential, consent, trust, and audit format that the architecture already requires. Adopting UM means closing the open question RP1 has explicitly deferred: what shape does the portable credential take?

Receipt taxonomy

Sixteen typed event classes, batched and chained.

UM's six-stage evaluation sequence gets a typed event taxonomy at the receipt stage: session-admitted, session-denied, session-degraded, capability-granted, capability-denied, capability-revoked, package-trusted, package-rejected, policy-override-applied, cross-fabric-portal-cleared, terms-acknowledged, co-presence-entity-type-asserted, avatar-retrieved, avatar-substituted, shader-trusted, shader-rejected. The chain is local-hashed and sealed into a departure manifest at session end. Sample below is from the factory-floor scene.

evaluation receipt rp1-spatial-fabric
session-admitted fabric / factory-A
capability-granted / hydraulic-press telemetry equipment-access credential matched
package-trusted / training-module-v2 hash + publisher signature ok
capability-granted / safety overlay (mandatory) enterprise policy
capability-granted / safety-to-navigation channel inter-service authorization verified
capability-denied / eye tracking consent (enterprise reinforced)
capability-denied / camera passthrough consent (enterprise reinforced)
facet / unrelated credentials not projected
session-degraded / advertising category enterprise policy prohibits
cross-fabric-portal-cleared / maintenance-bay zone authorization verified
session-sealed departure manifest written at expiresAt
result: shift sealed; receipt chain archived

Closing

The architecture and the envelope are designed for each other.

RP1 publishes the browser engine, the spatial fabric, the service protocol, and the scene object model. UM publishes the credential format the engine caches, the consent vocabulary the services read, the trust chain the modules verify against, the receipt taxonomy the audit layer produces, and the projection contracts the receiver roles enforce. The browser does not need to invent the credential format. The services do not need to invent the credential read path. The audit layer does not need to invent the event taxonomy. The portable-credential decision becomes "use UM."