How it works

The architecture of RSM ID

How permanent identifiers, registered names, governed Semantic Spaces, and policy-aware resolution work together — and where each rule is defined. Read top to bottom, or jump to the part you need.

  • RSM ID is the identity system.
  • RID identifies.
  • RRN names.
  • RSN identifies a Semantic Space.
  • The registry preserves identity and authority.
  • Resolution connects identities to trustworthy, policy-permitted representations.
  • Locus maintains authoritative semantic knowledge.
  • Atlas explores federated relationships.

Architecture

One identity system, not three identifiers

RSM ID is the identity infrastructure of RSM. It is governed by RSM Core and consumed — never redefined — by Locus, Atlas, Wellzai, Musewoods, and any other federated participant.

Its constructs fit together. A resource referent receives one permanent RID. Registered RRNs name it. An RSN names the Semantic Space responsible for it, and that space has an RID of its own. The RSM Identity Record binds these together, the Identity Registry preserves them, and Resolution connects them to permitted representations.

In plain terms

A library catalogue is a fair analogy: a shelf mark says which book, the catalogue entry records who catalogued it and where it lives, and the desk tells you what you may borrow. RSM ID provides all three, for resources of every kind, across independent organizations.

In the specification

Doc 08 §2.0 · Doc 09 §1

Consumers

Applications, AI agents, command-line tools, and Atlas — the federated explorer.

RSM ID · governed by RSM Core

  • RIDidentifies one resource, permanently
  • RRNnames it within a registered namespace
  • RSNnames a governed Semantic Space

RSM Identity Record

Binds an RID to its referent, names, issuing authority, lifecycle, and space binding.

Identity Registry

  • Prefix Registry
  • Authority Registry
  • Resource Identity Registry
  • Space Registry

Resolution

Verifies authority, applies policy, and returns a permitted representation or a typed status.

Federated Semantic Spaces · authoritative knowledge stays here

  • RSMrrn:451:451labs:us-ca:rsm:space/rootserved by Locus · own database
  • Wellzairrn:451:451labs:us-ca:wellzai:space/rootserved by Locus · own database
  • Musewoodsrrn:451:451labs:us-ca:musewoods:space/rootserved by Locus · own database
One architecture, not three identifier schemes. RSM ID holds identity and authority; Semantic Spaces, served by Locus, hold content and relationships; Atlas and applications consume both through resolution. Spaces are the proposed initial federation; nothing shown is deployed.
Diagram source (Mermaid)

Adapted from Document 08 §2.0 and Document 09 §1.1. Portable definition; paste it into any Mermaid renderer.

Mermaid
flowchart TB
    APPS["Applications, agents, Atlas"]
    subgraph RSMID["RSM ID — governed by RSM Core"]
        RID["RID: permanent identifier"]
        RRN["RRN: registered resource name"]
        RSN["RSN: name of a Semantic Space"]
        IR["RSM Identity Record"]
        REG[("Identity Registry: prefixes, authorities, identities, spaces")]
        RES["Policy-aware resolver"]
        RID --> IR
        RRN --> IR
        RSN --> IR
        IR --> REG
        REG --> RES
    end
    APPS --> RES
    RES --> S1["RSM space on Locus"]
    RES --> S2["Wellzai space on Locus"]
    RES --> S3["Musewoods space on Locus"]

Identity record

The RSM Identity Record

The identity record is the authoritative, registry-level envelope for one RID, and the RID is its key. It binds the RID to one referent descriptor and preserves what is needed so that the RID can never be reassigned: the issuing namespace, creation time, lifecycle status, and issuance provenance.

Where they apply, it also keeps the registered names and their history, the authoritative space binding, delegated-authority history, and audit events. Semantic attributes, content, revisions, and relationships stay with the Semantic Space.

Not to be confused with

A second identity, or the resource itself. The record holds no required copy of the resource body, and it is not evidence that its issuer owns the real-world thing.

