For developers

Build on the RSM ID contract

RSM Core owns the identity types, grammar, registry contracts, resolver interfaces, and conformance fixtures. Applications consume them. This page maps each part to the section that defines it, and says plainly what has been built.

Specified, not deployed

The protocol is defined (Document 08) and a reference implementation is designed (Document 09). No registry, resolver, or public API is operating, the proposed host rmsid.org does not resolve, and this website exposes no API. Code listings in Document 09 are interface shapes, not released software.

Implementation contract

Eight logical modules

Defined by Doc 08 §12.1. The names describe logical modules, not a required repository layout; every language implementation shares one grammar and one set of test vectors.

identity

Defined by specification

Canonical RID types, generation, and validation. Pure, deterministic, and free of network or SQL dependencies.

Doc 08 §3.1 · Doc 09 §3.2

naming

Defined by specification

RRN and RSN parsing, formatting, and registration. Lowercase normalized segments, bounded lengths, no wildcards or traversal.

Doc 08 §4.1 · Doc 09 §2.2

registry

Proposed reference architecture

Prefix, authority, resource, and space contracts. Transactional issuance, append-only events, permanent non-reuse.

Doc 08 §5.2 · Doc 09 §4.1

resolution

Proposed reference architecture

Resolver request and result models. Typed statuses, content negotiation, policy-aware disclosure.

Doc 08 §6.3 · Doc 09 §7.4

governance

Defined by specification

Jurisdiction, stewardship, and policy references. Issuance jurisdiction is history, not a complete policy.

Doc 08 §8.6 · Doc 09 §8.4

provenance

Defined by specification

Issuance, transfer, lineage, and lifecycle evidence. Auditable chains of authority with effective dates.

Doc 08 §9.4 · Doc 09 §4.4

interop

Defined by specification

HTTPS, JSON, JSON-LD, and external ID mappings. External identifiers stay distinguishable from RSM-issued RIDs.

Doc 08 §6.4 · Doc 08 §7.5

conformance

Not available yet

Language-independent validation fixtures. Go, Rust, and TypeScript implementations share the same vectors.

Doc 08 §12.2 · Doc 09 §9.1

Identifiers

Grammar and test vectors

RID — Document 08 §3.1 (ABNF-style summary)

RID    = prefix "." suffix
prefix = "0" / %x31-39 *15DIGIT          ; 1–16 digits, no leading zero
suffix = 12*32CROCKFORD                  ; uppercase only
CROCKFORD = 0 1 2 3 4 5 6 7 8 9 A B C D E F G H J K M N P Q R S T V W X Y Z

; v1.0 default: 16 characters, 80 bits from a CSPRNG
; equality: exact canonical character comparison

RRN and RSN — Document 08 §4.1, §2.4

rrn:<realm>:<authority>:<jurisdiction>:<space>:<kind>/<resource-id>

; RSN = an RRN whose <kind> is "space"
rrn:451:451labs:us-ca:wellzai:space/root

The normative ABNF for RRNs has not been published (Doc 08 §4.1). Until it is, the segment character set is not fixed beyond “normalized lowercase ASCII identifiers”.

Not to be confused with

Lexical validity and registration. A parser can tell you an RID is well formed; only the registry can tell you it was issued.

Doc 09 §2.1

Implementation status

Implemented in this repository

This website implements lexical RID, RRN, and RSN checks in src/lib/identity, tested against the Document 09 vectors. They are not a conformance suite.

Parser vectors from Document 09

JSON

{
  "spec": "rsm-identity-v1",
  "cases": [
    { "input": "451.7K4M9Q2X8D5P0R6T", "valid": true, "prefix": "451", "suffix": "7K4M9Q2X8D5P0R6T" },
    { "input": "451.7K4M9Q2X8D5P0R6I", "valid": false, "reason": "invalid Crockford Base32 character" },
    { "input": "0451.7K4M9Q2X8D5P0R6T", "valid": false, "reason": "noncanonical prefix" },
    { "input": "451.7K4M9Q2X8D5P0R6T", "valid": true, "registryValidation": "depends on prefix registration" }
  ]
}

Lexical fixtures stay separate from registry-aware issuance tests; generation is tested with a controlled random source.

Source: Doc 09 §9.1

Records

Identity record and representation

The identity record is the registry’s envelope for one RID: names and their history, issuing authority, lifecycle, and the binding to the authoritative space. The representation is what that space supplies: content, relationships, and revision state. Keep them distinct in your data model.

application/json — shape of Document 08 §7.2 (illustrative)

{
  "rid": "451.7K4M9Q2X8D5P0R6T",
  "rrn": "rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model",
  "kind": "document",
  "name": "Outcome Formation Model",
  "space": {
    "name": "Wellzai",
    "rsn": "rrn:451:451labs:us-ca:wellzai:space/root"
  },
  "governance": {
    "issuanceJurisdiction": "us-ca",
    "visibility": "public"
  },
  "lifecycle": {
    "identity": "active",
    "revision": 7
  },
  "representations": [
    {
      "mediaType": "text/html",
      "role": "landing-page"
    },
    {
      "mediaType": "application/ld+json",
      "role": "semantic-description"
    },
    {
      "mediaType": "application/json",
      "role": "identity-record"
    }
  ]
}

In the specification

Every representation exposes its canonical RID; the final structure will be versioned JSON Schema.

Doc 08 §7.1 · Doc 08 §7.2

Implementation status

The JSON-LD context IRIs in Document 09 are placeholders — explicitly not valid production vocabulary.

