# RSM ID — Core Identity Reference Implementation v1.0

**Document ID:** RSM-CORE-IDENTITY-REF-001  
**System designation:** RSM ID  
**Version:** 1.0  
**Status:** Proposed Implementation Specification  
**Date:** October 9, 2026  
**Steward:** RSM Core  
**Initial federation:** RSM, Wellzai, Musewoods  
**Implementation language:** Go  
**Initial persistence:** SQLite, behind replaceable storage interfaces  
**Normative dependency:** RSM ID — Identity, Naming & Resolution Specification v1.0

## Abstract

This reference implementation defines the first executable foundation for RSM ID, the universal RSM resource identity system. It provides permanent RSM Identifiers (RIDs), structured RSM Resource Names (RRNs), RSM Space Names (RSNs), controlled identifier issuance, an auditable registry, HTTP resolution, and federation with independently managed Semantic Spaces.

RSM ID is the encompassing infrastructure, not another identifier type. The design deliberately separates identity from content and deployment. **RID identifies; RRN names; RSN identifies a Semantic Space; the registry preserves identity and authority; the resolver connects identifiers to permitted representations; Locus serves authoritative knowledge; Atlas explores relationships.** The initial demonstration consists of three independent Locus nodes—RSM, Wellzai, and Musewoods—sharing one identity contract without sharing a content database.

All diagrams in this document use portable fenced Mermaid syntax. Code listings describe reference interfaces and implementation patterns; they are not claims that these components have already been built.

## 1. Architecture and scope

RSM ID SHALL be implemented as one logical identity system whose interoperable constructs are RID, RRN, RSN, authoritative Identity Records, registry authority, and trusted resolution. A deployment MAY split these responsibilities across modules and services, but MUST NOT create separate competing RID/RRN/RSN authorities or independently invent a second canonical identity for the same registered referent. The normative specification, not this reference implementation, controls the identity contract.


### 1.1. Reference architecture

```mermaid
flowchart TB
    CLIENT["Applications, agents, CLI, Atlas"]
    API["RSM Identity API / Resolver"]
    CORE["RSM Core Identity Library"]
    REG["Registry and Issuance"]
    TRUST["Authority and Trust"]
    POLICY["Policy and Governance"]
    DB[("Durable Registry")]
    FED["Federation Adapter"]

    subgraph RSMCORE["RSM Core Boundary"]
        API --> CORE
        CORE --> REG
        CORE --> TRUST
        CORE --> POLICY
        REG --> DB
        API --> FED
    end

    CLIENT --> API
    FED --> L1["RSM Locus"]
    FED --> L2["Wellzai Locus"]
    FED --> L3["Musewoods Locus"]
```

The implementation has five independently testable responsibilities:

1. **Identity:** Generate, validate, parse, format, and compare permanent RIDs.
2. **Naming:** Validate RRNs and RSNs, enforce registration, and associate names with RIDs.
3. **Registry:** Preserve identities, prefixes, authority delegations, binding history, lifecycle, and provenance.
4. **Resolution:** Convert identifiers into verified, policy-permitted metadata and representations.
5. **Federation:** Discover authoritative Semantic Spaces and delegate retrieval without centralizing their knowledge.

The implementation SHOULD support three operating modes: an embedded pure Go library, a standalone registry/resolver service, and a federated gateway connecting independent Locus nodes.

### 1.2. Architectural ownership

RSM Core SHALL own the identity types, naming grammar, validation, registry contracts, resolver interfaces, and conformance fixtures. A reference runtime MAY use SQLite and HTTP, but neither SQLite nor a particular Go web framework becomes part of the identity standard.

Locus SHALL own authoritative resource content, revisions, and semantic relationships for the spaces it serves. Atlas SHALL consume federated metadata and relationships for exploration. Wellzai, Musewoods, and other applications SHALL use RSM identity rather than creating incompatible cross-system identities. Ana MAY form and reconcile knowledge, but SHALL not redefine RID issuance or resource equivalence.

### 1.3. Explicit non-goals

The initial release SHALL NOT build a general CMS, graph database, distributed consensus platform, blockchain, embedding engine, global search service, or custom enterprise identity provider. It SHALL NOT require Docker or an external database for pure identity package tests.

### 1.4. Foundational invariants

