RSM Reference Implementation & Conformance Specification v2.0

#1. Purpose and Conformance Objective

#1.1 Purpose

The RSM normative specifications define a coherent conceptual, semantic, canonical, protocol, runtime, and federation architecture. Those specifications are not sufficient by themselves to establish interoperability because two implementations may claim adherence to the same documents while making materially different choices about identity, authority, semantic categories, lifecycle, protocol behavior, projection boundaries, federation, or error handling.

The RSM Reference Implementation & Conformance Specification closes that gap. It defines the minimum executable evidence required to demonstrate that an implementation preserves RSM semantics and behavior rather than merely adopting RSM terminology or reproducing its diagrams.

#1.2 Central Acceptance Question

The principal acceptance question is:

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?

Acceptance therefore requires more than successful API calls or passing unit tests. The implementation must demonstrate, through executable fixtures and end-to-end scenarios, that it refuses invalid semantic collapses as reliably as it accepts valid behavior.

#1.3 Reference Implementation

The RSM Reference Implementation is the minimum complete executable system maintained as a known-good realization of the normative RSM architecture. It is not intended to prescribe the final production topology, user experience, programming language, database engine, cloud provider, optimization strategy, or intelligence implementation.

Its purpose is to establish an inspectable behavioral baseline. Alternative implementations may differ substantially internally while remaining conformant when they satisfy the same observable semantic contracts and conformance suites.

#1.4 Conformance Is Behavioral

An implementation SHALL NOT be considered conformant merely because its schema contains objects named Capability, Formation, Outcome, or Relationship. Conformance requires those concepts to behave according to their normative distinctions.

For example, an implementation that stores Configuration and Formation in one uncontrolled record differentiated only by a string status fails conformance if that representation permits derived possibility to acquire Formation authority without crossing the required canonical establishment boundary.

#2. Normative Sources and Precedence

#2.1 Normative Source Set

The Reference Implementation SHALL be evaluated against five normative RSM documents:

The Reference Implementation & Conformance Specification does not override those documents. It translates their normative requirements into executable tests and acceptance criteria.

#2.2 Specification Before Implementation

Existing code SHALL NOT become normative merely because it predates a specification or because changing it is expensive. Where implementation and normative specification conflict, the implementation must change unless the specification itself is formally revised through the RSM governance process.

This principle prevents accidental implementation behavior from becoming permanent architecture.

#2.3 Executable Artifacts

Governed machine-readable artifacts are part of the conformance surface when the relevant normative specification designates them as authoritative companions. These may include:

JSON-LD contexts
RSM Core vocabulary
SHACL shapes
Domain Pack manifests
Predicate definitions
canonical JSON schemas
protocol schemas
valid fixtures
invalid fixtures
golden semantic projections

Executable artifacts SHALL remain traceable to the normative semantics they enforce.

#3. Conformance Profiles

#3.1 Purpose of Profiles

Not every RSM participant must operate a complete federated Runtime. A laboratory connector, for example, may expose only a limited protocol surface, while an RSM infrastructure provider may implement the complete canonical and federation stack.

RSM therefore defines conformance profiles so that systems may make precise claims rather than using the single ambiguous label “RSM compliant.”

#3.2 Semantic Conformance

A Semantic Conformant implementation demonstrates that it can interpret and preserve RSM Core semantics, the governed JSON-LD context, Concept references, foundational kinds, Domain Types, contextual Roles, semantic categories, and applicable Domain Packs.

Semantic Conformance does not require canonical persistence or federation. It does require semantic round-trip behavior and rejection of invalid governed RSM vocabulary.

#3.3 Canonical Conformance

A Canonical Conformant implementation additionally supports applicable canonical objects, lifecycle, revision, provenance, canonical mutation boundaries, epistemic distinctions, and category separation.

It must demonstrate that Derived, Operational, and Projection artifacts cannot enter canonical state merely through serialization or direct category reassignment.

#3.4 Protocol Conformance

A Protocol Conformant implementation supports a declared subset of RSM operations and preserves protocol envelope semantics including Actor, Principal or actsFor, Subject, purpose, operation identity, authority, idempotency, explicit result state, and applicable concurrency behavior.

A node need not implement every RSM operation. It SHALL advertise which operations it supports and SHALL respond explicitly when an unsupported operation is requested.

#3.5 Runtime Conformance

A Runtime Conformant implementation demonstrates canonical persistence, history, semantic resolution, identity resolution, policy and authority boundaries, projection generation, recovery, and operation processing.

Runtime Conformance requires proof that reconstructable projections are disposable and that canonical semantics remain independent of the chosen physical storage technology.

#3.6 Federation Conformance

A Federation Conformant implementation demonstrates interaction among independently governed RSM nodes, semantic compatibility negotiation, selective disclosure, authoritative reconciliation, node-failure semantics, and the preservation of local authority.

Federation Conformance SHALL prove that private state cannot be accessed merely because nodes participate in the same RSM network.

#3.7 Full RSM Reference Conformance

Full RSM Reference Conformance requires all preceding profiles together with successful execution of the required golden scenarios, fault-injection tests, recovery tests, and end-to-end lifecycle demonstrations.

