OpenRSN Reference Implementation & Conformance Specification

#1. Purpose and Conformance Objective

#1.1 Purpose

The OpenRSN 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 OpenRSN Reference Implementation & Conformance Specification closes that gap. It defines the minimum executable evidence required to demonstrate that an implementation preserves OpenRSN semantics and behavior rather than merely adopting OpenRSN terminology or reproducing its diagrams.

Conformance under this specification is conformance to the OpenRSN Model and its protocol, runtime, and federation behavior. Supporting AI agents, or any other cognitive capability within OpenRSN (Concept Paper §19.6), does not by itself make an implementation conformant, and neither does use of the OpenRSN name. Agents are tested here only as consumers and Actors subject to the same authority and admission boundaries as any other participant (Gate F). Agent-specific conformance requirements, if any are adopted, will be specified and governed separately; this edition defines none. This paragraph is informative.

#1.2 Central Acceptance Question

The principal acceptance question is:

Can an implementation represent, mutate, exchange, federate, observe, and reconstruct OpenRSN 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 OpenRSN Reference Implementation is the minimum complete executable system maintained as a known-good realization of the normative OpenRSN 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 OpenRSN 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 OpenRSN 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
OpenRSN 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 OpenRSN participant must operate a complete federated Runtime. A laboratory connector, for example, may expose only a limited protocol surface, while an OpenRSN infrastructure provider may implement the complete canonical and federation stack.

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

#3.2 Semantic Conformance

A Semantic Conformant implementation demonstrates that it can interpret and preserve OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 Derived Artifact Producer

The reference environment SHALL include a deterministic Derived Artifact Producer capable of demonstrating the Derived reasoning boundary. It MAY be a fixture replayer that submits pre-computed artifacts, or a reasoner. It need not represent any intelligence architecture and SHALL NOT be treated as part of canonical OpenRSN authority.

OpenRSN Core conformance tests the category, provenance, and invalidation boundary of Derived artifacts. It does not test the algorithms that synthesize them. Outcome-formation and intelligence systems own those algorithms (Canonical Model & Protocol §29.4). An implementation that synthesizes Gaps and Pathways MAY additionally claim the Outcome Formation Application Profile, maintained with the OFN application documents (docs/ofn/ofn-application-conformance-profile.md). That profile is not required for any OpenRSN Core conformance level. (Edition 2.1.0; the 2.0 text required a Reference Formation Reasoner that produced these artifacts.)

The Producer must be capable of supplying, 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

An intelligence application such as Wellzai MAY supply the Derived Artifact Producer's artifacts, but OpenRSN conformance SHALL NOT depend upon Wellzai-specific algorithms, APIs, prompts, application state, or product architecture.

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

#4.4 Reference Connector

At least one participant SHALL operate through a Connector rather than through a native OpenRSN 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 OpenRSN-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 OpenRSN 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 OpenRSN'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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN 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 Derived Artifact Producer 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 OpenRSN. Existing Capability or Capacity is deliberately insufficient to satisfy the Intent.

The Derived Artifact Producer SHALL supply a Gap, a dependency structure, and a Pathway involving at least one condition that must change before Formation becomes viable. The implementation SHALL preserve their category, provenance, and invalidation, and SHALL require participant Commitments to close the Gap. Synthesizing the Gap and Pathway from the Intent is tested by the Outcome Formation Application Profile, not here. (Edition 2.1.0.)

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 OpenRSN 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 and invalidate affected Derived reasoning.

• The Derived Artifact Producer SHALL then supply a revised Configuration, Gap, Pathway, or readiness result, as appropriate, for the changed inputs.
• The implementation SHALL record the revised artifact as DERIVED, with provenance to its new inputs and to the invalidated artifact it replaces.
• Synthesizing the revised artifact is tested by the Outcome Formation Application Profile (OFN-C4), not here.

(Edition 2.1.0.)

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 OpenRSN 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 OpenRSN 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
unauthenticated consequential request
claimed actorRef not bound to the authenticated requester
self-asserted actsFor without AuthorityBasis
bearer-only credential on an authority-bearing operation
replayed proof or request signature
proof older than the freshness bound
proof bound to a different request
credential with the wrong audience
idempotent retry by a different Actor or Principal
authority or policy service unavailable during a consequential operation
authority state beyond its staleness bound while disconnected
pending proposal producing a protected side effect
semantic-environment incompatibility
broken canonical reference
connector execution failure
projection corruption
runtime restart

The expected result must distinguish semantic rejection, authentication failure, authority failure, policy denial, conflict, unavailability, pending review, and infrastructure failure. Cases for the authentication, replay, and fail-closed classes are specified as proposed conformance cases SEC-04- and SEC-05- in docs/architecture/RSM-SECURITY-VALIDATION-PLAN-V1.0.md. They become normative only when Documents 04 and 05 are adopted at editions 2.4.0 and 2.1.0 or later (RSM-GOV-002 §3; RSM-GOV-006). (Edition 2.1.0.)

#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 OpenRSN 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 supplied Candidate Configurations, Gaps, Dependencies, Pathways, Recommendations, and Formation Readiness remain inspectable and DERIVED, carry their source references, and are invalidated when their inputs change. (Edition 2.1.0: Gate G tests the boundary, not the producing algorithm.)

The Derived Artifact Producer 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. Another must exercise a supplied Gap and Pathway with conditional Commitments.

#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.1.

Migration from v2.0 (edition 2.1.0):

• A v2.0 conformance result remains a valid v2.0 result. It is not, by itself, a v2.1 result.
• The evidence for Gates G and H obtained under v2.0 with a synthesizing reasoner remains valid under the amended Gates G and H. Those gates now test the boundary, which such a reasoner also satisfies.
• To claim v2.1, an implementation SHALL also pass the twelve fault classes added to §15.2 in edition 2.1.0. They require the behaviour of Canonical Model & Protocol §18.8 and Runtime & Federation §17.6. They are new obligations, and a v2.0 implementation does not meet them unless it already behaves that way.
• The synthesis itself is recognized only through the Outcome Formation Application Profile.

#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 OpenRSN 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:

OpenRSN 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 OpenRSN architecture rather than to define OpenRSN 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 OpenRSN'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 OpenRSN 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, OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN Is More Than a Schema

The Reference Implementation must prove that OpenRSN'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 OpenRSN 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 OpenRSN, but connectivity alone does not constitute OpenRSN.

#22.3 OpenRSN 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 OpenRSN Is More Than AI Coordination

An intelligence system may discover excellent Configurations and Pathways while still failing OpenRSN 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 OpenRSN 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 OpenRSN 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 OpenRSN not because it uses OpenRSN vocabulary, runs an OpenRSN-branded application, or stores data in an OpenRSN-shaped schema. It is OpenRSN 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 OpenRSN 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 OpenRSN as infrastructure rather than merely an architectural idea.

#Errata