| Invariant | Requirement |
|---|---|
| One canonical identity | Each *registered resource referent* has one canonical RID in its authoritative record. Independent records for the same real-world entity require explicit reconciliation. |
| Permanent RID | An issued RID is never reassigned. |
| Delegated issuance | Only registered, authorized issuers may issue within a prefix. |
| Registered RRN | A registered RRN maps to exactly one RID and is never reassigned to an unrelated resource. |
| Space identity | Each Semantic Space has its own RID and RSN. |
| Content separation | Resource bodies are not required in the identity registry. |
| Location independence | Hosting relocation does not change RID. |
| Governance separation | An RRN's issuance jurisdiction is not a complete authorization or residency policy. |
| Verified resolution | Authoritative responses must be associated with verified registry bindings. |
| Auditability | Issuance, transfers, retirement, and authority changes are recorded. |

## 2. Canonical identity and naming types

### 2.1. RID

RID is the permanent, compact identifier in DOI-style prefix/suffix form:

```text
<prefix>.<suffix>
451.7K4M9Q2X8D5P0R6T
```

The v1.0 default suffix is **16 uppercase Crockford Base32 symbols**, encoding 80 bits of cryptographic randomness. The alphabet is:

```text
0123456789ABCDEFGHJKMNPQRSTVWXYZ
```

The prefix is a registered decimal namespace, not a hostname. Lexical RID parsing and registry-aware RID validation are different operations: syntactically valid RIDs may have unregistered prefixes and must not be represented as authoritative until issuance succeeds.

### 2.2. RRN

RRN is the registered structured naming descriptor:

```text
rrn:<realm>:<authority>:<jurisdiction>:<space>:<kind>/<resource-id>
rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model
```

The grammar SHALL enforce normalized lowercase structural segments, nonempty parts, bounded lengths, and disallow ambiguous percent encodings, wildcards, and path traversal. Registered RRNs resolve to an RID. A resource may acquire an additional RRN after a governed namespace transfer without changing RID; historical RRNs remain reserved.

### 2.3. RSN

RSN is an RRN whose kind is `space`:

```text
rrn:451:451labs:us-ca:rsm:space/root
rrn:451:451labs:us-ca:wellzai:space/root
rrn:451:451labs:us-ca:musewoods:space/root
```

These are proposed namespace registrations, not claims of issued identities. Each space SHALL also have its own permanent RID. The identity registry, not a hostname or application build, determines the space's current authoritative runtime.

### 2.4. Identity and representation

A RID identifies a resource, while its RRN represents structured issuance context. A resolver supplies one or more views of the same referent. An HTML landing page for a watershed, for example, is a description of the watershed, not the watershed itself.

```mermaid
flowchart TB
    RID["RID: permanent canonical identity"]
    NAME["RRN: registered structured name"]
    REG["Identity Registry: prefix, authority, mappings"]
    SPACE["RSN: authoritative Semantic Space"]
    META["Semantic context: kind, subjects, relationships"]
    GOV["Governance: jurisdiction, bioregion, stewardship"]
    REP["Representations: HTML, JSON-LD, content"]
    RID --> REG
    NAME --> REG
    REG --> SPACE
    SPACE --> META
    SPACE --> GOV
    SPACE --> REP
```

## 3. Repository and Go package boundaries

### 3.1. Recommended logical layout

Adapt these paths to the existing RSM repository; do not reorganize working modules merely to match this example.

```text
rsm/
  core/
    identity/
      rid/
      rrn/
      rsn/
      model/
      validation/
      issuance/
      registry/
      resolution/
      authority/
      governance/
      provenance/
      interop/
  services/
    identityd/
  clients/
    go/
    typescript/
  schemas/
    identity/v1/
      rid.schema.json
      rrn.schema.json
      identity-record.schema.json
      space-record.schema.json
      resolution.schema.json
      registry-events.schema.json
      openapi.yaml
  migrations/identity/
  conformance/v1/
    valid-rids.json
    invalid-rids.json
    valid-rrns.json
    invalid-rrns.json
    registry-cases.json
    resolution-cases.json
    policy-cases.json
  examples/
    identity-cli/
    local-registry/
    three-space-federation/
  docs/identity/
```

### 3.2. Layering