This is the highest conformance level defined by this specification.

#4. Reference System Architecture

#4.1 Minimum Executable System

The minimum complete reference environment contains:

The nodes MAY run as independent processes, containers, services, or logically isolated deployments. The test environment must preserve enough separation to prove that one participant cannot bypass federation interfaces and inspect another participant's private canonical store.

#4.2 Reference Formation Reasoner

The reference environment SHALL include a deterministic Reference Formation Reasoner capable of demonstrating the Derived reasoning boundary. It need not represent the final RSM intelligence architecture and SHALL NOT be treated as part of canonical RSM authority.

The Reasoner must be capable of producing, at minimum:

Candidate Relevance
Candidate Configuration
Gap
Dependency
Pathway
Recommendation
Formation Readiness

These artifacts SHALL remain DERIVED and SHALL carry source references and derivation metadata sufficient for acceptance testing.

#4.3 No Wellzai Dependency

Wellzai MAY implement or replace the Reference Formation Reasoner, but RSM conformance SHALL NOT depend upon Wellzai-specific algorithms, APIs, prompts, application state, or product architecture.

This boundary is important because RSM is infrastructure. Intelligence systems consume and reason over RSM; they do not define whether RSM itself is correctly implemented.

#4.4 Reference Connector

At least one participant SHALL operate through a Connector rather than through a native RSM implementation. The connector must demonstrate external identity mapping, semantic mapping, provenance preservation, canonical mutation through protocol boundaries, and outbound action correlation.

This proves that participation does not require replacing existing systems with RSM-native applications.

#5. Reference Repository and Executable Artifacts

#5.1 Repository Boundaries

A reference repository SHOULD make the architectural boundaries visible. An illustrative structure is:

rsm/
├── semantic/
│   ├── context/
│   ├── vocabulary/
│   ├── domain-packs/
│   ├── shapes/
│   └── resolver/
│
├── canonical/
│   ├── subjects/
│   ├── relationships/
│   ├── capability/
│   ├── expressions/
│   ├── epistemic/
│   ├── commitment/
│   ├── formation/
│   ├── activity/
│   └── outcome/
│
├── protocol/
│   ├── envelopes/
│   ├── operations/
│   ├── validation/
│   ├── receipts/
│   └── results/
│
├── runtime/
│   ├── persistence/
│   ├── identity/
│   ├── authority/
│   ├── policy/
│   ├── history/
│   ├── projections/
│   ├── biography/
│   ├── discovery/
│   └── federation/
│
├── connectors/
│   ├── sdk/
│   └── reference/
│
├── reasoning/
│   └── reference/
│
├── conformance/
│   ├── fixtures/
│   ├── contracts/
│   ├── semantic/
│   ├── canonical/
│   ├── protocol/
│   ├── runtime/
│   ├── federation/
│   ├── connectors/
│   ├── recovery/
│   └── golden/
│
└── docs/

The physical organization MAY differ. Dependency and conformance boundaries must nevertheless remain recognizable.

#5.2 Governed Semantic Artifacts

The reference implementation SHALL consume the governed semantic artifacts rather than reproducing equivalent hard-coded definitions separately in application code.

At minimum, the executable environment SHOULD contain governed versions of:

rsm.context-v4.jsonld
rsm-core-v4.ttl
rsm.shacl-v4.ttl
Domain Pack manifests
Domain Pack concepts
Domain Pack shapes
reference predicates
semantic mappings

Tests SHALL detect if a semantic projector emits undeclared Core terms or invents an unauthorized second RSM vocabulary.

#5.3 Golden Fixtures

Golden fixtures are human-reviewable reference representations whose expected semantic meaning is controlled. They SHALL be regenerated only through an explicit update process rather than silently changing whenever implementation behavior changes.

A golden-fixture update must be reviewable as a semantic change, not merely a snapshot refresh.

#5.4 Invalid Fixtures

Invalid fixtures are equally important. They prove that the implementation rejects semantic states that would otherwise collapse RSM's normative distinctions.

Each major invariant SHOULD have one or more intentionally invalid fixtures demonstrating the expected rejection or diagnostic.

#6. Test Architecture

#6.1 Layered Verification

The conformance system SHALL operate through progressively wider test layers:

Higher-level scenario success does not compensate for lower-level semantic failure. A system that completes a golden scenario by violating a foundational invariant fails conformance.

#6.2 Deterministic Test Environment

The acceptance environment SHALL be reproducible from a clean checkout or equivalent source package. Tests must not depend upon manually prepared developer databases, undocumented credentials, unreproducible external state, or hidden environment mutations.

Reference fixtures, clocks, identifiers, and deterministic reasoning inputs SHOULD be controlled sufficiently for failures to be reproduced.

#6.3 Positive and Negative Testing

Every conformance family SHOULD include both acceptance and rejection cases. Positive tests prove that valid semantics can execute, while negative tests prove that invalid semantics cannot cross the relevant boundary.

Negative testing is particularly important for authority, semantic category, epistemic state, Formation establishment, idempotency, disclosure, and federation failure.

