RSM ID — Identity, Naming & Resolution Specification

Specification ID: RSM-CORE-ID-001
System designation: RSM ID
Version: 1.0
Status: Proposed Normative Standard
Date: October 9, 2026
Standards Authority: RSM Core
Initial Steward: 451 Labs
Implementation Scope: RSM, Wellzai, Musewoods, Locus, Atlas, Ana, and future federated systems

Abstract#

The RSM ID — Identity, Naming & Resolution Specification establishes the universal resource identity system for the Regenerative System Model (RSM). It provides persistent identification, structured naming, federated authority, location-aware governance, and web-based resolution for resources represented across independently managed systems.

RSM ID is the integrated identity system, not a fourth identifier or an alternative notation. It encompasses persistent identification, structured naming, authoritative identity records, delegated issuance, registry stewardship, lifecycle governance, and policy-aware resolution. The specification defines three complementary identity constructs: the RSM Identifier (RID), the RSM Resource Name (RRN), and the RSM Space Name (RSN). RID is the permanent canonical identifier assigned to a resource. RRN provides a registered, structured name representing the resource's namespace and issuance context. RSN identifies a Semantic Space within the same naming system. The RSM Resolution Protocol connects these constructs to authoritative metadata, representations, policies, and relationships.

Together, these mechanisms enable knowledge, people, organizations, concepts, instruments, places, ecological systems, formations, outcomes, and other RSM resources to participate in a common semantic universe. The architecture does not require all resources to share one database, application, infrastructure provider, or organizational owner.

The specification adopts lessons from persistent identifier systems, including DOI, while extending those ideas to sovereign Semantic Spaces, federated governance, semantic relationships, and place-based regenerative systems.

1. Introduction#

1.1. Background and motivation#

RSM has developed into a common semantic foundation spanning regenerative supply networks, knowledge infrastructure, exploratory intelligence, organizational systems, and outcome formation. Its resource model increasingly includes knowledge objects, actors, organizations, places, relationships, formations, and real-world systems whose identities must remain meaningful across organizational boundaries.

The 451 ecosystem illustrates the problem concretely. Musewoods contains exploratory knowledge, Wellzai contains knowledge associated with outcome networks, and RSM maintains foundational models and specifications. Although these systems share concepts and relationships, their knowledge and object identities have historically been associated with individual repositories, paths, and application-specific data models.

Federated Semantic Spaces introduce an additional requirement. Independently managed systems must be able to exchange references and resolve authoritative resource identities without surrendering control of their knowledge or assuming that every other participant uses the same software.

A universal naming and resolution system is therefore a prerequisite for durable semantic federation.

1.2. Purpose#

This specification defines how an RSM resource receives a globally distinguishable, persistent identifier and how that identifier can be resolved into trustworthy information. It also defines how structured resource names, jurisdictional context, namespace authority, and Semantic Spaces participate in identity management.

The purpose is not merely to shorten identifiers or create permanent web links. It is to establish identity as a foundational infrastructure service upon which semantic knowledge, governance, provenance, relationships, and interoperable applications can be built.

1.3. Scope#

This specification covers canonical resource identity, registered namespace allocation, structured resource naming, Semantic Space naming, issuance, authority delegation, resolution, resource representations, lifecycle management, geographic governance, security, interoperability, and implementation conformance.

It does not define the entire RSM semantic ontology, a complete content management system, the internal implementation of Locus, or the user experience of Atlas. Those systems SHALL consume this identity architecture through stable RSM Core contracts.

1.4. Design principles#

The architecture is based on ten principles.

1. Every canonical RSM resource SHALL have one persistent RID.
2. An RID SHALL be independent of resource meaning, hosting location, and current owner.
3. Registered authorities SHALL be able to issue resource identities independently within delegated namespaces.
4. Structured RRN naming SHALL provide explicit namespace and issuance context without replacing RID.
5. Every Semantic Space SHALL possess a canonical RSN and a permanent RID.
6. Resolution SHALL separate resource identity from resource representation and infrastructure location.
7. Governance SHALL incorporate jurisdiction, bioregion, stewardship, and data residency where relevant.
8. Semantic relationships SHALL reference persistent identities rather than application paths.
9. Resolution SHALL preserve access controls, privacy, authority provenance, and auditability.
10. Persistent identity SHALL survive ordinary resource, application, organization, and infrastructure changes.

1.5. Normative terminology#

MUST and SHALL indicate mandatory conformance requirements. MUST NOT and SHALL NOT prohibit behavior. SHOULD indicates a strongly recommended behavior that may be departed from only with a documented rationale. MAY indicates permitted optional behavior.

Examples in this document are illustrative unless explicitly designated as registered identifiers. They do not imply that example domains, prefixes, namespaces, or resources have already been registered or deployed.

2. Foundational Identity Concepts#

2.0. RSM ID — system boundary and normative composition#