The `rid`, `rrn`, and `rsn` packages SHALL be deterministic and free of network or SQL dependencies. RID generation uses cryptographic randomness; issuance requires a transactional registry and delegated authority. Resolution requires registry lookup, trust verification, policy evaluation, and representation access.

The core types MUST be importable without starting an HTTP service. Storage and network adapters must not leak into canonical formatting or identifier comparisons.

### 3.3. Dependencies

Prefer the Go standard library for parsing, HTTP, cryptography, and testing. Select a maintained SQLite driver based on supported Go versions, licensing, deployment portability, and transactional behavior. Keep authentication, JOSE, JSON-LD, and policy libraries behind replaceable interfaces.

## 4. Registry logical data model

### 4.1. Entities

| Entity | Purpose |
|---|---|
| `prefixes` | RID prefix allocations and lifecycle |
| `authorities` | Registered identity issuers/controllers |
| `delegations` | Explicit, time-bounded issuance grants |
| `identities` | Immutable canonical RID registrations |
| `spaces` | Semantic Space RIDs and RSNs |
| `resource_names` | Permanent RRN-to-RID mappings |
| `resource_bindings` | Current and historical authoritative spaces/endpoints |
| `identity_events` | Append-only issuance and governance events |
| `idempotency_records` | Retry-safe issuance records |
| `external_identifiers` | DOI, ORCID, and other independently issued IDs |

### 4.1.1. RSM Identity Record mapping

The `identities` table is the local persistence projection of the normative **RSM Identity Record**. The complete logical record spans `identities`, `resource_names`, `resource_bindings`, `identity_events`, `external_identifiers`, `prefixes`, `authorities`, and `delegations`; it is not a new independent table or resource identifier. APIs SHOULD assemble a consistent identity-record view from these records while retaining authoritative provenance and effective-dated history. The durable primary key is RID, including when RRNs, space bindings, or endpoints change.

The reference schema below is intentionally incomplete. In particular, production conformance must explicitly model authoritative space RID/RSN, issuer provenance, binding verification, delegation and transfer history, and protected disclosure, as required by the normative Identity Record. Do not silently treat a database row or example YAML envelope as the final serialized schema.

### 4.2. Relationships

```mermaid
erDiagram
    PREFIX ||--o{ IDENTITY : issues
    AUTHORITY ||--o{ DELEGATION : grants
    PREFIX ||--o{ DELEGATION : authorizes
    AUTHORITY ||--o{ SPACE : controls
    IDENTITY ||--o{ RESOURCE_NAME : named_by
    IDENTITY ||--o{ RESOURCE_BINDING : served_by
    IDENTITY ||--o{ IDENTITY_EVENT : records
    IDENTITY ||--o{ EXTERNAL_IDENTIFIER : references
    SPACE ||--o{ RESOURCE_BINDING : hosts
    IDENTITY ||--o| SPACE : identifies

    PREFIX {
        text value PK
        text status
        text controller_id
    }
    AUTHORITY {
        text id PK
        text name
        text status
    }
    DELEGATION {
        text id PK
        text prefix
        text authority_id
        text scope
    }
    IDENTITY {
        text rid PK
        text prefix FK
        text kind
        text status
        text created_at
    }
    SPACE {
        text rid PK
        text rsn UK
        text authority_id
    }
    RESOURCE_NAME {
        text rrn PK
        text rid FK
        text status
    }
    RESOURCE_BINDING {
        text id PK
        text rid FK
        text space_rid FK
        text endpoint
    }
    IDENTITY_EVENT {
        text event_id PK
        text rid FK
        text action
    }
    EXTERNAL_IDENTIFIER {
        text id PK
        text rid FK
        text scheme
        text value
    }
```

### 4.3. Representative SQLite migration

