RSM Model
Canonical and semantic state: kinds, relationships, state categories and the canonical progression. Specified in 01–04 (01 Normative; 02–04 Draft Normative).
Developers
Build on the model.
Keep authority explicit.
Applications, agents and connectors reach RSM through its protocol, never through its tables. That boundary is what lets each of them evolve without becoming a hidden system of record. This page shows where your code sits, where each part of the architecture fits, where each kind of state lives, and the rules every consumer follows.
WHERE YOUR CODE SITS (source: 05 §3.2, §25.3)
Applications never own the canonical shortcut.
Dependencies flow toward canonical and semantic authority. Canonical domain code does not depend on a particular database, HTTP framework, vector store, graph engine or intelligence system.
- authority evaluated
- provenance retained
- idempotency enforced
- projections stay non-authoritative
The pattern to avoid is an application reading and writing RSM database tables (source: 05 §25.3). It skips validation, authority and provenance at once.
- 01Application / Agent / Connector
Product code, autonomous agents and connectors evolve freely. They may keep local UI state and caches.
- 02RSM Client / SDK
Typed access to RSM operations. The first SDKs are Go, for servers and connectors, and TypeScript, for web applications.
- 03RSM Protocol
The governed boundary: Actor, Principal, Subject, purpose, authority and idempotency are evaluated here.
- 04RSM Runtime
Admits operations, keeps the operation and change journals, and maintains projections.
- 05Canonical + Semantic State
Authoritative RSM state. Nothing above the protocol writes to it directly.
APPLICATIONS AND AGENTS → PROTOCOL → RUNTIME → MODEL
Where each part of the Metamind sits
The full path runs from applications and agents, through the RSM Protocol and its authorized operations, to the RSM Runtime and the Canonical and Semantic Model. Identity and discovery support that path from beside it. Each part is labeled with its maturity, because a specified boundary is not shipped software.
RSM Protocol and Runtime
Authorized operations, admission, journals, projections and federation. Specified in 04 and 05 (Draft Normative). The reference implementation is planned (07), not shipped.
RSM ID
Identity, trust, issuance and resolution. Proposed specifications 08 and 09. How core protocol operations depend on it is proposed integration architecture.
R2D2 Network
The discovery, directory and federation network: participants discover one another, locate authoritative services and establish trusted connections across independently governed RSM Nodes. It refers and connects; it does not own what it discovers, and discovery is not authoritative resolution. Not governed by 01–09; its integration with the protocol is proposed.
RSM Agents
Bounded, identity-bearing participants that sense, discover, reason, orchestrate and propose. They reach the Model through the protocol as DigitalAgent Actors, like any application. The agent architecture is proposed, not a governed specification.
Cognition is not authority. An agent's plan, explanation or reported completion is not evidence that an action was authorized or done. A consequential effect still needs an authorized operation, an authenticated principal acting under current authority, and an auditable result. See why capability is not permission (source: 01 §14.2).
CANONICAL, PROJECTED AND DERIVED (source: 07 §3.2–3.4)
Where each kind of state lives
The reference architecture separates three planes of state in code. Knowing which one you are touching tells you what you may do with it. These are runtime planes, not the three conceptual planes of the Model.
Canonical plane
Locally authoritative state and the rules for changing it: persistence, semantic validation, identity resolution, authority, policy, revisions, provenance and the journals. No projection or intelligence component mutates it directly.
Projection and discovery plane
Search, graph, spatial and vector views, plus Biography over canonical history. Every projection is rebuildable, provenanced, permission-aware and non-authoritative. Deleting one never destroys canonical meaning.
Intelligence plane
Consumes authorized state and produces Derived reasoning: Configurations, Gaps, Pathways, Recommendations. It owns none of the participants' canonical state, and the reference reasoner can be replaced without changing the canonical runtime.
THE RULES EVERY CONSUMER FOLLOWS
Six rules that keep the ecology trustworthy.
RSM is permissive about implementation technology and strict about semantic boundaries. These rules apply to applications, agents and connectors alike; Integrators applies them at the connector.
Map identity explicitly
Name similarity is not identity resolution. External identifiers map to canonical identities, and uncertain matches stay uncertain.
Preserve provenance
Every imported fact stays traceable to its source, and mappings that change meaning are versioned.
Do not bypass canonical admission
Consumers create operations, not privileged rows. Nothing becomes canonical except through the canonical mutation boundary.
Separate authentication from authority
A valid login is not permission to commit on behalf of a Subject. Agency answers whether an entity can act; Authority answers whether it may.
Keep derived reasoning derived
A Configuration, Gap, Pathway or Recommendation stays Derived wherever it is stored, and never stands in for a participant's Commitment.
Treat projections as disposable
Search, graph, spatial and vector systems are optimized views, never hidden truth. A stale projection is reconciled against its authority before anything consequential happens.
STACK BOUNDARY (source: 07 §2, §15)
The stack is an implementation choice.
The reference realization is a Go modular runtime on PostgreSQL with PostGIS, a JSON-LD, RDF and SHACL semantic contract, an HTTPS and JSON protocol described in OpenAPI 3.1, and explicit ports for search, graph, spatial, temporal, vector, embedding and model providers. It is federated externally and modular internally (source: 07 §1.3): nodes federate through the protocol, never through shared database access.
None of that defines what an RSM concept means. A technology may implement, index, project, transport or reason over part of the Model; it does not acquire authority over it. The Model shows which technology does not define which concept and the ports that keep each one replaceable. The Technology & Infrastructure Architecture (07) is an implementation architecture, not a normative specification.
FIVE PLANNED MILESTONES (source: 07 §22)
The realization plan
Planned in the Technology & Infrastructure Architecture. These are architectural capabilities, each cumulative and independently verifiable; they describe intended work, not shipped releases.
- 01R0 · Foundation and canonical core
Reconcile the existing kernel with the normative foundation and establish the full infrastructure skeleton.
- 02R1 · Protocol and projection runtime
Make the canonical Model operational through the complete protocol and a rebuildable read and projection plane.
- 03R2 · Federation and integration
Connect independently governed nodes and existing systems without weakening authority boundaries.
- 04R3 · Outcome Formation and intelligence
Realize the derived reasoning plane while keeping intelligence and authority distinct.
- 05R4 · Full conformance and adoption
Prove the complete architecture and hand it to applications and intelligence systems.
Each milestone leaves the repository fully verifiable, and every optimization must pass the same contract suites (source: 07 §24) before it replaces an adapter.
WHERE TO GO NEXT
Developer path
Learn the distinctions
Start with the Concept Paper and the Subject Model, and look up each term before turning it into a type. Every concept page quotes its governing definition.
Use the protocol
Applications call RSM operations, not canonical tables. Authority and idempotency live at that boundary.
Connect an existing system
Map identity, semantics and provenance through a Connector, and keep the source system authoritative where it legitimately is.
Prove conformance
Run the positive and negative suites. RSM is real only when invalid transitions fail at the correct boundary.