RSM ID is the universal identity system governed by RSM Core. It SHALL define and preserve canonical resource identification, registered naming, controlled issuance, authority delegation, authoritative identity records, identity lifecycle, trusted bindings, and federated resolution through one coherent contract. RSM ID SHALL NOT be interpreted as a new resource identifier type, a replacement for RID, or a synonym for a public resolver hostname. The permanent resource identifier within RSM ID is the RID; RRN and RSN are registered naming constructs, and the HTTPS identifier is a web representation of the RID.

The normative relationship among these constructs is as follows: a distinguishable resource referent has a permanent canonical RID once registered; registered RRNs associate names with that RID; an RSN names a Semantic Space, which itself has an RID; the RSM Identity Record preserves issuance, naming, lifecycle, and authority information; trusted resolution locates permissible authoritative representations without transferring knowledge ownership to the registry. RSM ID governs identity, not the complete semantic meaning, content, ownership rights, or behavior of the represented resource.

flowchart TB
    REF["Resource referent"] --> RID["RID: permanent identifier"]
    RRN["RRN: registered resource name"] --> IR["RSM Identity Record"]
    RID --> IR
    AUTH["Registered authority and delegation"] --> IR
    IR --> REG["RSM ID registry"]
    REG --> RES["Policy-aware resolver"]
    RES --> SPACE["Authoritative Semantic Space"]
    RSN["RSN: name of Semantic Space"] --> SPACE
    SPACE --> LOCUS["Locus: authoritative representations and relationships"]

RSM ID SHALL remain logically distinct from Semantic Space implementation and from the identity or authentication of an actor performing an operation. A registered identifier does not, by itself, prove control, consent, ownership, or authorization to access any representation.

2.1. Resource#

A resource is any distinguishable entity represented within the RSM universe. A resource may be digital, physical, conceptual, organizational, ecological, social, or computational.

Examples include a research publication, a person, a cooperative, a watershed, a farm, a concept, an AI agent, a recorded observation, a relationship, an outcome formation, or a Semantic Space.

A resource need not be publicly visible or directly retrievable to possess a canonical identity. RSM distinguishes the existence of an identity record from permission to discover or access it.

2.2. RID — RSM Identifier#

An RID is the permanent canonical identity of a resource. It SHALL identify one and only one resource referent and SHALL NOT be reassigned to another resource.

An RID consists of a registered prefix and an issuer-generated suffix:

<prefix>.<suffix>

Illustrative example:

451.7K4M9Q2X8D5P0R6T

The prefix identifies a registered issuance namespace. The suffix uniquely identifies a resource within that namespace. The complete RID is the canonical identifier; neither portion independently identifies the resource.

RID intentionally contains no mandatory resource type, Semantic Space, bioregion, jurisdiction, owner, or application location. These attributes are maintained through resolvable metadata.

2.3. RRN — RSM Resource Name#

An RRN is a registered, structured resource name representing the namespace under which a resource has been issued or named.

The RRN grammar is:

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

Illustrative example:

rrn:451:451labs:global:rsm:concept/formation

An RRN provides human-readable and machine-parseable context. It serves as a structured name, governance address, and lookup key associated with an RID.

For v1.0, every registered RRN SHALL resolve to exactly one canonical RID. The same RID MAY have historical or alternate registered RRNs where namespace migration or other governed transitions require them.

Unlike RID, an RRN may be superseded by a newly registered name while preserving its original RID association. Previously issued RRNs MUST NOT be reassigned to unrelated resources.

2.4. RSN — RSM Space Name#

An RSN is an RRN identifying a Semantic Space.

Example:

rrn:451:451labs:us-ca:wellzai:space/root

The corresponding Semantic Space also possesses its own RID, which is its persistent canonical identity.

RSN is not a separate incompatible naming scheme. It is the specialized space resource kind within RRN.

2.5. RSM Web Identifier#

An RSM Web Identifier is a stable HTTPS representation of an RID.

The proposed RSM ID web pattern is (subject to domain stewardship and deployment verification):

https://rsmid.org/<rid>

Example:

https://rsmid.org/451.7K4M9Q2X8D5P0R6T

The rsmid.org domain is proposed and SHALL NOT be represented as an operational or authoritative resolver until domain control, deployment, trust bindings, and stewardship are verified. A conforming resolver operating under another approved hostname MAY resolve the same RID.

The RID remains authoritative as the resource's persistent identity; the HTTPS URL supplies web interoperability and a practical entry point for people, applications, and agents.

2.6. Identity versus description#

An RID answers the question, “Which resource?”

An RRN answers, “Under which structured namespace was this resource named?”

A resolver answers, “What authoritative information and representations are currently available for this identity?”

A Semantic Space answers, “Which knowledge and governance environment is responsible for the resource's authoritative record?”

These responsibilities SHALL remain logically distinct.

3. RID Syntax and Issuance#

3.1. Canonical syntax#

The v1.0 RID grammar SHALL be:

RID = prefix "." suffix

The canonical prefix SHALL contain one to sixteen decimal digits, without leading zeros except for the single digit zero. The suffix SHALL contain twelve to thirty-two uppercase Crockford Base32 characters from the canonical alphabet:

0123456789ABCDEFGHJKMNPQRSTVWXYZ