```sql
PRAGMA foreign_keys = ON;

CREATE TABLE prefixes (
    prefix TEXT PRIMARY KEY,
    controller_authority TEXT NOT NULL,
    status TEXT NOT NULL
      CHECK (status IN ('active','suspended','retired','reserved')),
    created_at TEXT NOT NULL
);

CREATE TABLE authorities (
    authority_id TEXT PRIMARY KEY,
    display_name TEXT NOT NULL,
    status TEXT NOT NULL
      CHECK (status IN ('active','suspended','retired'))
);

CREATE TABLE identities (
    rid TEXT PRIMARY KEY,
    prefix TEXT NOT NULL REFERENCES prefixes(prefix),
    kind TEXT NOT NULL,
    status TEXT NOT NULL
      CHECK (status IN
        ('active','deprecated','superseded','retired','reserved')),
    referent_descriptor TEXT NOT NULL,
    created_at TEXT NOT NULL,
    updated_at TEXT NOT NULL
);

CREATE TABLE spaces (
    rid TEXT PRIMARY KEY REFERENCES identities(rid),
    rsn TEXT NOT NULL UNIQUE,
    authority_id TEXT NOT NULL REFERENCES authorities(authority_id),
    status TEXT NOT NULL
      CHECK (status IN ('active','suspended','retired'))
);

CREATE TABLE resource_names (
    rrn TEXT PRIMARY KEY,
    rid TEXT NOT NULL REFERENCES identities(rid),
    status TEXT NOT NULL
      CHECK (status IN ('active','superseded','retired')),
    registered_at TEXT NOT NULL,
    superseded_at TEXT
);

CREATE TABLE resource_bindings (
    binding_id TEXT PRIMARY KEY,
    rid TEXT NOT NULL REFERENCES identities(rid),
    space_rid TEXT NOT NULL REFERENCES spaces(rid),
    endpoint TEXT NOT NULL,
    valid_from TEXT NOT NULL,
    valid_to TEXT
);

CREATE UNIQUE INDEX one_active_binding_per_resource
ON resource_bindings(rid)
WHERE valid_to IS NULL;

CREATE TABLE identity_events (
    event_id TEXT PRIMARY KEY,
    rid TEXT REFERENCES identities(rid),
    actor_id TEXT NOT NULL,
    action TEXT NOT NULL,
    details_json TEXT NOT NULL,
    occurred_at TEXT NOT NULL
);

CREATE TABLE idempotency_records (
    issuer_id TEXT NOT NULL,
    key TEXT NOT NULL,
    request_hash TEXT NOT NULL,
    rid TEXT NOT NULL REFERENCES identities(rid),
    created_at TEXT NOT NULL,
    PRIMARY KEY (issuer_id, key)
);

CREATE TABLE external_identifiers (
    id TEXT PRIMARY KEY,
    rid TEXT NOT NULL REFERENCES identities(rid),
    scheme TEXT NOT NULL,
    external_value TEXT NOT NULL,
    relation TEXT NOT NULL
);
```

This is a **representative** migration rather than a production-complete schema. Production implementation SHALL add delegated permissions, verification keys, binding transfer state, registry revision counters, immutability enforcement, and migration tests. SQL constraints do not replace RID/RRN parsing. For SQLite, enforce foreign keys on **every connection**, not only during schema creation.

### 4.4. Transactions and history

Identity issuance SHALL atomically commit the RID registration, initial RRN, authoritative binding, and audit event. A resource transfer SHALL preserve historical bindings with effective periods. Remote Locus provisioning cannot be part of the same SQLite ACID transaction; use an explicit provisioning state and an idempotent coordination workflow.

## 5. Go reference interfaces

The following presents interface shapes; production code will split packages and add constructors, typed errors, authorization context, and transaction interfaces.

```go
package identity

import (
    "context"
    "time"
)

type RID struct { value string }
func (r RID) String() string { return r.value }

type RRN struct { value string }
func (r RRN) String() string { return r.value }

type IssueRequest struct {
    Prefix         string
    Kind           string
    SpaceRID       RID
    RequestedRRN   RRN
    Referent       string
    IdempotencyKey string
}

type IdentityRecord struct {
    RID       RID
    Kind      string
    State     string
    CreatedAt time.Time
}

type Issuer interface {
    Issue(ctx context.Context, principal string,
        request IssueRequest) (IdentityRecord, error)
}

type Registry interface {
    GetIdentity(ctx context.Context, rid RID) (IdentityRecord, error)
    ResolveName(ctx context.Context, name RRN) (RID, error)
}

type RepresentationRequest struct {
    RID       RID
    Principal string
    MediaType string
    Revision  string
}

type Representation struct {
    RID         RID
    MediaType   string
    Content     []byte
    ETag        string
    RetrievedAt time.Time
}

type Resolver interface {
    Resolve(ctx context.Context,
        request RepresentationRequest) (Representation, error)
}

type AuthorityVerifier interface {
    CanIssue(ctx context.Context, principal string,
        prefix string, space RID, kind string) (bool, error)
}
```