Doc 08 §5.3.1

Illustrative identity-record envelope
Document 08 §5.3.1 — not a finalized schema
rid: 451.7K4M9Q2X8D5P0R6T
referentDescriptor: Wellzai Outcome Formation Model
kind: document
primaryRrn: rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model
issuerPrefix: "451"
identityStatus: active
authoritativeSpace:
  rsn: rrn:451:451labs:us-ca:wellzai:space/root
  rid: <registered-space-rid>
issuanceProvenance: <registered-issuance-event>
registeredNames: <historical-and-current-name-records>
authorityBinding: <current-verified-binding>

Angle-bracketed values are placeholders in the specification. A versioned normative schema must fix field types before production conformance. In the reference implementation the logical record spans several tables — identities, names, bindings, events, external identifiers, prefixes, authorities, delegations — assembled into one view.

Source: Doc 08 §5.3.1 · Doc 09 §4.1.1

Registry

The Identity Registry preserves identity and authority

The registry is logical infrastructure with four parts. They may share one implementation at first; their contracts stay separate so they can later be federated and replicated.

  • Prefix Registry Globally unique RID prefix allocations, their controllers, signing keys, and status. Prefixes are never reused.
  • Authority Registry Authenticated namespace controllers and the delegations they grant — time-bounded, auditable, revocable.
  • Resource Identity Registry Permanent RID records, their names, lifecycle, bindings, and append-only events.
  • Space Registry Semantic Space identities (RID and RSN), capabilities, and authoritative resolution endpoints.

An authority must prove it may issue under a prefix. Resolvers distinguish trusted registry records from claims made by remote systems: a host that advertises a resource does not thereby become its authority.

Example

The prefix 451 is proposed for the controlled 451 federation. Until it is registered, no identifier under it can be issued — including every example on this site.

Not to be confused with

A universal content database, a blockchain, or a single server every lookup must contact.

Doc 08 §5.5 · Doc 09 §1.3

Issuance: generating a candidate is not registering an identity
  1. Authenticate the requesting principal and authorize issuance for the prefix, space, and kind.
  2. Validate the kind, requested RRN, referent descriptor, and idempotency key.
  3. Generate 80 cryptographically random bits and encode them as 16 Crockford Base32 characters.
  4. In one transaction, insert the RID, its first RRN, its space binding, an issuance event, and the idempotency record.
  5. On a uniqueness collision, retry with a new suffix. A failed issuance never returns an identifier as authoritative.

At a billion issuances under one prefix the chance of any suffix collision is about 4 × 10⁻⁷, which is why the atomic uniqueness check is mandatory rather than optional.

Source: Doc 08 §3.3 · Doc 08 §3.4 · Doc 09 §6.1

Resolution

Resolution returns what is trustworthy and permitted

A resolver accepts a canonical RID — or a registered RRN, RSN, or HTTPS identifier, which it first maps to the RID. It then works through a fixed sequence, and any step can end resolution with a typed status.

Any conforming resolver with access to trusted registry information may resolve an RID. A public gateway is a convenience, not the sole authority over every resource.

Not to be confused with

A URL redirect or a file download. The default web identifier should return a durable identity landing page; a redirect to an application is an explicit, permitted option.

Doc 08 §6.1 · Doc 08 §6.7

Example

A researcher may receive a provenance-rich description of a watershed, a public visitor a simpler one. Both describe the same watershed, the same RID.