The initial implementation SHALL use a sixteen-character suffix containing 80 bits of uniformly generated randomness.

Example:

451.7K4M9Q2X8D5P0R6T

The complete RID SHALL be compared using exact canonical character equality. Implementations SHALL reject noncanonical case, unsupported characters, malformed separators, or unknown prefix registration during authoritative validation.

A user-facing interface MAY provide case-insensitive input assistance, but the stored and exchanged canonical RID SHALL always use the specified representation.

3.2. Prefix allocation#

An RID prefix represents a registered issuance namespace. Prefix values MUST be globally unique within the RSM identity registry and MUST NOT be reused after retirement.

The initial 451 prefix is proposed for the controlled 451 federation. Its formal issuance and namespace ownership MUST be registered before production use.

A prefix registry SHALL maintain its registered controller, issuance permissions, administrative delegation, validity status, signing-key information, and operational contact or succession arrangements where applicable.

A prefix does not necessarily reveal the current owner of an individual resource. Ownership and operational management may change while the permanent RID remains unchanged.

3.3. Suffix generation#

The default RID suffix generator SHALL use a cryptographically secure random number generator to obtain eighty independent random bits and encode them as sixteen Crockford Base32 characters.

Issuers SHALL check local registry uniqueness before finalizing issuance. Implementations MUST NOT rely exclusively on a timestamp, application-local sequential counter, document title, or hash of mutable content for global uniqueness.

Alternative suffix allocation strategies MAY be introduced under separately registered issuance profiles. Such strategies MUST provide equivalent uniqueness and non-reuse guarantees.

3.4. Concurrency and uniqueness#

A namespace authority MAY operate multiple issuance services. Such services SHALL coordinate through a collision-safe issuance contract, including atomic insertion into the authoritative registry or a verifiably disjoint delegated allocation scheme.

An issuer receiving an identifier collision SHALL generate another suffix and retry. A failed issuance SHALL NOT return an identifier that is represented as authoritative before successful registration.

3.5. Immutability and non-reuse#

An issued RID SHALL remain associated with its original resource referent throughout the lifetime of the identity registry.

Deletion, archival, organizational transfer, application migration, jurisdictional change, or resource unavailability SHALL NOT permit reuse of that RID.

If a resource is permanently withdrawn, its identity record SHALL retain a suitable tombstone, subject to applicable privacy, retention, and legal requirements.

3.6. Example: a research paper#

Suppose Wellzai publishes a paper titled “Outcome Formation Model.”

The resource receives:

451.7K4M9Q2X8D5P0R6T

Its initial RRN might be:

rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model

The paper may subsequently be revised, moved to a different application, or transferred to another stewardship organization. Its RID remains the same, while its current revision, landing-page URL, authority bindings, and permitted representations change through governed metadata updates.

A substantially distinct edition MAY receive a separate RID when the publication policy treats that edition as a new referent. Such decisions SHALL follow documented resource granularity rules rather than arbitrary implementation behavior.

4. RRN and RSN Naming Model#

4.1. Structured naming grammar#

RRN SHALL retain the following structure:

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

For v1.0, namespace segments SHALL be normalized lowercase ASCII identifiers. The grammar SHALL be published as machine-readable ABNF and implemented through a single RSM Core conformance suite.

Resource paths SHALL reject wildcard characters, traversal components, ambiguous percent encodings, and empty path elements. Canonical RRNs SHALL NOT be reconstructed from mutable application URLs.

4.2. Structural meaning#

The realm identifies the registered federation namespace. The authority identifies the registered namespace issuer. The jurisdiction identifies the issuance governance scope. The space identifies the logical Semantic Space namespace. The kind identifies the resource's primary registered kind, and the resource ID identifies the resource within that local namespace.

These fields describe registration and issuance context, not the full current meaning or legal status of a resource.

4.3. RRN mapping to RID#

Each RRN registry record SHALL include the canonical RID to which it refers.

Example:

The mapping SHALL be unique in the RRN-to-RID direction. Two distinct current RRNs MAY map to the same RID only when explicitly registered as aliases or successor names.

4.4. Naming changes#

A resource may move between Semantic Spaces without changing its RID. Where the move requires a different registered namespace, the new authority MAY issue a new RRN associated with the existing RID through an authenticated transfer process.

The original RRN SHALL remain reserved and SHALL continue resolving to the original RID or an authorized historical mapping.

Example:

Original RRN:

rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model

Successor RRN:

rrn:451:451labs:us-ca:rsm:document/outcome-formation-model

Both may resolve to the same RID after an approved transfer. The registry MUST preserve which RRN was authoritative during each effective period.

4.5. Semantic Spaces#

Every Semantic Space SHALL have its own RID and registered RSN.

Examples of proposed initial spaces are RSM Core, Wellzai, and Musewoods. These spaces may operate on separate Locus instances while sharing the same RSM identity model.

A Semantic Space is a governed logical resource. It SHALL NOT be confused with its current Go process, database, container, hostname, or application frontend.

4.6. Personal and organizational spaces#