The RID and RRN constructors SHALL validate before creating value objects. Real packages SHOULD use non-exported fields and validated factory functions. Typed errors SHOULD include invalid syntax, unregistered prefix, forbidden issuance, conflict, unavailable authority, and retired identity.

## 6. RID issuance

### 6.1. Algorithm

1. Authenticate the requesting principal and authorize prefix/space/kind issuance.
2. Validate the resource's kind, requested RRN, referent descriptor, and idempotency input.
3. Look up an existing idempotency record, scoped to authenticated issuer and request fingerprint.
4. Generate 80 cryptographically random bits and encode them into a 16-character suffix.
5. Construct the candidate RID and validate its canonical syntax.
6. Begin a transaction and insert RID, initial RRN mapping, binding, issuance event, and idempotency record.
7. Commit atomically; if the RID unique constraint collides, retry with a new suffix.
8. Return the persisted RID and authoritative registration metadata.

Authorization failures, malformed input, and network/storage failures MUST NOT be misclassified as RID collisions. SQLite writes should not remain open across remote network requests.

### 6.2. Candidate generator

```go
package rid

import (
    "crypto/rand"
    "fmt"
    "strconv"
    "strings"
)

const alphabet = "0123456789ABCDEFGHJKMNPQRSTVWXYZ"

func Generate(prefix string) (string, error) {
    if err := validatePrefix(prefix); err != nil {
        return "", err
    }

    var raw [10]byte // 80 random bits
    if _, err := rand.Read(raw[:]); err != nil {
        return "", err
    }

    var suffix [16]byte
    for i := 0; i < 16; i++ {
        bit := i * 5
        byteIndex := bit / 8
        shift := uint(bit % 8)
        value := uint16(raw[byteIndex]) << 8
        if byteIndex+1 < len(raw) {
            value |= uint16(raw[byteIndex+1])
        }
        index := byte((value >> (11 - shift)) & 31)
        suffix[i] = alphabet[index]
    }

    return prefix + "." + string(suffix[:]), nil
}

func validatePrefix(prefix string) error {
    if len(prefix) < 1 || len(prefix) > 16 {
        return fmt.Errorf("invalid prefix length")
    }
    if strings.HasPrefix(prefix, "0") && prefix != "0" {
        return fmt.Errorf("noncanonical leading zero")
    }
    for _, c := range prefix {
        if c < '0' || c > '9' {
            return fmt.Errorf("nondecimal prefix")
        }
    }
    if _, err := strconv.ParseUint(prefix, 10, 64); err != nil {
        return err
    }
    return nil
}
```

This generates a **candidate**, not a registered identity. Generation alone does not guarantee uniqueness. At one billion independent 80-bit suffix generations under a single prefix, the approximate birthday collision probability is about `4.1 × 10^-7`, so atomic uniqueness checks and bounded collision retries are mandatory.

### 6.3. Idempotency

The issuer SHALL scope idempotency keys to the authenticated issuer and a stable hash of the normalized request. Repeating an identical request returns the originally committed RID. Repeating the same key with different request content returns a conflict.

### 6.4. Non-reuse

An issued RID reservation must survive resource retirement, withdrawal, transfer, and legal erasure workflows to the extent permitted by law. Never expose a deleted RID for reassignment to a new resource.

## 7. Resolver API and representations

### 7.1. HTTP routes

| Operation | Endpoint | Purpose |
|---|---|---|
| Resolve RID | `GET /{rid}` | Content-negotiated identity view |
| Identity metadata | `GET /v1/identities/{rid}` | Policy-permitted metadata |
| RRN lookup | `GET /v1/names/resolve?rrn=...` | RRN to RID |
| Issue RID | `POST /v1/identities` | Authorized, idempotent registration |
| Register space | `POST /v1/spaces` | RSN and space registration |
| Space metadata | `GET /v1/spaces/{rid}` | Space capabilities and authority |
| Transfer binding | `POST /v1/identities/{rid}/transfer` | Governed binding transition |
| Audit history | `GET /v1/identities/{rid}/events` | Authorized identity events |
| Readiness | `GET /readyz` | Registry and resolver health |

