Semantic
Interprets and preserves RSM Core semantics, Concept references, foundational kinds, Domain Types, Roles and Domain Packs. Requires semantic round trip and rejection of invalid vocabulary.
Conformance
Conformance is executable.
Proof is refusal.
An implementation is not RSM because it names the right concepts. It is RSM when its observable behavior preserves the Model's distinctions, and when invalid transitions fail at the boundary where they should. This page summarizes the Reference Implementation & Conformance Specification (06); the specification governs.
WHAT CONFORMANCE ASKS
The acceptance question
Can an implementation represent, mutate, exchange, federate, observe, and reconstruct RSM state while preserving every normative distinction on which identity, authority, meaning, provenance, and Outcome Formation depend?
That is the specification's central acceptance question (source: 06 §1.2), quoted word for word. Passing API calls and unit tests is not enough. A schema with objects named Capability, Formation or Outcome is not enough either: those objects must behave according to their distinctions (source: 06 §1.4).
Conformance targets are the normative specifications only. Proposed documents, such as RSM ID (08, 09), are not conformance targets.
Conformance is conformance to the RSM Model and its protocol, runtime and federation behavior. Supporting AI agents does not make a system conformant, and there is no "Metamind-conformant" claim. Agents are tested only as Actors held to the same authority and admission boundaries as any other participant (Gate F). Any agent-specific requirements must be specified and governed separately (source: 06 §1.1); none exist today.
CONFORMANCE PROFILES (source: 06 §3)
Six profiles, so claims can be precise
Not every participant runs a full federated Runtime. A laboratory connector may expose a narrow protocol surface; an infrastructure provider may implement the whole stack. Profiles replace the ambiguous label "RSM compliant" with a claim that can be tested.
Canonical
Adds canonical objects, lifecycle, revision, provenance and category separation. Derived, Operational and Projection artifacts cannot enter canonical state by serialization or reassignment.
Protocol
Supports a declared subset of operations with full envelope semantics: Actor, Principal, Subject, purpose, authority, idempotency and explicit results. Unsupported operations are refused explicitly.
Runtime
Demonstrates persistence, history, resolution, authority, projections and recovery. Projections are proven disposable; semantics stay independent of storage technology.
Federation
Independently governed nodes interact with selective disclosure, reconciliation and node-failure semantics. Joining a network never exposes private state.
Full Reference
All profiles together, plus the golden scenarios, fault injection, recovery and end-to-end lifecycle demonstrations.
CONFORMANCE GATES (source: 06 §16)
Ten gates, in order
Each gate has its own suite. The order matters: no later gate can compensate for a semantic failure at Gate A, and Gate J is only reached from a clean environment through one reproducible verification command.
A · Semantic integrity
Governed context, Core vocabulary, foundational kinds, Concept references, Domain Packs and semantic round trip.
B · Canonical integrity
Identity, revisions, relationships, provenance, Capability and Capacity, epistemic distinctions, Commitment, Formation, Activity and Outcome. The category firebreak is executable, not documentary.
C · Protocol integrity
Operations under valid, invalid, unauthorized, denied, idempotent, conflicting, unavailable, indeterminate and unsupported conditions.
D · Runtime integrity
Persistence, journals, resolution, authority, projections, Biography, recovery and rebuild. Deleting a projection never destroys canonical meaning.
E · Federation integrity
Isolation, selective disclosure, reconciliation, semantic compatibility, node unavailability and federated Commitment, with local authority preserved.
F · Connector and agent integrity
At least one external system through a Connector and one DigitalAgent through bounded Delegation. Neither bypasses mutation, authority, policy or provenance.
G · Derived reasoning integrity
The reference reasoner produces inspectable Configurations, Gaps, Dependencies, Pathways, Recommendations and Formation Readiness, all Derived, and cannot create a Commitment or Formation.
H · End-to-end Outcome Formation
Golden Scenarios A to F, from Intent through Formation and reconciliation, with every lower invariant intact.
I · Reality, recovery and learning
Activity, Observation, Outcome, Biography, failure and restart, rebuild, adaptation and a subsequent Intent.
J · Full reference conformance
Gates A to I pass from a clean environment through the documented verification command.
GOLDEN SCENARIOS (source: 06 §13)
Eight golden scenarios
Shared proof paths. Each states what must happen and what must not.
A · Direct existing Capability
A buyer's Intent is met by existing Capability and available Capacity, from Intent through Outcome and Biography. The Candidate Configuration stays Derived, Commitments require authority, the Formation does not exist before it is established, and the Outcome stays distinct from both the Intent and the Activity.
B · Gap and Pathway formation
Existing Capability or Capacity is deliberately insufficient. The reference reasoner identifies a Gap, builds the dependency structure and proposes a Pathway with at least one condition that must change. No derived artifact may stand in for a participant's Commitment.
C · Cross-domain semantic composition
Concepts from at least three Domain Packs, such as agriculture, food, water and finance, over one shared Core. A Subject may carry several Domain Types without its identity being duplicated, and round trip preserves them.
D · Material transformation and provenance
A Material is followed from crop to grain lot to food ingredient. Each distinct Material keeps its own identity, lineage relationships preserve the transformation, and Observations or Evidence attach to the right stage, not to one generic product.
E · Authority and selective disclosure
Identity, authentication, agency, authority and disclosure stay separate. An authorized Actor succeeds; an authenticated but unauthorized one fails. The test includes a DigitalAgent or delegated representative.
F · Stale federation and reconciliation
A stale Capacity reaches federated discovery, and the authoritative node later returns a different value. Before Formation, reconciliation detects it, invalidates the affected Derived reasoning and revises it. Earlier reasoning stays inspectable, never rewritten.
G · Failure and recovery
A Runtime or federation node stops mid-cycle and restarts. Authoritative state recovers, consequential operations are not duplicated, completed Commitments survive, and the outage is recorded as unavailability, not as false domain state.
H · Outcome and learning loop
Completed Activity produces Observations, Evaluations and canonical Outcomes that update Biography. A later Intent uses that history as context while still reconciling any value whose current state matters.
THE REASONING BOUNDARY (source: 06 §4.2–4.3)
Conformance does not depend on any intelligence system.
The reference environment includes a deterministic Reference Formation Reasoner, so the Derived boundary can be tested. It produces Candidate Configurations, Gaps, Dependencies, Pathways, Recommendations and Formation Readiness, every one of them Derived and carrying its sources. It is not part of canonical RSM authority.
Wellzai may implement or replace that reasoner. RSM conformance does not depend on Wellzai-specific algorithms, APIs, prompts, application state or product architecture. Intelligence systems consume and reason over RSM; they do not decide whether RSM is correctly implemented (source: 06 §4.3). At least one participant must also take part through a Connector (source: 06 §4.4) rather than a native implementation, which proves that joining RSM does not mean replacing existing systems.
ARCHITECTURE BECOMES REAL THROUGH REFUSAL (source: 06 §23.1)
A conformant system must refuse
The strongest proof is not that valid scenarios succeed. It is that invalid transitions fail at the correct boundary.
a Person≠an Organization
Capability≠Capacity
a Configuration≠a Formation
a recommendation≠a Commitment
an inference≠an Assertion
a projection≠authority
unavailable state≠false
An implementation is RSM only when the Model's distinctions remain true (source: 06 §23.3) under execution, federation, failure, recovery and change.
NEXT
Prove an implementation.
The specification defines the fixtures, fault classes, verification report and definition of done. Each distinction a gate enforces is defined, with its source, in Concepts.