Universal Manifest

Use cases Use case B

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.

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.

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.

The full integration depth (14 primary surfaces, 8 secondary surfaces, a typed receipt taxonomy, a category-trust split, a receiver-roles table, and full enterprise worked examples) lives in the research files linked in the deeper-reading section. The three scenes below are the entry door to that depth, chosen to make the breadth visible without forcing the reader to absorb all of it in one sitting.

Scene 01

Service-to-service handoff at a fabric boundary

You enter a spatial fabric. Your browser has held your manifest in cache since you authenticated with your identity service provider this morning. The fabric's service layer requests authentication via RMAP. Your browser presents your manifest at the Service layer: a one-time presentation; the verified session is retained until your manifest's expiresAt is reached.

The fabric resolves your DID, retrieves your public key, verifies the Ed25519 signature over the JCS-canonicalized manifest. The signature is valid. The TTL is current. The fabric reads your entity type (human, signed by a trusted identity service provider) and admits you. A session-admitted receipt is written.

Three services activate inside the fabric. Each one is a different receiver role; each one gets a different projection. The map service receives a position-bearing projection: persona, position, fabric attachment. A map-anchored retail kiosk at your nearest waypoint receives a narrower projection: display name, entity type, position, and the consent set its service-requirement manifest names. A commerce service inside the fabric wants to verify you are over 18: it receives an age verifiable credential presented as a ZKP, learning only that the threshold is met. Three projections; one envelope.

The browser mediated every projection. No service received a facet outside its receiver-role contract. Each decision produced a typed receipt. The chain is local-hashed and batched per the receipt taxonomy's 5-60 second cadence; safety-critical receipts (if any had occurred) would have flushed immediately.

Surfaces exercised: 1 Identity Credential, 2 Entity Type, 4 RMAP Service Credentials, 5 Consent Model, 7 ZKP Selective Disclosure, 10 Spatial Addressing, plus the Stage 6 receipt taxonomy and the receiver-role table.

Scene 02

Spatial mapping for commercial: the factory floor

A maintenance technician puts on AR glasses at the start of an 8-hour shift in a 40,000-square-foot manufacturing plant. The browser loads the technician's manifest from the corporate identity service provider. The manifest carries persona, three signed safety certifications (OSHA 30-Hour, Lockout/Tagout Qualified Person, Confined Space Entry), an equipment-access credential authorizing five equipment categories and three zones, an enterprise policy facet declaring mandatory safety-alert and emergency-evacuation services and prohibiting social / entertainment / advertising categories, and a derived-variant sensor consent set (location allowed, eye tracking denied, hand tracking allowed, room geometry denied, camera passthrough denied, GPS denied; the enterprise policy reinforces the sensor denials).

The technician walks the fabric for the full shift. At entry, the fabric verifies the signature, reads the consents, applies the enterprise policy, activates the two mandatory services. At a hydraulic press station, the equipment monitoring service receives a scoped projection containing the equipment-access credential; the press's category is in the authorized list and full telemetry renders. The service writes to its authorized SOM branch (/factory/production-A/press-07/telemetry); it cannot write to the safety service's branch.

A training service guides the technician through a pump replacement. Its WASM module passes the content trust chain check (module hash + publisher signature + revocation lookup) before execution. The training service reads the certifications and the equipment-access level to confirm authorization. The safety monitoring service detects a forklift in the adjacent aisle and needs to tell the navigation service to reroute pedestrian traffic. The fabric operator's inter-service authorization manifest declares the safety-to-navigation channel with allowed message type hazard-alert. The browser verifies source DID, target category, message type, size limit, rate limit, and operator signature. All checks pass. The message forwards. The navigation service reroutes traffic. A safety overlay renders on the technician's glasses; because the safety service is mandatory per the enterprise policy, the technician cannot dismiss it.

At end of shift, the manifest's expiresAt is reached. All services invalidate their cached references. The receipt chain for the shift is sealed into a departure manifest.

Surfaces exercised: 1 Identity Credential, 4 RMAP Service Credentials, 5 Consent Model, 6 Content Trust Chain, 11 SOM Branch Authorization, 12 Inter-Service Communication Authorization.

Scene 03

Content trust at the module loader

A new fabric is being composed. A service vendor offers a predictive-maintenance module as a WASM binary. The browser refuses to execute the module until the content trust chain is verified. The chain has three steps: the module hash matches the hash signed by the publisher in their content trust attestation; the publisher DID resolves to a recognized identity that has not been revoked by the fabric operator's service-catalog manifest; the publisher's signature over the module bytes is valid.

All three checks pass. A package-trusted receipt is written. The module enters execution. It receives only the projection the publisher's service-requirement manifest declares; no facets outside that contract. The module writes to its assigned SOM branch and cannot touch any other.

A second module from a different publisher is offered. Its publisher DID has been revoked by the fabric operator since the manifest was issued. The browser blocks execution. A package-rejected receipt is written. The fabric operator's audit log records both the revocation and the block. The module never reaches the runtime.

Surfaces exercised: 6 Content Trust Chain, 6A RMAP Package and Service Catalog Manifest, 11 SOM Branch Authorization, plus the Stage 6 typed receipts (package-trusted, package-rejected).

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, internally called "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

Deeper reading

The full integration depth lives off-page.

The full RP1 integration depth (14 primary integration surfaces, 8 secondary surfaces, the typed Stage 6 receipt taxonomy, the Part 3.5 performance-engineering profile, the four-facet category-trust split, the twelve-row receiver-role table, the factory-floor and hospital-corridor enterprise worked examples) currently lives in the project's research files. A public landing for that depth is on the roadmap; until it lands, the research can be requested directly.

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."