Registry-mutation routes require authentication and least-privilege authorization. The public identifier path is a resolution interface, **not** a permission grant.

### 7.2. Issuance request

```http
POST /v1/identities HTTP/1.1
Host: identity.example.test
Authorization: Bearer <access-token>
Content-Type: application/json
Idempotency-Key: formation-model-001

{
  "prefix": "451",
  "kind": "document",
  "spaceRid": "<registered-wellzai-space-rid>",
  "rrn": "rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model",
  "referent": "Wellzai Outcome Formation Model"
}
```

On successful first issuance, return `201 Created` with canonical RID, registration status, and a web identifier. For identical retried requests, return the original issuance result without minting a second RID.

### 7.3. Resolution request

```http
GET /451.7K4M9Q2X8D5P0R6T HTTP/1.1
Host: rsmid.org
Accept: application/ld+json
```

The `rsmid.org` hostname is **proposed**, not a claimed live or verified authoritative resolver. Its use requires domain control, stewardship, and trust configuration. A conforming resolver MAY operate under another approved hostname.

The JSON-LD shape might be:

```json
{
  "@context": {
    "rid": "https://example.org/rsm/context/rid",
    "rrn": "https://example.org/rsm/context/rrn",
    "kind": "https://example.org/rsm/context/kind",
    "space": {
      "@id": "https://example.org/rsm/context/space",
      "@type": "@id"
    }
  },
  "@id": "https://rsmid.org/451.7K4M9Q2X8D5P0R6T",
  "rid": "451.7K4M9Q2X8D5P0R6T",
  "rrn": "rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model",
  "kind": "document",
  "title": "Outcome Formation Model",
  "space": "https://rsmid.org/<wellzai-space-rid>",
  "identityStatus": "active"
}
```

The example context IRIs and placeholder space identifier are **not valid production vocabulary mappings**. Assign stable RSM vocabulary IRIs, expand and validate the JSON-LD, and replace placeholders before promoting a fixture into the conformance suite.

### 7.4. Resolver sequence

```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->>P: Verify prefix and trust binding
    P-->>R: Registered authority
    R->>I: Locate RID identity record
    I-->>R: Space and active binding
    R->>L: Authorized representation request
    L-->>R: Permitted metadata / representation
    R-->>C: HTML, JSON-LD, or typed result
```

Resolvers SHOULD support `text/html`, `application/json`, and `application/ld+json`, with suitable HTTP `Vary` and cache controls. A representation may vary according to `Accept`, language preference, and authenticated authorization **without changing the identified referent**.

### 7.5. Resolution statuses and privacy

Internal statuses SHOULD distinguish `resolved`, `not_found`, `forbidden`, `retired`, `superseded`, `unavailable`, `untrusted`, and `invalid`. Externally, restricted and nonexistent resources MAY need indistinguishable responses to avoid resource-existence leaks. HTTP response behavior and diagnostics must implement that policy deliberately.

The default persistent web identifier SHOULD yield a durable identity landing page rather than always forwarding to a transient application URL. Optional redirects to authoritative representations may be supported. Content hashes and revision identifiers remain separate from RID.

### 7.6. Security and caches

Verify registered prefixes, delegated issuers, signed or otherwise authenticated endpoint bindings, token audience and expiry, and policy-permitted representation access. Federation HTTP clients must defend against SSRF, unsafe redirects, private-network destinations, and credential forwarding. Public caches must never store principal-specific restricted responses; binding revocation, authority transfers, and policy changes require explicit cache invalidation or bounded freshness.

## 8. Semantic Space federation

### 8.1. Initial topology

```mermaid
flowchart TB
    USER["Browser / CLI / Atlas Demo"]

    subgraph CONTROL["Identity and Resolution"]
        RES["RSM Resolver: localhost:8080"]
        REG[("Identity Registry: SQLite")]
        RES <--> REG
    end

    subgraph SPACES["Independent Semantic Spaces"]
        R["RSM Locus: localhost:8101"]
        W["Wellzai Locus: localhost:8102"]
        M["Musewoods Locus: localhost:8103"]
    end

    USER --> RES
    RES --> R
    RES --> W
    RES --> M

    R --> RD[("rsm.db")]
    W --> WD[("wellzai.db")]
    M --> MD[("musewoods.db")]
```