A person, cooperative, company, research institution, or community MAY administer one or more Semantic Spaces, provided the relevant identity and authority requirements are met.

An authority may delegate namespace issuance and space administration without transferring ownership of every resource represented within those spaces. Authority delegation and resource ownership SHALL remain separate governance relationships.

5. RSM Identity Registry#

5.1. Registry responsibilities#

The RSM Identity Registry is the logical infrastructure responsible for persistent identity registration, uniqueness, namespace delegation, identity lifecycle, and resolution metadata.

The architecture MAY distribute registry functions across independently administered systems. It SHALL nevertheless provide consistent rules for prefix allocation, RID uniqueness, namespace authority, and registry integrity.

5.2. Registry hierarchy#

The registry architecture SHALL distinguish four logical registries:

1. Prefix Registry — globally unique RID prefix allocations.
2. Authority Registry — authenticated namespace controllers and delegated authority.
3. Resource Identity Registry — permanent RID records and lifecycle mappings.
4. Space Registry — Semantic Space identities, capabilities, and authoritative resolution endpoints.

These functions MAY share a physical implementation in the initial release. Their contracts SHALL remain independently defined to allow future federation and replication.

5.3. Resource identity record#

The minimum durable identity record SHALL contain the RID, issuing prefix, creation timestamp, registered referent descriptor, lifecycle status, issuance provenance, and enough metadata to prevent reassignment.

It SHOULD additionally contain current and historical RRNs, resource kind, current authoritative RSN, resolution bindings, governance references, and revision metadata where those attributes are available.

The identity registry need not contain the full resource body or every relationship. Authoritative content remains the responsibility of the relevant Semantic Space.

5.3.1. Canonical RSM Identity Record#

An RSM Identity Record is the durable, authoritative registry-level record for one RID. It is not a second identity, and it is not the complete semantic resource object. A conforming record SHALL bind the RID to one registered referent descriptor and preserve the issuing namespace, identity lifecycle, issuance provenance, and information required to prevent reassignment. Where applicable, it SHALL associate registered RRNs and their effective history, authoritative space bindings, delegated authority history, and audit events; it SHOULD reference governance and external identifier mappings without asserting unsupported equivalence.

The RSM Identity Record SHALL have the RID as its canonical key. Registered RRNs SHALL map to exactly one RID, while a RID MAY have several names over time. Every Semantic Space SHALL have an RSM Identity Record of its own, including an RID and registered RSN. Space bindings SHALL distinguish the logical authoritative Semantic Space from any particular Locus process, host, deployment, or content database.

Identity records SHALL NOT contain a required copy of the resource body. Semantic attributes, content revisions, formation state, domain relationships, and application-specific projections remain under the authority of their proper resource and Semantic Space contracts. An identity record SHALL NOT be treated as evidence that its issuer owns the real-world referent, nor as proof that independently issued external identifiers denote the same referent.

