Learning Center
Learn how RSM ID works
Structured explanations of persistent identity, naming, authority, resolution, and federation — organized into five pathways, from the first question to the clauses that govern the answer. Every item names the sections of Documents 08 and 09 it rests on.
Pathways
Five ways in
Each pathway is a short, ordered sequence. Start with the first if RSM ID is new to you.
- 7 steps
Pathway A: Understanding Identity
What is RSM ID, and why does identity need to persist?
Why systems lose track of the same thing, what a permanent identifier changes, how an RID differs from a name, and why identity is kept apart from description.
- 10 steps
Pathway B: Naming and Authority
Who may name and issue identities, and under which rules?
RRNs and RSNs, prefixes and their allocation, registered kinds, the authority to issue, and why delegated authority is never ownership.
- 8 steps
Pathway C: Resolution
What happens between an identifier and the information about it?
Identity Records, authority verification, lookup, disclosure policy, lifecycle, representation negotiation, and the typed outcomes that end resolution.
- 8 steps
Pathway D: Federation
How do independently governed spaces share identity without sharing a database?
Semantic Spaces, Locus, Atlas, cross-space references, provenance, and why similar descriptions never merge identities on their own.
- 6 steps
Pathway E: Real-World Applications
What does persistent identity look like for farms, facilities, watersheds, and outcomes?
One referent across many organizational systems, governance that changes while identity does not, and evidence that keeps its source.
Not to be confused with
The specifications. Learning materials are informative: they explain Documents 08 and 09 v1.1 and add no requirements. Where an explanation and a specification differ, the specification governs.
Reel · guided, at your own pace
The Journey of an RSM Identity
A guided sequence in eight frames — from a resource in the world, through registration, naming, resolution, and revision — showing what changes around an identity and what never does.
Journals
Deep architectural reading
Sustained architectural essays: a thesis, worked examples, diagrams, and the clauses that govern them.
From Identity to Federation
A concept in the RSM space, a research paper in Wellzai, and a fieldnote in Musewoods reference each other without sharing a database. This Journal follows that chain through citation, exploration, transfer, and restriction to show how persistent references, provenance, and authority let federation work.
The Anatomy of RSM ID
RSM ID is not one identifier but a system of seven cooperating parts. This Journal takes them apart one by one — RID, RRN, RSN, Identity Record, the four registries, issuance authority, and resolution under the v1.1 HTTP profile — and shows why each is kept separate from the others.
Why Persistent Identity Matters
Every system that touches a farm, a mill, or a watershed keeps its own record, and none of them can say with certainty that the others mean the same thing. This Journal explains why that is a structural problem, and how a permanent identifier separated from every description of the resource addresses it.
Seednotes
The concept library
Small, connected concepts: a definition, an example, a common misconception, and where to read more. Each opens with the same definition as the glossary.
- AtlasThe proposed explorer of federated Semantic Spaces.
- FederationIndependently operated Semantic Spaces connected by shared identity and resolution.
- Identity lifecycleThe registry status of an RID: active, deprecated, superseded, retired, or reserved.
- Identity RecordThe durable registry record of one RID’s registration, lifecycle, naming, provenance, and authoritative bindings.
- Identity RegistryPreserves identity, namespace allocation, authority, historical mappings, and lifecycle information.
- Issuance authorityA registered issuer permitted to issue identities within a delegated namespace.
- LocusThe proposed engine that serves authoritative resource knowledge for Semantic Spaces.
- PrefixThe registered issuance namespace at the start of an RID.
- ProvenanceThe recorded origin and history of an identity, a name, or an assertion: who did what, under which authority, and when.
- ResolverConnects identifiers to verified, policy-permitted identity information and available representations.
- RIDThe permanent canonical identifier of one resource referent.
- RRNA registered, structured name that maps to exactly one RID.
- RSM IDThe universal identity infrastructure of RSM, governed by RSM Core.
- RSNA specialized RRN, of kind “space”, that identifies a Semantic Space.
- Semantic SpaceAn independently governed logical knowledge environment, with its own RID and RSN.
Viewgraphs
Visual explanations
Visual explanations in 16:9 frames, with their sources on every frame.
Federation across Semantic Spaces
How RSM, Wellzai, and Musewoods are proposed to share identity without sharing storage: cross-space references by RID, Atlas traversal, and transfers that keep the RID.
Identity lifecycle
Reserved, active, deprecated, superseded, and retired as Document 08 v1.1 defines them, with the permitted transitions and why no state ever frees an RID for reuse.
One referent across many systems
How one real-world resource keeps one RID while a cooperative, a certifier, a buyer, and a watershed council each keep their own records, identifiers, and governance.
Registration and controlled issuance
Prefixes, delegated authority, the controlled issuance sequence, idempotent retries, and permanent non-reuse — the rules that make an RID trustworthy before anyone resolves it.
RID, RRN, and RSN
Three constructs that are easy to blur: the RID identifies, an RRN names, and an RSN names a Semantic Space that has an RID of its own.
The anatomy of an Identity Record
What an RSM Identity Record contains, keyed by RID: the required minimum, the recommended additions, and the things it deliberately does not hold.
The complete RSM ID architecture
How the RID, RRN, Identity Record, registries, resolver, Semantic Space, and Locus fit together — and which of them hold identity, and which hold knowledge.
The Journey of an RSM Identity
Follow one illustrative paper from registration to resolution and revision, and see which parts change and which never do. The source deck for the guided Reel.
The resolution sequence
The logical steps a conforming resolver follows, the eight typed outcomes, and how Document 08 v1.1 maps them to HTTP without leaking what policy keeps private.
Fieldnotes
Focused questions
Focused explorations of one architectural question and the tradeoff behind it.
Why a Semantic Space has both an RID and an RSN
Why each Semantic Space carries a registered name and a separate permanent identifier, and what goes wrong when either is mistaken for the other — or for the server.
Why an RID should not encode its meaning
Why an RID carries no type, place, owner, or host — and why the meaning-rich parts live in names and metadata that are allowed to change.
Why identity is not ownership
Why RSM ID keeps issuance authority, legal ownership, custody, and stewardship as separate relationships — and what would break if it did not.
Why resolution is not simply fetching a document
Why RSM ID resolution verifies authority, evaluates lifecycle and disclosure, and negotiates a representation instead of following a link to a file.
Why semantic equivalence is not identity equality
Why RSM ID never merges identities on similarity, sameAs claims, or shared source files — and what an authorized equivalence decision needs instead.
Reading the margins
What each label means
Margin notes and source panels say what kind of statement you are reading. Only the first two carry the specifications’ authority — and only the first is the standard itself.
- Document 08 v1.1 · normative
- Grounded directly in Document 08, the controlling standard. Cited by section.
- Document 09 v1.1 · reference implementation
- Guidance from Document 09, the proposed reference implementation. Subordinate to Document 08; its technology choices are not requirements.
- Interpretation
- Explanation or design rationale written for this Learning Center. It does not add requirements.
- Hypothetical example
- An illustrative scenario. Its identifiers are examples or fictional; none has been issued.
- Proposed, not operational
- Something the specifications propose — a host, a prefix, a federation, a service — that does not exist yet.