Ports are proposed local-development defaults, not existing deployed services. Each node maintains independent content and revisions; the registry maintains permanent identities, namespace ownership, and endpoint bindings.

### 8.2. Cross-space references

A Wellzai formation resource can reference an RSM concept by RID and a Musewoods fieldnote by RID. Atlas resolves those references through registered authorities and retrieves representations from the spaces owning them. Cached projections may carry identity, revision, retrieval time, and provenance, but MUST NOT silently become independent authoritative copies.

### 8.3. Resource transfer

```mermaid
sequenceDiagram
    participant A as Authorized Administrator
    participant R as Identity Registry
    participant O as Original Wellzai Locus
    participant N as New Locus
    participant P as Public Resolver

    A->>R: Request transfer by RID
    R->>R: Verify delegation and policy
    R->>N: Prepare target resource
    N-->>R: Confirm readiness
    R->>R: Commit binding and audit event
    R-->>A: Transfer committed
    P->>R: Resolve same RID
    R-->>P: Updated authoritative binding
    P->>N: Fetch representation
    N-->>P: Same RID, new location
    Note over O,N: Old binding preserved in history
```

This is a coordinated transfer, **not a distributed ACID transaction**. Define handling for loss of the target after cutover, rollback eligibility, stale resolver caches, and split-brain prevention. The canonical RID persists throughout.

### 8.4. Contextual governance

The registered RRN records issuance jurisdiction, not necessarily the resource's current legal location, ecological extent, or hosting region. The semantic governance model MAY record multiple bioregions, watersheds, legal jurisdictions, data residency constraints, and stewardship authorities. A resolver SHALL enforce disclosure policy based on current trusted attributes, not on RID prefix or RRN jurisdiction alone.

## 9. Portable conformance fixtures

### 9.1. Parser vectors