Illustrative identity-record envelope (not a finalized serialization 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>

A versioned normative schema SHALL specify precise field types and lifecycle constraints before production conformance. The example tokens are placeholders, not evidence of registration or production resolution.

5.4. Registry trust#

An authority SHALL prove that it has permission to issue identifiers under a registered prefix. The registry MUST support authenticated administration, auditable delegation changes, signing-key rotation, and revocation.

Federated resolvers MUST distinguish trusted registration records from unverified claims made by remote systems. A host advertising a resource does not automatically become its authoritative controller.

5.5. Registry independence#

RSM SHALL NOT require every resource lookup to contact one centralized database. Prefix registries, verified authority bindings, and resource resolution records MAY be replicated, cached, or distributed.

The reference implementation SHOULD begin with a simple authoritative registry and then add federation as an explicit compatibility-preserving extension.

6. Resolution Protocol#

6.1. Purpose#

The RSM Resolution Protocol maps persistent identities to current, permitted information about their referents. It SHALL enable a requester to obtain authoritative metadata, locate available representations, discover permitted relationships, and understand the resource's current lifecycle.

Resolution is not equivalent to fetching a file. A resource may be physical, abstract, protected, retired, or represented through several different forms.

6.2. Resolution input#

Resolvers SHALL accept a canonical RID as the primary identifier.

Resolvers MAY also accept registered RRNs, RSNs, HTTPS identity URLs, or recognized aliases. Such inputs SHALL first be normalized or mapped to the corresponding canonical RID before resource-level resolution.

6.3. Logical resolution sequence#

A conforming resolver SHALL:

1. Validate the RID grammar.
2. Resolve and verify the registered prefix.
3. Locate an authoritative identity record or authorized resolution service.
4. Verify the applicable namespace and resource authority.
5. Determine the identity lifecycle and permissible disclosure.
6. Select a representation according to the request and supported capabilities.
7. Return authoritative metadata, a representation, a permitted redirect, or a typed resolution status.

A resolver SHALL NOT assume that the RID prefix directly identifies a server hostname.

6.4. HTTPS representation#

The proposed public HTTPS resolver SHALL use:

https://rsmid.org/<rid>

The base hostname SHALL be configurable within conforming resolver implementations. The RID-to-path mapping SHALL remain deterministic across registered gateways.

The HTTPS endpoint SHALL support GET and HEAD. A successful human-readable request SHOULD return an identity landing page, while a machine-readable request SHOULD return structured identity metadata or an explicitly indicated location for it.

6.5. Content negotiation#

Resolvers SHOULD support at least:

• text/html — human-readable identity landing page.
• application/ld+json — interoperable JSON-LD representation.
• application/json — RSM identity and resolution record.

Other media types MAY be supported through registered representation profiles. Responses that vary by content negotiation SHALL use appropriate HTTP cache variation controls.

6.6. Identity landing page#

A public identity landing page SHOULD display the canonical RID, resource name, kind, issuing authority, authoritative Semantic Space, current lifecycle, permitted description, provenance summary, and available representations.

Where disclosure is authorized, it SHOULD also provide related concepts, semantic relationships, source publications, revisions, geographic context, and stewardship information.

The landing page is a representation of the resource identity and SHALL NOT be confused with the resource itself. A physical watershed, for example, is not equivalent to the HTML page describing it.

6.7. Redirect behavior#

A resolver MAY redirect a user to an authoritative application page or representation when requested by an explicit resolution mode or suitable media negotiation.

The default persistent identity URL SHOULD provide a durable identity landing page rather than always redirecting directly to a potentially transient file or application route. This preserves discoverability and provenance when content is moved or withdrawn.

6.8. Resolution statuses#

Conforming resolution services SHALL distinguish, at the logical protocol level, the following outcomes:

The HTTP transport profile SHALL specify the mapping of these statuses to HTTP response codes and bodies. External responses MUST avoid revealing protected resource existence where policies prohibit such disclosure.

6.9. Contextual representation#

A resolver MAY return different representations based on content negotiation, language preference, application capability, and authenticated access rights.

The underlying canonical RID and resource referent MUST remain unchanged. Contextual resolution SHALL NOT silently reinterpret one RID as identifying different resources for different users.

For example, a researcher may receive a provenance-rich representation of a watershed, while a public visitor receives a simplified description. Both representations refer to the same watershed identity, and both remain subject to current disclosure policy.

6.10. Resolver portability#

Any conforming resolver with access to trusted registry information MAY resolve an RID. The architecture SHALL support multiple gateways without altering the canonical identifier.

Resolvers MAY be operated by RSM Core, 451 Labs, partner organizations, or independent federated participants. A public gateway is a convenience and interoperability mechanism, not the sole authority over every resource.

7. Semantic Resource Representations#

7.1. Common resource envelope#

An RSM resource representation SHALL expose its canonical RID and SHOULD include its primary RRN, registered kind, authoritative RSN, provenance, revision or state information, and semantic context.

The envelope SHALL be independent of the application's presentation framework. Rich content structures and domain-specific attributes MAY be supplied through registered extensions.

7.2. Illustrative JSON representation#

The following example describes a hypothetical Wellzai research document:

{
  "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"
    }
  ]
}

The final implementation SHALL define this structure through versioned JSON Schema and interoperability profiles. The example is conceptual and does not imply that the RID has actually been issued.

7.3. Identity and knowledge separation#

The identity registry is responsible for naming and persistent identity records. A Semantic Space is responsible for its authoritative knowledge representations.

Locus MAY serve resource bodies, metadata, revisions, and relationships. It SHALL NOT be required to implement the entire global identity registry or every federation capability.

7.4. Semantic relationships#

Relationships SHALL use canonical RIDs as their primary resource references.

For example, a Wellzai formation model may declare that it extends the RSM concept of Formation. The relationship SHALL identify both resources by RID and retain the originating space, predicate, assertion authority, and provenance.

A relationship requiring independent lifecycle, provenance, permission, or revision management SHALL be eligible for its own RID.

7.5. External identifiers#

RSM resources MAY be associated with identifiers issued by independent systems, including DOI, ORCID, ISBN, recognized geographic registries, and domain-specific institutional identifiers.

Such associations SHALL preserve the authority and semantics of the external identifier. RSM SHALL NOT silently treat an external DOI or ORCID as an RSM-issued RID.

An external identity may be represented through relationships such as sameAs, identifiedBy, derivedFrom, or more specific RSM predicates, subject to evidence and equivalence rules.

8. Location, Jurisdiction, and Bioregional Governance#

8.1. Governance dimensions#

RSM distinguishes the permanent RID from governance attributes associated with the resource and its issuing authority.

The governance model SHALL support issuance jurisdiction, current legal jurisdiction, ecological context, bioregions, watersheds, stewardship authority, territorial rights, and data residency.

These attributes MAY evolve independently of the RID.

8.2. Issuance jurisdiction#

The jurisdiction segment of the primary issuance RRN identifies the governance scope under which that name was registered.

It SHALL be maintained as historical issuance metadata and MUST NOT automatically change when the resource moves, its administrator changes, or its geographic subject is revised.

8.3. Geographic context#

A resource MAY be associated with multiple bioregions, watersheds, geographic extents, and legal jurisdictions simultaneously.