Doc 08 §6.9

  1. Validate the RID grammarResolverNames and web identifiers are first mapped to the canonical RID.Typical status if it failsinvalid
  2. Resolve and verify the registered prefixPrefix RegistryThe prefix is a registered namespace — never a hostname.Typical status if it failsuntrustednot_found
  3. Locate the identity recordIdentity RegistryOr an authorized resolution service for it.Typical status if it failsnot_foundunavailable
  4. Verify namespace and resource authorityAuthority RegistryA host advertising a resource does not thereby become its authority.Typical status if it failsuntrusted
  5. Determine lifecycle and permissible disclosurePolicyUsing current governance metadata and the requester’s authenticated context.Typical status if it failsforbiddenretiredsuperseded
  6. Select a representationAuthoritative space · LocusBy content negotiation, language, capability, and access rights — the referent never changes.No failure status of its own
  7. Return the resultResolverMetadata, a representation, a permitted redirect, or a typed status.On successresolved
Resolution sequence. The seven steps are normative (Document 08 §6.3); the statuses are those of §6.8. Which status each failing step returns is this site’s reading — the HTTP transport profile that will fix the mapping has not been published. Where policy requires it, a forbidden resource and a nonexistent one may receive the same external response.
Diagram source (Mermaid)

Document 09 §7.4, following Document 08 §6.3. Portable definition; paste it into any Mermaid renderer.

Mermaid
sequenceDiagram
    participant C as Browser / Agent
    participant R as RSM Resolver
    participant P as Prefix Registry
    participant I as Identity Registry
    participant L as Authoritative Locus
    C->>R: Resolve RID
    R->>R: Validate RID grammar
    R->>P: Verify prefix and trust binding
    P-->>R: Registered authority
    R->>I: Locate RID identity record
    I-->>R: Space and active binding
    R->>R: Evaluate lifecycle and disclosure policy
    R->>L: Authorized representation request
    L-->>R: Permitted metadata / representation
    R-->>C: HTML, JSON, JSON-LD, or typed status
Content negotiation and typed statuses

Resolvers should support at least:

  • text/html — a human-readable identity landing page
  • application/ld+json — an interoperable JSON-LD representation
  • application/json — the RSM identity and resolution record
StatusMeaning
resolvedResource record successfully resolved
not_foundNo discoverable registered identity
forbiddenAccess prohibited by policy
retiredIdentity preserved; resource no longer active
supersededResource has identified successor references
unavailableAuthoritative service temporarily inaccessible
untrustedAuthority verification unsuccessful
invalidIdentifier violates the naming specification

Externally, a resource that may not be disclosed and one that does not exist may need to receive the same response, so that resolution does not leak existence.

Source: Doc 08 §6.5 · Doc 08 §6.8

Semantic Spaces

Identity in the registry, knowledge in the space

A Semantic Space is a governed logical resource responsible for the authoritative records of the resources it holds. It has its own RID and RSN, and it is distinct from the Go process, database, container, hostname, or front end that currently serves it.

Locus is the proposed engine that operates a space: resource storage, metadata, relationships, revisions, provenance, and policy. It consumes the RID, RRN, RSN, and resolution contracts from RSM Core and does not need to implement the global registry.

In plain terms

A Semantic Space is like an institution: it has a name and an identity, and it can move to a new building without becoming a different institution. Locus is the building.

In the specification

Doc 08 §4.5 · Doc 08 §7.3 · Doc 08 §10.2

Semantic Space · governed logical resource

Wellzai

RID
451.SD27J6QHDVEF0DYY
RSN
rrn:451:451labs:us-ca:wellzai:space/root

Permanent. Governance, authority, and the resources it is authoritative for are recorded against this identity.

  1. Locus deployment AGo process · SQLite database · host and regionbinding ended at relocation
  2. Locus deployment BNew host, new region, migrated databasecurrent binding
Semantic Space identity. The space is not its process, database, container, hostname, or front end. Relocating the Locus deployment changes an effective-dated binding in the registry; the space’s RID and RSN — and the RID of every resource in it — stay the same. Illustrative; the RID shown was generated for this site.
Diagram source (Mermaid)

Document 08 §4.5, §5.3.1; Document 09 §8.1. Portable definition; paste it into any Mermaid renderer.