#7. Semantic and Subject Conformance

#7.1 Subject Semantics

Tests SHALL demonstrate that Subject is a semantic role rather than an entity superclass. A LivingSystem, Organization, Material, Person, or other applicable entity must be referenceable as a Subject without being rewritten into a universal Subject type.

Tests must also prove that being a Subject does not automatically grant Actor or Participant semantics.

#7.2 Foundational Kinds

The implementation SHALL preserve the foundational distinctions among:

Person
Organization
Community
LivingSystem
Place
Facility
Material
Instrument
DigitalAgent
Formation

Domain typing SHALL not collapse these kinds. An Organization typed as rsm:food/processor remains an Organization rather than becoming a new foundational Processor class.

#7.3 Kind, Domain Type, and Role

Fixtures SHALL prove that Foundational Kind, Domain Type, and Contextual Role are independently representable.

The same Organization must be capable of serving as buyer in one context and supplier in another while retaining stable identity and foundational kind.

#7.4 Namespace Conformance

Semantic fixtures SHALL verify use of the governed rsm: namespace and hierarchical domain concepts such as:

rsm:agriculture/soil-system
rsm:food/grain-lot
rsm:water/watershed

Unauthorized or unresolved terms under the governed RSM namespace SHALL fail or resolve explicitly as invalid governed vocabulary rather than being silently accepted.

#7.5 Domain Pack Conformance

Domain Pack tests SHALL verify manifest compatibility, dependency resolution, Concept identity, taxonomy relationships, shapes, mappings, versioning, and conflict detection.

Two active packs SHALL NOT redefine one governed RSM Concept incompatibly.

#7.6 Semantic Round Trip

At least one fixture for every supported foundational kind and major canonical family SHOULD demonstrate:

Typed Object
    → JSON-LD Projection
    → Reconstruction
    → JSON-LD Projection

The first and final projections SHALL be semantically equivalent for governed interchange content.

#8. Canonical Conformance

#8.1 Canonical Admission

Canonical tests SHALL demonstrate that only objects satisfying the applicable semantic, structural, reference, provenance, lifecycle, and authority requirements may enter canonical state.

A syntactically valid JSON document is insufficient evidence of canonical validity.

#8.2 Category Firebreak

Tests SHALL explicitly prove:

Derived artifact cannot be stored as Canonical by changing category
Projection cannot be re-imported as Canonical without mutation
Operational context cannot masquerade as Outcome
Candidate Configuration cannot masquerade as Formation
Recommendation cannot masquerade as Commitment

This category firebreak is mandatory.

#8.3 Canonical Identity

Tests SHALL verify stable identity across revision, projection, federation reference, and connector representation.

Changing labels, Domain Types, or contextual Roles SHALL not create a new entity identity unless the underlying real-world identity has actually changed.

#8.4 Revision and History

Tests SHALL demonstrate monotonic revision or equivalent version semantics, optimistic concurrency, and preservation of historical canonical state.

A stale mutation using an outdated expected revision SHALL fail explicitly rather than silently overwriting newer state.

#8.5 Relationship Integrity

Relationship tests SHALL verify resolvable endpoints, governed Relationship type, temporal semantics where applicable, provenance, and lifecycle.

Affiliation, Membership, Participation, Stewardship, and Delegation SHALL remain behaviorally distinct.

#8.6 Capability and Capacity

Tests SHALL prove:

Capability ≠ Capacity
Capacity references applicable Capability
Capability may exist with zero current Capacity
Expired Capacity cannot be treated as current Capacity
Offer does not create Capacity automatically

These distinctions must survive both storage and discovery.

#8.7 Epistemic Integrity

Canonical fixtures SHALL prove:

Observation ≠ Claim
Claim ≠ Evidence
Evidence ≠ Evaluation
Evaluation ≠ Assertion
Inference ≠ Assertion

An Observation may support an Evaluation, but no constructor or generic update operation may silently promote one epistemic category into another.

#8.8 Commitment and Formation

Tests SHALL demonstrate that Commitment requires identifiable authority and that Formation establishment requires the applicable canonical conditions.

A Derived Formation Readiness result SHALL never be sufficient by itself to create a Formation.

#8.9 Activity and Outcome

Tests SHALL demonstrate that recording Activity does not automatically create Outcome. Outcome must preserve affected Subject, evidence or evaluation context, time, and provenance appropriate to its domain.

This proves that execution and consequence remain independent concepts.

#9. Protocol Conformance

#9.1 Envelope Tests

Protocol tests SHALL verify Actor, Principal or actsFor, Subject, purpose, operation identity, semantic environment, correlation, and applicable expected revision.

Missing fields SHALL be rejected when their absence prevents the operation from being interpreted or authorized correctly.

#9.2 Operation Tests

For every operation an implementation declares as supported, tests SHALL include valid, semantically invalid, unauthorized, lifecycle-invalid, and unsupported-context cases where applicable.

The core test suite SHOULD cover:

DESCRIBE
OBSERVE
OFFER
SEEK
RELATE
CLAIM
ASK
EVALUATE
PROPOSE
COMMIT
ACT
ATTEST
DISCLOSE
LEARN
REVOKE

A particular participant node may expose only a subset.

#9.3 Authority Tests

The harness SHALL demonstrate that authentication and authority are distinct. An authenticated DigitalAgent with permission to ASK and DISCLOSE but not COMMIT must receive an authority failure when attempting a Commitment.

Changing the HTTP role or possession of a valid access token SHALL not bypass canonical Delegation semantics.

#9.4 Idempotency Tests

Consequential operations SHALL be retried deliberately. The second execution of the same operation identity and semantic payload must not create duplicate canonical effects.

The harness SHALL also verify that reuse of the same operation identity with a different payload results in explicit conflict.

#9.5 Protocol Result Tests

Tests SHALL distinguish:

APPLIED
ALREADY_APPLIED
RETURNED
NO_CHANGE
REJECTED
UNAUTHORIZED
DENIED
CONFLICT
NOT_FOUND
UNAVAILABLE
INDETERMINATE
UNSUPPORTED

Transport status codes MAY differ, but the semantic result must remain observable.

#9.6 Unavailability Test

A required source SHALL be made unavailable during an ASK or reconciliation operation. The implementation must return UNAVAILABLE or equivalent semantics rather than manufacturing a negative domain answer.

This requirement applies particularly to Capacity, certification, Evidence, and other consequential state.

#10. Runtime Conformance

#10.1 Persistence Contract

The Canonical Repository SHALL pass a reusable contract suite independent of the selected database implementation. Replacing PostgreSQL with another conformant persistence engine, for example, should not require changing canonical behavior tests.

The contract must cover identity, mutation, revision, history, atomicity, reference integrity, idempotency support, and recovery.

#10.2 Operation Journal

Tests SHALL demonstrate that consequential operation disposition survives restart sufficiently to prevent duplicate effects after uncertain client retry.

The Runtime must distinguish operation history from the canonical objects affected by those operations.

#10.3 Change Journal

Canonical mutation SHALL produce the required Change Records or equivalent reliable propagation state. Tests must demonstrate that projection consumers can continue after restart without losing committed canonical changes.

Change Records SHALL remain distinct from modeled domain Events.

#10.4 Projection Rebuild

At least one significant Projection SHALL be deleted completely during acceptance. The Runtime must rebuild it from authoritative state and history and demonstrate semantic equivalence for the queries defined by that projection.

Suitable candidates include:

Relationship Graph
Capability Discovery Index
Biography Projection
Material Provenance Projection

This proves that the Projection is disposable.

#10.5 Biography Reconstruction

The Biography Builder SHALL construct an ordered history for at least:

one Organization
one Relationship
one Formation
one Material

Historical events must remain visible after current state changes, while current-state queries must not treat historical Capacity or expired Assertions as current.

#10.6 Recovery

The Runtime SHALL be stopped during an active scenario and restarted. After restart it must recover canonical state, idempotency information, required history, active coordination context, projection checkpoints, and pending work necessary to continue safely.

Recovery SHALL not create duplicate Commitments or lose accepted canonical state.

#11. Federation Conformance

#11.1 Node Isolation

Reference nodes SHALL be sufficiently isolated to prove that federation clients cannot read each other's private databases, object stores, internal APIs, or private Evidence directly.

The only authorized path between independent authority domains is through declared RSM or connector interfaces.

#11.2 Discovery Isolation

A node SHALL expose discovery-safe projection state separately from protected canonical state. A private laboratory report, exact farm boundary, internal financial information, or confidential Capacity detail SHALL not appear in public discovery merely because the underlying Subject is discoverable.

#11.3 Semantic Compatibility

Federation tests SHALL include two nodes with compatible semantic environments and at least one deliberately incompatible case.

The incompatible case must fail explicitly rather than allowing silent interpretation under the wrong Domain Pack or Predicate semantics.

#11.4 Stale Projection Test

The harness SHALL intentionally create stale projected Capacity or another consequential field. Before a Formation or comparable consequential transition is established, the Runtime must reconcile the relevant state with its authoritative node.

If authoritative state has changed, affected Derived reasoning SHALL be invalidated or recomputed.

#11.5 Node Failure Test

One authoritative node SHALL be made unavailable while cached discovery state remains accessible.

The expected semantics are:

authoritative state: UNAVAILABLE
cached state: visible with timestamp and provenance
consequential use: prohibited when current authority is required

The Runtime SHALL NOT replace unavailable state with zero, false, empty, or expired unless the authoritative semantics actually establish that value.

#11.6 Selective Disclosure Test

An authorized requester and an unauthorized requester SHALL request the same protected state. The authorized context must receive the appropriate purpose-bounded projection, while the unauthorized request must fail or return a less precise permitted representation.

This test SHOULD include at least one case involving Evidence or precise Place.

#11.7 Federated Commitment Test

Two or more independent nodes SHALL create their own canonical Commitments as part of one Formation process.

The test must demonstrate that no shared central service writes those Commitments directly into participant canonical stores.

#11.8 Partial Failure Test