Such relationships SHALL identify the underlying places or geographic classification records through canonical or registered external identifiers. RSM SHOULD reference established geographic standards and preserve classification provenance.

8.4. Example: a watershed#

Consider a hypothetical watershed spanning multiple administrative jurisdictions. Its canonical RID may be:

451.6R8T2W9K4M7P0Q5X

The resource's semantic description may associate it with multiple legal jurisdictions, a hydrological unit identifier, ecological regions, upstream and downstream relationships, and stewardship organizations.

None of these attributes needs to appear in the RID. Changes in administrative boundaries or ecological classification can be recorded as temporal updates without changing the identity of the underlying watershed.

8.5. Stewardship and ownership#

The authority issuing an identifier MAY differ from the legal owner of a resource, its operational custodian, or the community entitled to steward associated knowledge.

RSM governance SHALL represent these roles separately. Issuance of an RID SHALL NOT confer legal ownership, consent, access rights, or authority to disclose sensitive ecological or community knowledge.

8.6. Policy evaluation#

Authorization decisions SHALL use current, trustworthy governance metadata and authenticated principal context.

A resolver MUST NOT assume that the RID prefix or the issuance jurisdiction establishes the full set of applicable legal or ecological policies. Where current location metadata is missing or disputed, the policy engine SHALL apply explicitly defined handling rules, including conservative denial when required.

8.7. Data residency#

Data residency describes where representations may be stored, processed, or transferred. It SHALL remain distinct from the canonical RID and issuing jurisdiction.

Locus nodes MAY be deployed in geographically constrained environments. Their data handling policies SHALL not require altering an object's persistent identity solely because an authorized deployment moves to another hosting region.

9. Identity Lifecycle and Persistence#

9.1. Lifecycle states#

An RID SHALL have an explicit registry lifecycle. Supported states SHALL include active, deprecated, superseded, retired, and reserved.

These states describe the identity's registry status. They SHALL NOT be confused with an application's publication states such as draft, review, published, archived, or withdrawn.

9.2. Revision versus identity#

An RID identifies a continuing resource. A revision reference identifies an immutable historical state of that resource.

For example, a paper's RID may remain constant across revisions 1, 2, and 3, while the resolver supplies a version-specific representation when an explicit revision selector is requested.

RSM SHALL define revision selection separately from RID syntax. An implementation MUST NOT embed a mutable revision number into the permanent canonical RID.

9.3. Content integrity#

An optional cryptographic content digest MAY identify the exact bytes of a representation. The digest SHALL be stored separately from the RID.

The system SHALL distinguish immutable representation integrity from persistent resource identity. Changing the bytes of a document may change its digest while preserving the RID of the continuing document.

9.4. Transfer and succession#

A resource MAY change administrative authority, Semantic Space, infrastructure, or legal ownership without changing its RID.

Transfers SHALL preserve an auditable chain of authority and effective dates. An RRN MAY be superseded as part of an authorized transfer, but its historical association with the RID SHALL remain discoverable to authorized parties.

9.5. Retirement and tombstones#

A permanently withdrawn resource SHALL retain its reserved RID. Where permitted by law and disclosure policy, resolution SHOULD return a tombstone stating that the resource is no longer available.

Tombstones SHOULD preserve appropriate historical and succession references without unnecessarily retaining restricted content.

9.6. Long-term stewardship#

A persistent identifier requires stewardship beyond the lifetime of a specific application or server.

RSM namespace authorities SHOULD maintain continuity arrangements covering registry backups, authority succession, key recovery or replacement, disaster recovery, and long-term preservation of identifier records.

The federation SHOULD define mechanisms for preserving identifier mappings if an operator or organization permanently ceases operation.

10. Federation and Semantic Spaces#

10.1. Federation model#

The RSM identity system SHALL support independently operated Semantic Spaces connected through shared identity, registered authority, and resolution protocols.

A federation SHALL NOT require all participating spaces to use the same physical database or application implementation.

10.2. Locus responsibilities#

Locus is a proposed lightweight semantic engine capable of operating a Semantic Space. A conforming Locus implementation SHALL consume the RID, RRN, RSN, and resolution contracts supplied by RSM Core.

Locus SHOULD support resource storage, metadata, relationships, revisions, provenance, policy evaluation, and federation capabilities appropriate to its deployment profile.

10.3. Atlas responsibilities#

Atlas is the proposed unified explorer of federated Semantic Spaces.

Atlas SHALL use canonical RIDs to reconcile resource references and navigate cross-space relationships. It MAY aggregate descriptions and search results from multiple sources, but SHALL preserve authority and provenance rather than treating aggregated data as its own canonical knowledge.

10.4. RSM, Wellzai, and Musewoods#

The initial federation SHALL include three logical Semantic Spaces: RSM, Wellzai, and Musewoods.

RSM provides foundational model and specification resources. Wellzai provides organizational, market, and outcome-formation knowledge. Musewoods provides exploratory intelligence through journals, stories, fieldnotes, seednotes, and related instruments.