Mermaid
flowchart LR
    subgraph SPACE["Semantic Space: Wellzai"]
        SRID["RID 451.SD27J6QHDVEF0DYY"]
        SRSN["RSN rrn:451:451labs:us-ca:wellzai:space/root"]
    end
    SPACE -- "binding (effective-dated)" --> L1["Locus deployment A"]
    SPACE -. "after relocation" .-> L2["Locus deployment B"]
    L1 --> D1[("wellzai.db")]
    L2 --> D2[("wellzai.db, new host")]

Federation

Shared identity without shared databases

Independently operated spaces connect through shared identity, registered authority, and resolution. They need not share a database, software, or hosting provider. The proposed initial federation is RSM, Wellzai, and Musewoods; others may join by registering namespace authority and operating a conforming space.

Atlas uses canonical RIDs to reconcile references and traverse relationships across spaces. A federated search may combine results using the RID as the deduplication key. Search relevance is kept apart from identity: two descriptions that look alike are not merged without the same RID or a verified equivalence.

Example

A Wellzai document extends the RSM concept of Formation and cites a Musewoods fieldnote. Each lives in its own space; the relationships name them by RID. Resolve the document.

In the specification

Doc 08 §10.3 · Doc 08 §10.5 · Doc 08 §13.2

  • RSM space

    Foundational models and concepts

    conceptFormation451.5VJC3VFV46EVR73V

    own database · own policies

  • Wellzai space

    Organizations, markets, outcome formation

    documentOutcome Formation Model451.7K4M9Q2X8D5P0R6T
    • extends 451.5VJC3VFV46EVR73V
    • references 451.5Z7MCTTCHRBCBS2S

    own database · own policies

  • Musewoods space

    Journals, stories, fieldnotes

    fieldnoteCode Meets Soil451.5Z7MCTTCHRBCBS2S

    own database · own policies

AtlasFollows the RIDs from Wellzai into RSM and Musewoods, fetching each representation from the space that owns it, and shows where every statement came from. It copies nothing into a central store.
Cross-system identity. Three independently governed spaces refer to each other’s resources by canonical RID. Relationships carry their predicate, originating space, and provenance; descriptions that merely look alike are never merged. Examples from Documents 08 and 09; the spaces are proposed and not deployed.
Diagram source (Mermaid)

Document 08 §7.4, §13.2; Document 09 §8.2. Portable definition; paste it into any Mermaid renderer.

Mermaid
flowchart LR
    subgraph RSM["RSM space"]
        C["Formation concept 451.5VJC3VFV46EVR73V"]
    end
    subgraph WZ["Wellzai space"]
        D["Outcome Formation Model 451.7K4M9Q2X8D5P0R6T"]
    end
    subgraph MW["Musewoods space"]
        F["Code Meets Soil 451.5Z7MCTTCHRBCBS2S"]
    end
    D -- "extends (by RID)" --> C
    D -- "references (by RID)" --> F
    ATLAS["Atlas"] -. "traverses by RID, keeps provenance" .-> D

Persistence

Resources change; their RID does not

An RID identifies a continuing resource. Revisions are immutable states of it, selected separately; a revision number is never embedded in the RID. Transfers keep an auditable chain of authority, and a withdrawn resource keeps its RID forever.

active
In use.
deprecated
Still valid; use is discouraged.
superseded
Has identified successor references.
retired
No longer active. Reserved forever; resolves to a tombstone where permitted.
reserved
Held, not yet in use.

Not to be confused with

Publication states such as draft or archived, or a content hash. Identity lifecycle is a registry status; a digest identifies bytes, and changes whenever they do.

Doc 08 §9.1 · Doc 08 §9.3

RID throughout451.7K4M9Q2X8D5P0R6T

  1. Registeredrev 1RID issued atomically with its first RRN, space binding, and audit event.RID unchanged
  2. Revisedrev 7Content and title revised. A revision selector can retrieve any earlier state.RID unchanged
  3. Relocatednew bindingThe Wellzai Locus deployment moves to a new host. The binding is updated.RID unchanged
  4. Transferrednew RRNStewardship moves to the RSM space. A successor RRN is registered; the original stays reserved.RID unchanged
  5. RetiredtombstoneWithdrawn. Resolution returns a tombstone; the RID is reserved forever.RID unchanged