Doc 09 §7.3

Resolver API

The proposed HTTP interface

Proposed reference architecture Routes from Doc 09 §7.1. Mutation routes require authentication and least-privilege authorization; the public identifier path is a resolution interface, not a permission grant.

Method	Path	Purpose
GET	/{rid}	Content-negotiated identity view
GET	/v1/identities/{rid}	Policy-permitted metadata
GET	/v1/names/resolve?rrn=…	RRN to RID
POST	/v1/identities	Authorized, idempotent registration
POST	/v1/spaces	RSN and space registration
GET	/v1/spaces/{rid}	Space capabilities and authority
POST	/v1/identities/{rid}/transfer	Governed binding transition
GET	/v1/identities/{rid}/events	Authorized identity events
GET	/readyz	Registry and resolver health

Resolution request — Document 09 §7.3

GET /451.7K4M9Q2X8D5P0R6T HTTP/1.1
Host: rmsid.org
Accept: application/ld+json

Responses that vary by Accept must carry suitable Vary and cache controls; public caches must never store principal-specific restricted responses (Doc 09 §7.6).

Implementation status

rmsid.org is proposed, not live. A conforming resolver may run under any approved hostname; the RID-to-path mapping stays the same.

Doc 08 §2.5

Conformance

What a conforming implementation must do

Core — parse, validate, generate, serialize, and compare RIDs deterministically; parse RRNs and RSNs; preserve RRN-to-RID mappings; reject malformed identifiers. Doc 08 §14.1
Issuer — enforce prefix delegation, suffix uniqueness, atomic registration, permanent non-reuse, and auditable provenance; never claim authority under an unregistered prefix. Doc 08 §14.2
Resolver — resolve through verified registry authority, return typed outcomes, serve human and machine responses, and enforce disclosure policy. Doc 08 §14.3
Federation — preserve canonical RIDs across spaces, avoid ownership assumptions, and distinguish source-authoritative records from cached ones. Doc 08 §14.4

The eighteen v1.0 acceptance tests

One hundred thousand locally generated RIDs are syntactically valid and unique.
Concurrent issuance transactions never commit duplicate RIDs.
Unsupported prefixes fail authoritative registration.
RID serialization and parsing are deterministic across supported languages.
RRN and RSN parsing follows the published grammar.
Registered RRNs map unambiguously to canonical RIDs.
A resource survives renaming and republishing without RID changes.
Relocating a Locus instance does not change resource identity.
Authorized RRN transfer preserves its original RID association.
Retired identifiers cannot be reissued.
HTML and JSON-LD resolve to the same underlying referent.
Contextual representation does not change canonical identity.
A public resolver does not disclose restricted resource information.
A cross-space relationship resolves by RID.
Jurisdiction and bioregional metadata can change independently of RID.
Resolver authority spoofing is rejected.
Historical identity records remain interpretable after registry changes.
External identifiers remain distinguishable from RSM-issued identities.

Plus negative tests for invalid encodings, ambiguous aliases, revoked authorities, concurrent transfers, stale caches, and malicious endpoint responses. Document 09 stages delivery through five release gates, from identity primitives to operational hardening.

Source: Doc 08 §14.5 · Doc 09 §11.1

Preparing your systems

Design choices that will make integration straightforward

Each follows from the specification and is safe to adopt before any registry exists.

Reserve a field for the canonical RID
Store the RID beside your own identifiers rather than overloading one key with both meanings. Compare RIDs by exact string equality.
Never parse meaning out of an RID
The prefix is a namespace, not a hostname or an owner. Type, space, place, and jurisdiction come from resolution, not from the identifier.
Keep names, locations, and revisions separate
An RRN is a name, a URL is a location, a revision is a state, a digest identifies bytes. None of them is the RID.
Reference across systems by RID, with provenance
Relationships should name both ends by RID and keep the originating space, predicate, and asserting authority. Never merge records on similarity alone.

Specification library

The nine RSM specifications

01–07 are published at rsmone.com. 08 and 09, the RSM ID documents, are reproduced on this site.

No.	Specification	Governing question	Version	Status
01	Regenerative Systems Model — A Living Outcome-Forming Ecology	Why does RSM exist?	2.0	Normative
02	RSM Subject Model	What can exist and participate?	1.0	Draft
03	RSM Semantic Model & Taxonomy Architecture	How is meaning represented and extended?	4.0	Draft
04	RSM Canonical Model & Protocol Specification	What is authoritative state, and how does it interact?	2.0	Draft
05	RSM Runtime & Federation Architecture	How does RSM operate across independent systems?	2.0	Draft
06	RSM Reference Implementation & Conformance	How do we know an implementation is really RSM?	2.0	Draft
07	RSM Technology & Infrastructure Architecture	Through what technology will the specifications be realized?	1.0	Implementation
08	RSM ID — Identity, Naming & Resolution Specification	How is every resource identified, named, and resolved?	1.0	Proposed normative
09	RSM ID — Core Identity Reference Implementation	How will the identity system be built and verified?	1.0	Proposed implementation

Build on the RSM ID contract

Eight logical modules

identity

naming

registry

resolution

governance

provenance

interop

conformance

Grammar and test vectors

Identity record and representation

The proposed HTTP interface

What a conforming implementation must do

Design choices that will make integration straightforward

Reserve a field for the canonical RID

Never parse meaning out of an RID

Keep names, locations, and revisions separate

Reference across systems by RID, with provenance

The nine RSM specifications