The three spaces SHALL be able to reference the same persistent resources while retaining independent content lifecycles and governance policies.

10.5. Federation query#

A federated query MAY search multiple Semantic Spaces and combine results using canonical RID identity as the deduplication key.

Search ranking and semantic relevance SHALL remain separate from identity equivalence. Two resources with similar descriptions SHALL NOT be merged unless they possess the same canonical RID or a verified equivalence relationship supported by explicit authority and evidence.

10.6. Federation growth#

New organizations, individuals, communities, and institutions MAY participate by registering appropriate namespace authority and operating conforming Semantic Spaces.

The federation SHOULD support small independently operated nodes as well as larger hosted environments. Participation SHALL not require adoption of 451 application interfaces or one mandatory hosting provider.

11. Security, Privacy, and Trust#

11.1. Identity is not authentication#

An RID identifies a resource but is not proof of possession, ownership, or authority.

Authentication SHALL establish the principal requesting an operation. Authorization SHALL determine whether that principal may interact with the resource under applicable policy.

11.2. Namespace authorization#

Only registered and properly delegated issuers SHALL create authoritative RID records under a prefix.

Registry mutations SHALL require authenticated requests and appropriate authorization. Key rotation, namespace transfer, revocation, and other sensitive operations SHALL produce auditable records.

11.3. Privacy-sensitive resources#

Sensitive persons, places, ecological knowledge, or organizational records MAY possess permanent RIDs without being publicly discoverable.

Resolvers SHALL implement disclosure rules that prevent unauthorized access to metadata, existence information, relationships, or resource representations.

11.4. Resolver trust#

Resolvers MUST validate authoritative namespace bindings and MUST NOT accept unverified endpoint claims as proof of resource authority.

Remote endpoints SHALL be accessed through a controlled transport policy designed to prevent unsafe redirects, untrusted internal-network access, credential forwarding, and related resolver abuse.

11.5. Collision and impersonation protection#

Prefix registration SHALL prevent duplicate assignments within the governed namespace. Issuers SHALL ensure local uniqueness, and resolvers SHALL reject conflicting claims that cannot be reconciled through authoritative registry provenance.

Human-friendly aliases SHALL NOT be treated as security principals or proofs of authority.

12. RSM Core Implementation Contract#

12.1. Required modules#

RSM Core SHALL define the following modules:

These names indicate logical modules and do not require a particular source repository structure.

12.2. Language independence#

The normative model SHALL be independent of programming language.

Go, Rust, TypeScript, and future language implementations SHALL use the same canonical grammar, identifier test vectors, serialization rules, and interoperability schema contracts.

The Go Locus engine SHALL NOT independently redefine RID issuance or RRN comparison semantics.

12.3. Reference implementation#

The initial RSM Core implementation SHOULD include a pure identity library, a local persistent registry, an HTTPS resolver, and a machine-readable conformance suite.

SQLite MAY be used for the prototype registry and local Locus persistence, provided transactional uniqueness and durable identity records are supported.

12.4. Standard interfaces#

The RSM Core library SHALL expose logical operations equivalent to:

• Issue RID under a delegated prefix.
• Parse and validate RID.
• Parse and validate RRN/RSN.
• Register resource identity and authoritative metadata.
• Associate and supersede registered RRNs.
• Resolve RID into authorized identity metadata.
• Locate the authoritative Semantic Space.
• Resolve a selected representation.
• Record lifecycle and authority transitions.
• Validate conformance fixtures.

The concrete Go interfaces and HTTP schemas SHALL be published in the implementation contract.

13. Worked Examples#

13.1. Example A — A Musewoods fieldnote#

A Musewoods fieldnote titled “Code Meets Soil” is authored and published through a Musewoods Semantic Space.

It receives a permanent RID. The fieldnote's current application page, title, subject classifications, content revision, and public visibility are attached as metadata. If Musewoods later changes its web framework or URL structure, the same RID continues resolving through the current authoritative space.

A reader citing the fieldnote can therefore preserve the permanent identity rather than relying exclusively on its application route.

13.2. Example B — A Wellzai formation model#

A Wellzai research document describes the Outcome Formation Model and references several foundational RSM concepts.

The paper receives one RID. Each referenced RSM concept has its own RID. Semantic relationships connect them through identifiable assertions with provenance and authority.

Atlas can discover the paper through Wellzai and traverse its relationships into the RSM Semantic Space without copying the authoritative RSM concepts into Wellzai.

13.3. Example C — A regenerative watershed#

A watershed is represented as a physical-world RSM resource. Its RID does not encode its name, geographic coordinates, country, or hydrological classification.

Its metadata references applicable watershed registries, multiple jurisdictions, bioregions, governing institutions, and ecological relationships.

An updated watershed boundary or classification changes the resource description and spatial references, not necessarily the underlying RID.

13.4. Example D — An organization changes ownership#

A cooperative has an RSM identity and an independently managed Semantic Space. Responsibility for maintaining that space is transferred to a new registered authority.

The cooperative's RID persists. Registry authority records and current governance metadata change, and a new structured RRN may be registered if required. Historical records preserve the previous namespace context.