Identity persistence. Renaming, revising, relocating, transferring, and retiring change metadata, bindings, and names — never the RID, and never by reassigning it. A substantially new edition may receive its own RID under documented granularity rules (Document 08 §3.6). Hypothetical history of the specification’s example document.
Diagram source (Mermaid)

Document 08 §3.5, §3.6, §9.2–9.5. Portable definition; paste it into any Mermaid renderer.

Mermaid
flowchart LR
    A["Registered"] --> B["Revised"] --> C["Relocated"] --> D["Transferred"] --> E["Retired"]
    RID(("RID 451.7K4M9Q2X8D5P0R6T — unchanged throughout"))
    A -.- RID
    E -.- RID

Governance and trust

Identity is not ownership, consent, or access

Jurisdiction is layered. The jurisdiction segment of an RRN records where the name was issued, and never changes. Current legal jurisdiction, bioregion, watershed, stewardship, and data residency are separate governance attributes that may evolve independently of the RID.

Roles stay separate. The authority that issued an identifier may differ from the legal owner, the operational custodian, or the community entitled to steward associated knowledge. Issuing an RID confers none of those rights.

Identity is not authentication. An RID identifies a resource; it is not proof of possession or authority. Authentication establishes who is asking; authorization decides what they may see. Sensitive people, places, ecological knowledge, and records may have permanent RIDs without being publicly discoverable.

Example

A watershed spanning several jurisdictions keeps one RID while its boundaries, bioregions, and stewards are recorded — and revised — as metadata.

Doc 08 §8.4

In the specification

Doc 08 §8.5 · Doc 08 §11.1 · Doc 08 §11.3

Status

What exists today

The specifications describe requirements and a reference design. They do not by themselves mean that anything has been built or deployed. As of 9 October 2026:

  • RID, RRN, RSN, identity records, and the resolution protocolDefined by specificationDocument 08, a proposed normative standard (v1.0, 9 October 2026). It is reproduced on this site. Doc 08 §2.0
  • Machine-readable RRN grammar (ABNF) and conformance suiteNot available yetRequired by Document 08 §4.1 and §14, not yet published. Doc 08 §4.1 · Doc 08 §14.5
  • Reference implementation: identity library, registry, resolver, CLIProposed reference architectureDesigned in Document 09 (Go, SQLite behind replaceable interfaces). Its code listings are interface shapes, not built components. Doc 09 §1.1 · Doc 09 §11.1
  • Identity Registry and the 451 prefixProposed reference architectureNo registry is operating and the 451 prefix is not registered, so no RID has been issued. Doc 08 §3.2 · Doc 08 §5.2
  • Public resolver at rmsid.orgProposed reference architectureThe hostname is proposed by Documents 08 and 09. It did not resolve in DNS when checked on 9 October 2026. Doc 08 §2.5 · Doc 09 §7.3
  • RSM, Wellzai, and Musewoods Semantic Spaces on Locus, explored through AtlasProposed reference architectureThe initial three-node federation is a proposed demonstration (Document 09 §12). No node is deployed. Doc 08 §10.4 · Doc 09 §12
  • RID, RRN, and RSN syntax checks on this websiteImplemented in this repositoryLexical checks only. They cannot tell whether an identifier is registered. Doc 08 §3.1 · Doc 08 §4.1
  • Resolver on this websiteDemonstrated on this siteFollows the resolution sequence over a small set of fictional demonstration records. It is not connected to any registry. Doc 08 §6.3
  • Namespace and identity registration for organizationsNot available yetThe rules are specified; no registration process exists yet. Doc 08 §10.6