Publication class
Which shelf a document belongs on: Core Specifications, implementation architecture, or proposed. A proposed document never appears among the Core Specifications.
Specifications
The specifications govern.
This site explains.
Every claim this site makes about the model traces to one of these documents, and where the two differ the specification wins. Each document shows its publication class, status and version exactly as declared. Where its metadata and its own text disagree, both are shown until the specification owner reconciles them.
SHELF 1 · DEFINES RSM
Core Specifications
These six documents define the RSM Model and its protocol, runtime and conformance: the governed core of the Regenerative Systems Metamind. Conformance may depend on them, and concept definitions on this site are quoted only from them. Each keeps its own maturity label: the Concept Paper (01) is Normative, and 02–06 are Draft Normative under RSM-GOV-006 (how status is shown).
01
Normative · v2.1.0
↗02Regenerative Systems Metamind — A Living Outcome-Forming Ecology
Concept Paper v2.1.0
docs/01-rsm-concepts-paper.mdDraft · v2.1.3
↗03RSM Subject Model
Regenerative Systems Metamind — Normative Conceptual Specification
docs/02-rsm-subject-model.mdDraft · v4.0.3
↗04RSM Semantic Model & Taxonomy Architecture
Regenerative Systems Metamind — Normative Semantic Specification
docs/03-rsm-semantic-model-taxonomy.mdDraft · v2.4.1
↗05RSM Canonical Model & Protocol Specification
Regenerative Systems Metamind — Normative Canonical and Interaction Specification
docs/04-rsm-canonical-model-protocol-specification.mdDraft · v2.1.1
↗06RSM Runtime & Federation Architecture
Regenerative Systems Metamind — Normative Operational Architecture Specification
docs/05-rsm-runtime-federation-architecture.mdDraft · v2.1.1
↗RSM Reference Implementation & Conformance Specification
Regenerative Systems Metamind — Normative Executable Conformance Specification
docs/06-rsm-reference-implementation-and-conformance.mdSHELF 2 · REALIZES RSM
Implementation architecture
How an implementation realizes the normative set: technology choices and infrastructure. It is governed, but it does not redefine any concept in the normative documents.
SHELF 3 · NOT YET GOVERNING
Proposed specifications
Candidates for normative status, published for review. They are not part of the normative RSM specification set, are not conformance targets, and are never the source of a concept definition. Errata E1 corrected the earlier example identifiers in 01–05 to the RSM ID form https://rsmid.org/<rid>, so the documents agree on identifier form; the status of 08 and 09 is unchanged. Each document page lists its open notices.
08
Proposed · v1.1.1
↗09RSM ID — Identity, Naming & Resolution Specification
The RSM ID — Identity, Naming & Resolution Specification establishes the universal resource identity system for the Regenerative Systems Metamind (RSM). It provides persistent iden
docs/08-rsm-id-identity-naming-resolution-specification.mdProposed · v1.1.2
↗RSM ID — Core Identity Reference Implementation
This reference implementation defines the first executable foundation for RSM ID, the universal RSM resource identity system. It provides permanent RSM Identifiers (RIDs), structur
docs/09-rsm-id-core-identity-reference-implementation.mdREADING THE LABELS
How status is shown
This site never chooses between conflicting declarations. It shows what each document declares and qualifies the label when declarations disagree.
Status
Shown literally from the document's metadata. "Status under reconciliation" means its own text declares a different maturity; the document page lists both.
Version
Shown from metadata. When the document heading declares another version, the page shows both.
Proposed notices
Open conditions the owner must resolve before a proposed document could be promoted, such as an undeclared relationship to another document.
READING PATHS
Choose the path that matches the boundary you are working on.
These are reading guides only. Sequence, labels, versions and statuses come from the documents themselves.
Understand the model
Start with the Concept Paper (01), then the Subject Model (02). Learn the distinctions before turning them into types. Look up any term in Concepts.
Build an application
Read the Canonical Model & Protocol (04) for the objects, state categories and operations your application will call, then Runtime & Federation (05) for how they are served.
Integrate a system
Focus on authority, disclosure, connectors and reconciliation in 04 and 05. The Integrators page summarizes the boundary.
Extend domain meaning
Follow the Subject Model (02) and the Semantic Model & Taxonomy (03) before adding domain vocabulary. Extensions refine the grammar; they do not redefine it.
Prove an implementation
The Reference Implementation & Conformance Specification (06) defines the gates and golden scenarios. The Conformance page explains them.