A multi-node coordination attempt SHALL experience partial success and one remote failure. Successfully accepted canonical state must remain intact while the failed step remains explicit and recoverable.

The implementation SHALL not pretend a global rollback occurred when independent authorities have already committed legitimate state.

#12. Connector and Agent Conformance

#12.1 Connector Identity Mapping

The reference Connector SHALL demonstrate deterministic mapping between an external-system identifier and an RSM canonical identity.

The mapping must preserve provenance and must not rely solely upon name similarity.

#12.2 Connector Semantic Mapping

At least one external field SHALL require semantic transformation into RSM rather than simple field renaming. The mapping must be versioned or otherwise traceable so that a later mapping change can be distinguished from historical semantics.

#12.3 Connector Mutation Boundary

An external-system update SHALL enter canonical RSM state only through a conformant canonical operation or equivalent acceptance boundary.

Direct SQL insertion or repository bypass SHALL fail the connector conformance test even if the resulting record is structurally valid.

#12.4 Outbound Execution

At least one RSM ACT or comparable authorized operation SHALL cause an action in the reference external system. Transport acceptance and external execution must produce separately inspectable states or receipts.

A successfully delivered request SHALL not be interpreted automatically as completed external Activity.

#12.5 DigitalAgent Authority

The reference DigitalAgent SHALL receive a Delegation permitting some operations and prohibiting another consequential operation.

The agent must successfully perform the permitted behavior and fail the prohibited operation without acquiring additional authority merely because it has technical access to the Runtime.

#12.6 Derived Reasoning Provenance

The Reference Formation Reasoner SHALL identify the canonical or authorized projected inputs used to construct each consequential Derived artifact.

Changing one input SHALL allow the test harness to identify at least one Derived artifact whose validity is affected.

#13. Golden Scenario Suite

#13.1 Golden Scenario A — Direct Existing Capability

The first scenario demonstrates the simplest complete coordination path. A buyer expresses an Intent and DemandExpression that can be satisfied using existing producer and processor Capability and available Capacity.

The scenario SHALL progress through:

Intent
→ Discovery
→ Candidate Configuration
→ Evaluation
→ Commitments
→ Formation
→ Activity
→ Observation
→ Outcome
→ Biography

Acceptance requires that Candidate Configuration remain Derived, Commitments require authority, Formation not exist before establishment, and Outcome remain distinct from both Intent and Activity.

#13.2 Golden Scenario B — Gap and Pathway Formation

The second scenario demonstrates the distinctive outcome-forming behavior of RSM. Existing Capability or Capacity is deliberately insufficient to satisfy the Intent.

The Reference Formation Reasoner must identify a Gap, construct a dependency structure, and produce a Pathway involving at least one condition that must change before Formation becomes viable.

The scenario SHALL demonstrate:

Intent
→ Discovery
→ Candidate Configuration
→ Gap
→ Dependency
→ Pathway
→ Conditional Commitments
→ Gap Closure
→ Reconciliation
→ Formation

No derived artifact may substitute for participant Commitment.

#13.3 Golden Scenario C — Cross-Domain Semantic Composition

The third scenario proves that RSM is not an agriculture-specific ontology. The scenario SHALL use Concepts from at least three Domain Packs while preserving one shared Core.

A suitable case may combine:

rsm:agriculture/*
rsm:food/*
rsm:water/*
rsm:finance/*

The same Subjects may carry multiple Domain Types without identity duplication, and semantic round trip must preserve those types.

#13.4 Golden Scenario D — Material Transformation and Provenance

The fourth scenario SHALL follow at least one Material through transformation:

Seed or Crop Material
→ Harvested Material
→ Grain Lot
→ Processed Material
→ Food Ingredient

Each semantically distinct Material requiring independent provenance shall retain its own identity, while derived-from or equivalent lineage relationships preserve transformation history.

The scenario must demonstrate that Observation, Evidence, certification, or other state can attach to the appropriate Material stage rather than only to one generic product object.

#13.5 Golden Scenario E — Authority and Selective Disclosure

The fifth scenario SHALL demonstrate that identity, authentication, agency, authority, and disclosure remain separate.

An authorized Actor shall receive a protected projection or perform an allowed operation, while an authenticated but unauthorized Actor must fail. The test must include a DigitalAgent or delegated representative.

#13.6 Golden Scenario F — Stale Federation and Reconciliation

The sixth scenario SHALL deliberately place a stale Capacity or similar consequential value in federated discovery. The authoritative node must later return a different current value.

Before Formation establishment, reconciliation must detect the change, invalidate affected Derived reasoning, and produce a revised Configuration, Gap, Pathway, or readiness result as appropriate.

Historical reasoning must remain inspectable rather than being rewritten.

#13.7 Golden Scenario G — Failure and Recovery

The seventh scenario SHALL interrupt an active outcome-forming cycle by stopping one Runtime or federation node and restarting it.

The system must recover authoritative state, avoid duplicate consequential operations, preserve completed Commitments, and continue the scenario after availability is restored.

The failure period must be represented as unavailability rather than false domain state.

#13.8 Golden Scenario H — Outcome and Learning Loop

The final scenario closes the living-system loop. Completed Activity produces Observations, Evaluations, and canonical Outcomes that update Biography.

A later Intent must be able to use relevant historical information as context while still reconciling any state whose current value matters.

The complete loop is:

The scenario proves that RSM behaves as a living, learning Model rather than a one-time workflow.

#14. Scenario Trace and Explainability

#14.1 Scenario Trace

Every golden scenario SHALL generate a deterministic or semantically stable scenario trace showing the major canonical, derived, authority, federation, and outcome transitions.

An illustrative trace is:

[01] Intent admitted canonically
[02] DemandExpression admitted
[03] Discovery projection queried
[04] Authoritative Capacity requested
[05] Candidate Configuration derived
[06] Capacity Gap derived
[07] Pathway derived
[08] Buyer Commitment proposed
[09] Buyer Commitment canonically established
[10] Processor Commitment established
[11] Formation readiness derived
[12] Consequential state reconciled
[13] Formation canonically established
[14] Activities recorded
[15] Observations recorded
[16] Outcome evaluated and admitted
[17] Biography rebuilt

The trace SHALL distinguish canonical transitions from derived reasoning and projection access.

#14.2 Explainability

Derived reasoning used by golden scenarios SHALL expose the external factual inputs, semantic rules, assumptions, dependencies, source versions, and conclusions necessary to understand why the artifact was produced.

Conformance does not require disclosure of hidden model chain-of-thought. It requires an inspectable derivation boundary.

#14.3 Provenance Inspection

The test harness SHALL be able to start from a canonical Outcome, Commitment, Formation, or Derived Configuration and navigate backward to the material inputs, operations, authority decisions, or source projections that contributed to it where those links are normatively required.

This creates a practical proof that provenance is operational rather than decorative metadata.

#15. Fault-Injection and Negative Conformance

#15.1 Purpose

A robust RSM implementation must remain semantically correct when inputs, authorities, nodes, projections, and infrastructure behave badly. Fault injection is therefore a mandatory part of full conformance rather than an optional resilience exercise.

#15.2 Required Fault Classes

The full conformance harness SHALL intentionally exercise conditions including:

invalid Concept reference
wrong foundational kind
invalid lifecycle transition
missing provenance
stale expected revision
duplicate operation
idempotency-key payload conflict
expired Delegation
unauthorized COMMIT
policy-denied DISCLOSE
unreachable authoritative node
stale consequential projection
semantic-environment incompatibility
broken canonical reference
connector execution failure
projection corruption
runtime restart

The expected result must distinguish semantic rejection, authority failure, policy denial, conflict, unavailability, and infrastructure failure.

#15.3 No Semantic Fabrication

Fault handling SHALL never make the system appear more certain than it is. In particular, unavailability must not become zero Capacity, an unresolved identity must not become a new Subject automatically, and missing Evidence must not become a failed Predicate unless the Predicate explicitly defines absence that way.

The negative test suite should treat these conversions as severe conformance failures.

#16. Conformance Gates

#16.1 Gate A — Semantic Integrity

Gate A passes when the governed context, Core vocabulary, foundational kinds, Concept references, Domain Packs, semantic categories, SHACL or equivalent validation, and semantic round-trip tests are green.

No later gate can compensate for a semantic failure at Gate A.

#16.2 Gate B — Canonical Integrity

Gate B passes when canonical identity, revisions, relationships, lifecycle, provenance, Capability and Capacity, epistemic distinctions, Commitment, Formation, Activity, and Outcome satisfy their conformance suites.

The category firebreak between Canonical, Derived, Operational, and Projection must be executable rather than documentary.

#16.3 Gate C — Protocol Integrity

Gate C passes when the declared protocol operations execute correctly across valid, invalid, unauthorized, denied, idempotent, conflicting, unavailable, indeterminate, and unsupported conditions.

Actor, Principal, actsFor, purpose, authority, operation identity, and receipt semantics must be demonstrably enforced.

#16.4 Gate D — Runtime Integrity

Gate D passes when canonical persistence, operation journal, canonical change propagation, semantic resolution, authority, policy, projections, Biography, discovery, restart recovery, and projection rebuild operate together.

Deleting a disposable projection must not destroy canonical meaning.

#16.5 Gate E — Federation Integrity

Gate E passes when multiple independently governed nodes can discover and interact through RSM interfaces while preserving local canonical authority.

The gate requires successful isolation, selective disclosure, reconciliation, semantic compatibility, node unavailability, and federated Commitment tests.

#16.6 Gate F — Connector and Agent Integrity

Gate F passes when at least one external system participates through a Connector and at least one DigitalAgent operates through bounded Delegation.

Neither Connector nor Agent may bypass canonical mutation, authority, policy, or provenance boundaries.

#16.7 Gate G — Derived Reasoning Integrity

Gate G passes when the Reference Formation Reasoner can create inspectable Candidate Configurations, Gaps, Dependencies, Pathways, Recommendations, and Formation Readiness while preserving category DERIVED.

The reasoner SHALL be unable to create canonical Commitment or Formation without the appropriate protocol and authority boundary.

#16.8 Gate H — End-to-End Outcome Formation

Gate H passes when Golden Scenarios A through F execute from Intent through Formation and consequential reconciliation while preserving all lower-level invariants.

At least one scenario must demonstrate formation from existing Capacity and another must require a Gap and Pathway.

#16.9 Gate I — Reality, Recovery, and Learning

Gate I passes when Activity, Observation, Outcome, Biography, node failure, restart recovery, projection rebuild, adaptation, and subsequent Intent all execute successfully.

This gate demonstrates that the Model survives contact with both real-world consequence and operational failure.

#16.10 Gate J — Full RSM Reference Conformance

Gate J passes only when Gates A through I pass from a clean environment using the documented verification command or equivalent reproducible process.

Gate J is the definition of Full RSM Reference Conformance v2.0.

#17. Continuous Conformance

#17.1 Conformance in CI

Conformance SHALL not be treated as a certification exercise performed only before release. The reference implementation SHOULD execute applicable conformance suites continuously in CI.

Changes affecting semantic artifacts, canonical object behavior, protocol operations, runtime boundaries, or federation SHALL rerun the relevant lower-level suites automatically.

#17.2 Semantic Diff

Changes to governed JSON-LD context, vocabulary, shapes, Domain Packs, Predicates, protocol schemas, or golden fixtures SHOULD produce a reviewable semantic diff.

A build that changes semantic meaning without a visible specification or artifact change should be treated as suspicious.

#17.3 Golden Fixture Updates

Golden fixture regeneration SHALL require an explicit developer action. CI SHALL compare live output against committed expected fixtures and fail when behavior changes unexpectedly.

Automatic snapshot replacement would eliminate the fixture's value as a conformance boundary.

#17.4 Dependency Upgrades

Infrastructure dependency upgrades SHOULD rerun complete contract suites for the affected ports. Changing database, JSON-LD, RDF, serialization, graph, or messaging libraries SHALL not be assumed semantically harmless.

The tests exist to prove that infrastructure replacement did not alter RSM meaning.

#18. Reproducibility and Build Contract

#18.1 Clean Environment

Full conformance SHALL be executable from an empty or freshly initialized persistent environment using documented commands.

No manual database edits, developer-only secrets, hidden seed operations, or undocumented cloud state may be required.

#18.2 Deterministic Initialization

Schema migration, governed semantic artifact loading, reference identities, fixtures, and scenario seed data SHOULD initialize deterministically.

Environment-specific credentials and cryptographic material may vary, but they SHALL not alter expected semantic results.

#18.3 One Verification Entry Point

The Reference Implementation SHOULD expose one documented top-level verification command conceptually equivalent to:

make verify

or:

rsm verify --full

The exact command is implementation-specific. It must orchestrate all required lower-level gates and return non-zero or equivalent failure status when any mandatory conformance requirement fails.

#18.4 Verification Report

A full run SHOULD produce a compact machine-readable and human-readable report containing:

RSM version
Semantic Environment
Domain Packs
Gate results
Test counts
Golden scenario results
Failed invariants
Projection rebuild result
Federation result
Recovery result
Final conformance status

This report becomes the evidence supporting a conformance claim.

#19. Reference Domain

#19.1 Purpose

The primary reference domain SHOULD remain a regional regenerative grain scenario because it exercises agriculture, food processing, testing, finance, logistics, ecological state, Material transformation, multi-party Commitment, and Outcome Formation without requiring excessive domain complexity.

The reference domain exists to exercise RSM architecture rather than to define RSM itself.

#19.2 Required Participants

The scenario SHOULD contain enough independently governed Subjects to exercise federation meaningfully, including producer, processor, buyer, Evidence provider, and at least one additional supporting function such as finance or logistics.

A richer scenario MAY add certifier, conservation organization, Community, or watershed Subjects when useful.

#19.3 Ecological Subject

At least one LivingSystem SHALL participate as a Subject of Observation and Outcome rather than only as metadata attached to an Organization.

This proves that RSM's ecological semantics survive implementation.

#19.4 Material Lineage

At least one Material transformation SHALL be represented in the reference domain. The resulting provenance chain must survive through projection and Biography.

This prevents the reference system from becoming exclusively actor-centric.

#20. Diagnostics and Conformance Evidence

#20.1 Semantic Diagnostics

The verification harness SHOULD emit structured diagnostics for failures such as:

RSM-SEM-*
RSM-CAN-*
RSM-PROTO-*
RSM-RUN-*
RSM-FED-*
RSM-CONN-*
RSM-GOLD-*

Stable diagnostic families make failures easier to interpret and allow CI to distinguish architectural regressions from incidental test failures.

#20.2 Diagnostic Content

A diagnostic SHOULD include enough information to identify:

code
severity
specification area
object or operation reference
failed invariant
observed state
expected semantic condition
suggested remediation where appropriate

Diagnostics SHALL avoid leaking protected data merely to explain failure.

#20.3 Conformance Evidence Bundle

A release claiming Full RSM Reference Conformance SHOULD produce an evidence bundle containing relevant verification reports, semantic artifact versions, golden-scenario traces, fixture digests, and environment information.

The evidence bundle allows another party to inspect what was actually tested rather than relying upon an unsupported conformance label.

#21. Definition of Done

#21.1 Functional Completion

The Reference Implementation is functionally complete when every mandatory golden scenario runs successfully from a clean environment and all required gates pass.

Successful execution must expose more than final API responses. A reviewer must be able to inspect canonical state, Derived reasoning, protocol receipts, authority decisions, federation interactions, Commitments, Formation progression, Activity, Observations, Outcomes, and resulting Biography.

#21.2 Semantic Completion

The implementation is semantically complete when no acceptance scenario requires violating the distinctions established by the normative RSM specifications.

In particular, the implementation SHALL NOT require:

Subject = Actor
Person = Organization
Domain Type = Foundational Kind
Capability = Capacity
Configuration = Formation
Recommendation = Commitment
Activity = Outcome
Claim = Evidence
Evidence = Assertion
Derived = Canonical
Projection = Authority
Unavailable = False
Historical State = Current State

If the system requires one of these shortcuts to make the scenarios work, RSM has not been correctly realized.

#21.3 Architectural Completion

The implementation is architecturally complete when canonical semantics remain independent of physical storage and transport, projections are disposable, nodes can participate through federation, external systems can participate through connectors, agents remain authority-bounded, and reasoning systems operate on authorized RSM state rather than privileged database access.

Infrastructure may remain intentionally simple. Architectural boundaries may not.

#21.4 Federation Completion

Federation is complete when independently governed nodes can discover one another, exchange purpose-bounded projections, reconcile consequential state with authoritative sources, maintain private Evidence, continue safely through node failure, and create coordinated Formations without central ownership of participant canonical state.

A demonstration in which every participant secretly reads and writes one shared application database does not satisfy this requirement.

#21.5 Recovery Completion

Recovery is complete when the Runtime can restart during an active scenario, preserve committed canonical state, prevent duplicate consequential effects, restore required processing state, and rebuild disposable projections.

A system that works only while one uninterrupted process remains alive is not a complete RSM Runtime.

#21.6 Full Completion

Full RSM Reference Conformance is achieved only when Gate J passes and the resulting evidence bundle demonstrates the complete chain:

Every transition must remain inspectable and preserve the authority and semantic category appropriate to it.

#22. What the Reference Implementation Must Prove

#22.1 RSM Is More Than a Schema

The Reference Implementation must prove that RSM's distinctions survive execution. A beautifully normalized schema that allows unauthorized action, treats projections as authority, or collapses Activity into Outcome does not realize the Model.

Conformance therefore measures behavior, not aesthetic similarity to the documentation.

#22.2 RSM Is More Than a Graph

The implementation must prove that Relationships have lifecycle and history, Capacity can become stale, authority affects action, Evidence affects evaluation, and a graph path does not become a Formation merely because an algorithm discovered it.

Graph infrastructure may support RSM, but connectivity alone does not constitute RSM.

#22.3 RSM Is More Than Federation Syntax

Two nodes exchanging JSON-LD do not establish meaningful federation if they disagree about semantic environment, cannot identify authoritative sources, leak private Evidence, or interpret unavailable state as false.

Federation Conformance therefore tests meaning, authority, disclosure, reconciliation, and failure—not merely network connectivity.

#22.4 RSM Is More Than AI Coordination

An intelligence system may discover excellent Configurations and Pathways while still failing RSM if it can silently create institutional Commitments or canonical Assertions.

The Reference Implementation must prove that intelligence expands possibility without acquiring authority merely by being intelligent.

#23. Final Conformance Principle

#23.1 Architecture Becomes Real Through Refusal

The strongest proof of RSM is not simply that valid scenarios succeed. It is that invalid transitions fail at the correct boundary.

A conformant system must refuse to treat a Person as an Organization, Capability as Capacity, Configuration as Formation, recommendation as Commitment, inference as Assertion, projection as authority, or unavailable state as false.

Those refusals are what preserve the meaning of the Model under real operational pressure.

#23.2 Conformance as an Executable Contract

The five normative RSM specifications describe a living, federated, outcome-forming ecology. This specification converts that architecture into an executable contract that can be tested repeatedly against any implementation.

An implementation is therefore genuinely RSM not because it uses RSM vocabulary, runs an RSM-branded application, or stores data in an RSM-shaped schema. It is RSM when its observable behavior preserves the identities, semantic distinctions, authority boundaries, protocol transitions, federation rules, provenance, and learning loop established by the Model.

#23.3 Governing Principle

The final conformance principle is:

An implementation is RSM only when the Model's distinctions remain true under execution, federation, failure, recovery, and change.

The Reference Implementation exists to prove that standard. The conformance harness exists to prevent future implementations from weakening it, and the golden scenarios exist to demonstrate that preserving semantic discipline does not prevent the system from forming real coordinated outcomes.

Together, the normative specifications and executable conformance suite establish RSM as infrastructure rather than merely an architectural idea.