Applications continue referencing the original RID while authorized resolvers return the current authority and representations.

13.5. Example E — A resource becomes private#

A research note is initially published publicly but later restricted under an applicable policy.

Its RID remains valid. A public resolver no longer exposes restricted metadata or content, while authorized principals may continue resolving it through authenticated requests.

The identity lifecycle and access lifecycle remain separate.

14. Conformance Requirements#

14.1. Core conformance#

A conforming core implementation MUST parse, validate, generate, serialize, and compare canonical RIDs deterministically.

It MUST also parse and validate RRNs and RSNs, preserve registered RRN-to-RID mappings, and reject malformed identifiers.

14.2. Issuer conformance#

A conforming issuer MUST enforce prefix delegation, suffix uniqueness, atomic registration, permanent non-reuse, and auditable issuance provenance.

It MUST NOT claim globally authoritative issuance under an unregistered or unverified prefix.

14.3. Resolver conformance#

A conforming resolver MUST resolve canonical RID inputs through verified registry authority and support typed resolution outcomes.

The HTTP profile MUST support human-readable and machine-readable identity responses and enforce applicable disclosure policies.

14.4. Federation conformance#

A conforming federated system MUST preserve canonical RIDs across cross-space references and avoid unauthorized ownership assumptions.

It MUST distinguish source-authoritative resource records from cached or derived representations.

14.5. Acceptance tests#

The v1.0 implementation SHALL pass at least the following tests:

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

A successful test suite SHALL be supplemented by negative tests covering invalid encodings, ambiguous aliases, revoked authorities, concurrent transfers, stale caches, and malicious endpoint responses.

15. Adoption and Migration#

15.1. Implementation sequence#

The implementation SHALL begin within RSM Core, then extend to Locus and the three initial Semantic Spaces.

The recommended order is identity library, naming library, registry, resolver, Semantic Space bindings, migration adapters, and finally unified Atlas exploration.

15.2. Legacy identifiers#

Existing Musewoods, Wellzai, and RSM identifiers MAY be retained as aliases. Migration SHALL register explicit relationships between legacy IDs, RRNs, and newly issued RIDs.

Existing links SHOULD continue working through application redirects or local alias resolution wherever practical.

15.3. Resource identity boundaries#

Migration MUST distinguish resources that are the same continuing referent from merely related resources. Similar titles, shared subjects, equivalent descriptions, or common source files do not automatically establish identity equivalence.

Where different systems have independently represented the same entity, reconciliation SHALL retain evidence and require an authorized identity-equivalence decision.

15.4. Initial federation#

The first implementation SHALL demonstrate RSM, Wellzai, and Musewoods resolving through a common identity service while preserving independent Semantic Spaces.

A resource SHALL be retrievable by its RID, discoverable through its Semantic Space, and connectable to resources in other spaces through persistent semantic relationships.

16. Specification Governance#

16.1. RSM Core ownership#

RSM Core SHALL own the normative identity, naming, and resolution specification. Consuming applications SHALL not modify its grammar or canonical comparison semantics without an approved standard revision.

16.2. Version compatibility#

Compatible extensions MAY add metadata, registered resource kinds, or supported representation profiles without altering existing RIDs.

Changes to the canonical RID grammar, equality semantics, namespace allocation model, or irreversible identity behavior SHALL require a major specification revision.

16.3. External interoperability#

The canonical RID is an RSM-native identifier, while its HTTPS representation provides web interoperability.

The proposed rrn: notation SHALL NOT be described as an externally registered URI scheme unless the required registration process is completed. Where an external standards-compliant IRI is necessary, a stable HTTPS mapping SHALL be used.

16.4. Operational permanence#

RSM federation governance SHALL establish procedures for registry continuity, namespace succession, backup and restoration, authority transfer, disaster recovery, and preservation of retired identity records.

The promise of persistence SHALL be supported through operational policy and tested recovery procedures, rather than relying solely on the syntactic properties of identifiers.

17. Conclusion#

RSM ID — Identity, Naming & Resolution v1.0 establishes permanent identity as a foundational capability of the Regenerative System Model. It distinguishes the stable identity of a resource from its structured namespace, hosting location, current representation, governance context, and semantic relationships.

RSM ID is the unified identity system; RID supplies the compact permanent identity. RRN supplies structured naming and issuance context. RSN identifies independently governed Semantic Spaces. The RSM Resolution Protocol connects identifiers to authoritative knowledge and permissible contextual representations.

The result is a foundation through which independently operated people, organizations, applications, and semantic engines can identify and connect resources without centralizing all knowledge or relinquishing authority.

One resource. One permanent identity. Many contextual representations. Federated authority. Enduring relationships.

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

Thaler, D., Hansen, T., & Hardie, T. (2015). Guidelines and registration procedures for URI schemes (RFC 7595). Internet Engineering Task Force. https://doi.org/10.17487/RFC7595

World Wide Web Consortium. (2008). Cool URIs for the Semantic Web. https://www.w3.org/TR/cooluris/

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