```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 must be separate from registry-aware issuance tests. Test cryptographic generation with a controlled random source and fixed expected outputs, and fuzz the parser with invalid encodings, lengths, unsupported characters, and malformed RRNs.

### 9.2. Acceptance scenarios

| Test | Action | Expected result |
|---|---|---|
| 1. Issue | Register RSM Formation concept | New persistent RID |
| 2. Resolve | Open RID URL | Permitted human-readable landing page |
| 3. Negotiate | Request JSON-LD | Same identity, semantic representation |
| 4. Link | Reference Formation from Wellzai | Cross-space RID reference |
| 5. Explore | Traverse to Musewoods via Atlas | Verified source resolution |
| 6. Revise | Update Wellzai content | Same RID, new content revision |
| 7. Relocate | Move Musewoods Locus endpoint | Same RID, new active binding |
| 8. Restrict | Change disclosure policy | Unauthorized access denied without leakage |
| 9. Retire | Retire resource | Reserved RID and suitable tombstone |
| 10. Restore | Restore registry backup | Issued ID reservations and history preserved |

Tests must include issuer authorization, conflicting idempotency keys, collision retries, non-reuse, transfer races, registry corruption handling, revoked endpoint keys, untrusted redirects, and appropriate cache behavior.

## 10. Operational development workflow

### 10.1. Local commands

A reference CLI SHOULD support:

```text
rsm identity init
rsm identity prefix add
rsm identity issue
rsm identity inspect
rsm identity resolve
rsm identity register-name
rsm identity register-space
rsm identity retire
rsm identity doctor
```

Suggested developer targets:

```bash
make identity-test
make identity-lint
make identity-fuzz
make identity-conformance
make federation-up
make federation-seed
make federation-test
make federation-down
```

Sample resolution:

```bash
rsm identity resolve 451.7K4M9Q2X8D5P0R6T
```

Illustrative authorized output:

```text
RID:          451.7K4M9Q2X8D5P0R6T
Kind:         document
Name:         Outcome Formation Model
Authority:    451 Labs
Space:        Wellzai
Identity:     active
Revision:     7
```

### 10.2. Observability and recovery

Expose readiness checks, issuance and collision counts, denied requests, registry failures, remote resolution errors, and structured tracing with appropriate privacy controls. Never log credentials or restricted data indiscriminately. Support transactionally consistent SQLite backups and restoration tests; verify that restoration preserves historical IDs, RRN reservations, active bindings, delegation history, and tombstones.

## 11. Implementation phases and release gates

### 11.1. Gate 1 — Identity primitives

Deliver pure Go RID/RRN/RSN packages, canonical parser/formatter, random suffix generation, shared conformance fixtures, and fuzz tests. The release gate requires deterministic tests and no network/database dependency for pure identity operations.

### 11.2. Gate 2 — Registry integrity

Implement SQLite migrations, prefix/authority registration, delegations, transactional issuance, RRN mappings, space records, idempotency, and append-only events. Verify concurrent uniqueness, rollback, collision retries, and permanent non-reuse.

### 11.3. Gate 3 — Persistent resolution

Deliver content-negotiated HTML/JSON/JSON-LD identity responses, trust validation, resource-binding lookup, lifecycle responses, and policy-aware disclosure. Validate the actual RSM JSON-LD context rather than relying on placeholder vocabulary mappings.

### 11.4. Gate 4 — Federation interoperability

Run RSM, Wellzai, and Musewoods as distinct Locus nodes with separate persistence. Traverse cross-space RID relationships, verify authoritative endpoints, and prove identity persistence after content edits and endpoint relocation.

### 11.5. Gate 5 — Operational hardening

Complete authority spoofing tests, HTTP security controls, caching/revocation tests, backup and recovery drills, concurrency stress tests, CI, schemas, OpenAPI, and compatibility documentation. Production deployment additionally requires legitimate prefix governance, trust roots, and stewardship procedures.

## 12. Initial three-node demonstration

The initial lab SHOULD seed approximately 20–30 representative resources from each of RSM, Wellzai, and Musewoods. Use non-destructive imports into isolated demonstration storage; do not modify original application repositories during the prototype.

The end-to-end demonstration SHALL prove that:

1. Each node has its own RSN and RID, plus independently managed content.
2. The shared registry can issue, register, and resolve permanent resource RIDs.
3. Each resource's registered RRN resolves to its canonical RID.
4. Atlas can traverse an RSM → Wellzai → Musewoods chain using RID references.
5. A content revision appears without rebuilding the consuming application.
6. A Locus endpoint relocation preserves RID and historical naming associations.
7. Governance restrictions are respected in human and machine-readable resolution.
8. Retired resources cannot have their RIDs reassigned.

## 13. Implementation guardrails

Before coding, inspect the **existing RSM Core canonical object, identity, subject, schema, and registry facilities**. Implement the RSM ID contract defined in Document 08 rather than a parallel identity platform. Reuse or migrate the present implementation instead of creating a parallel identity model. Keep the canonical RID contract language-neutral and drive every Go, TypeScript, and Rust implementation from the same fixtures.

Do not conflate a registered resource name with canonical identity, a space with its Locus deployment, a DOI-like identity with an immutable content hash, or issuance jurisdiction with all present-day geographic policy. Never assume a global identity registry implies a global content database.

## 14. Conclusion

The reference implementation makes resource identity durable while permitting Semantic Spaces to remain independently owned and operated. RSM Core provides the canonical rules, the registry preserves issuance and authority, the resolver exposes contextual representations, and Locus nodes maintain authoritative knowledge. Atlas connects those spaces through semantic relationships anchored to permanent RIDs.

**Identity is permanent. Naming is governed. Resolution is federated. Knowledge remains independently owned.**

## References

DOI Foundation. (n.d.). *DOI handbook.* https://www.doi.org/doi-handbook/html/

Berners-Lee, T., Fielding, R., & Masinter, L. (2005). *Uniform resource identifier (URI): Generic syntax* (RFC 3986). Internet Engineering Task Force. https://doi.org/10.17487/RFC3986

Davis, K., Peabody, B., & Leach, P. (2024). *Universally unique identifiers (UUIDs)* (RFC 9562). Internet Engineering Task Force. https://doi.org/10.17487/RFC9562

Fielding, R., Nottingham, M., & Reschke, J. (2022). *HTTP semantics* (RFC 9110). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110

World Wide Web Consortium. (2020). *JSON-LD 1.1: A JSON-based serialization for linked data.* https://www.w3.org/TR/json-ld11/