RSM Runtime & Federation Architecture v2.0

#1. Purpose and Architectural Position

#1.1 Purpose

The Regenerative Systems Model is designed for an ecology in which authoritative state does not naturally belong in one application or one database. A farm may remain authoritative for its operational Capacity, a laboratory for its Observations, a certifier for its Assertions, a Community for its membership, an Organization for its Delegations, and a Formation for the Commitments and Activities governed within its scope.

The RSM Runtime & Federation Architecture defines the machinery that allows these independently governed sources to participate in one interoperable Model. It translates the semantics established by the preceding RSM specifications into operational boundaries for persistence, identity, authorization, event processing, semantic resolution, projections, federation, disclosure, reconciliation, and external-system participation.

The architecture is designed around a central principle:

RSM federation creates mutual intelligibility without requiring central ownership of authoritative state.

#1.2 Governing Question

The governing question of this specification is:

How can independently governed systems participate in a shared Regenerative Systems Model while preserving canonical authority, semantic fidelity, provenance, privacy, operational autonomy, and the ability to coordinate across boundaries?

The answer cannot be a single distributed database pretending that all participants share one owner. RSM instead requires explicit authority boundaries and protocols through which state can be described, requested, disclosed, committed, reconciled, and projected without confusing a copy with its source.

#1.3 Architectural Role

The Runtime implements the operational consequences of the preceding specifications:

The Runtime SHALL preserve the distinctions established above rather than redefining them for implementation convenience.

#1.4 Non-Goals

This specification does not prescribe one cloud provider, database, graph engine, message broker, programming language, deployment topology, API framework, or agent platform. A small local installation and a geographically distributed federated network may conform to the same architecture while using different infrastructure.

The Runtime also does not own Outcome Formation intelligence. Systems such as Wellzai may discover, configure, evaluate, identify gaps, construct pathways, or recommend actions, but they operate through RSM-authorized state and protocol boundaries rather than becoming privileged owners of participant data.

#2. Runtime Principles

#2.1 Authority Before Location

Authority is a semantic property, not a consequence of where data happens to be stored. A record copied into a central database does not become authoritative merely because the database is operationally convenient.

The Runtime SHALL therefore know, directly or through resolvable provenance, which authority boundary governs consequential canonical state. A local replica, search index, graph projection, vector representation, cached response, or materialized Biography remains subordinate to the authority from which it was derived.

#2.2 Federation Before Centralization

RSM MAY be deployed centrally when one authority legitimately governs the relevant state. The architecture SHALL nevertheless remain federatable and SHALL NOT depend upon all Subjects surrendering authoritative state to a universal central database.

Federation allows independently governed nodes to expose controlled RSM interfaces while retaining their internal systems and governance. Shared infrastructure may assist with discovery, routing, semantic distribution, or public projections, but shared infrastructure SHALL NOT silently become the universal system of record.

#2.3 Canonical State Before Projection

Canonical state and authoritative history form the durable operational foundation. Search indexes, maps, graph projections, Biography views, analytics tables, vector indexes, recommendation caches, and UI read models are replaceable projections.

The Runtime SHALL be able to rebuild projections from authoritative state and history where the projection is defined as reconstructable. An implementation that can recover only from its search index or graph projection has allowed the projection to become an undeclared system of record.

#2.4 Explicit Uncertainty and Unavailability

A federated system must represent what it does not know. Failure to contact an authoritative source does not imply that Capacity is zero, that a certification has expired, that Evidence does not exist, or that a participant refused an action.

The Runtime SHALL distinguish unavailable, unresolved, unauthorized, indeterminate, absent, stale, and negative state wherever those distinctions affect meaning or consequential processing.

#2.5 Local Atomicity, Federated Coordination

Strong atomic transactions are appropriate inside a single authority boundary. They SHALL NOT be assumed automatically across independently governed RSM nodes.

Cross-node coordination should use explicit RSM protocol operations, canonical Commitments, idempotent receipts, reconciliation, and state transitions rather than attempting to disguise federation as one global ACID transaction.

This distinction allows failures to remain inspectable and prevents one unavailable participant from corrupting another participant's authoritative state.

#2.6 Replaceable Infrastructure

Canonical semantics SHALL not depend upon proprietary behavior of a particular persistence engine, graph database, vector store, broker, or cloud service. Runtime components SHOULD depend upon explicit contracts that can be implemented by alternative infrastructure.

The architecture may optimize aggressively at deployment time, but optimization SHALL not become ontology.

#3. Runtime Architecture

#3.1 Core Runtime Components

A complete RSM Runtime consists conceptually of the following cooperating capabilities:

These are logical responsibilities rather than mandatory independent services. A small implementation may host several responsibilities within one process while preserving their interfaces and dependency direction.

#3.2 Dependency Direction

Dependencies SHALL flow toward canonical and semantic authority rather than allowing infrastructure to define domain meaning.

The intended direction is:

Applications / Agents / Connectors
              ↓
       RSM Protocol Boundary
              ↓
        Runtime Services
              ↓
   Canonical + Semantic Contracts
              ↓
      Infrastructure Adapters

Canonical domain code SHALL NOT depend upon a particular database client, HTTP framework, vector database, graph engine, or application-specific intelligence system.

#3.3 Runtime Node

An RSM Runtime Node is a logically governed deployment capable of participating in RSM protocol and federation. A Node may represent one Organization, one Community, one service provider, several Subjects under a common authority boundary, or a shared hosting environment that preserves separate authority domains.

Node boundaries are operational and governance boundaries rather than foundational Subject kinds. An RSM Node SHALL therefore not be confused with an Organization or Participant merely because one Organization operates it.

#3.4 Authority Boundary

An Authority Boundary defines the scope within which a Runtime may admit or mutate particular canonical state. One Node may contain several authority boundaries if its architecture enforces them reliably.

For example, a regional platform may host canonical projections or delegated operational state for many farms while each farm remains independently authoritative for defined portions of its Capacity, Commitments, or private Evidence.

Hosting and authority SHALL remain distinct.

#4. Semantic Runtime and Identity Resolution

#4.1 Semantic Runtime

The Semantic Runtime resolves the governed semantic environment under which canonical objects and protocol operations are interpreted. It provides access to RSM Core vocabulary, the JSON-LD context, active Domain Packs, Concept definitions, semantic mappings, validation shapes, Predicate definitions, units, and compatibility metadata.

Consequential operations SHOULD be traceable to an identifiable Semantic Environment so that later inspection can determine which vocabulary and rules applied.

#4.2 Semantic Environment Activation

A Runtime MAY support several Semantic Environments simultaneously when federation or historical reconstruction requires them. Activation SHALL be deterministic and SHALL validate Domain Pack dependencies, Core compatibility, and conflicts before the environment becomes eligible for consequential processing.

A Runtime SHALL NOT silently load two incompatible definitions of the same governed RSM Concept.

#4.3 Historical Semantic Resolution

Canonical history may reference Concepts or Predicate versions no longer active for new operations. The Runtime SHOULD therefore retain or resolve historical semantic artifacts sufficiently to interpret prior canonical state.

Deprecating a Concept does not make historical state semantically unreadable.

#4.4 Identity Resolver

The Identity Resolver maps canonical RSM identities to their applicable authoritative context and distinguishes canonical identity from application-local identifiers. It may additionally maintain governed equivalence or mapping relationships to external identifiers.

The same Subject accessed through a connector, projection, protocol response, or federated query SHALL retain the same canonical identity where the source identity is known to be the same entity.

#4.5 Identity Mapping

External systems may identify one entity differently. Connectors MAY maintain mappings such as:

ERP customer 44821
        ↕
https://id.rsm.org/organization/01KORG

Farm management system parcel F-42
        ↕
https://id.rsm.org/place/01KFIELD

An identity mapping SHALL carry provenance and SHALL NOT merge two canonical Subjects merely because labels or attributes appear similar.

#4.6 Identity Resolution and Uncertainty

Entity resolution may sometimes be probabilistic. A probable identity match SHALL remain a Derived conclusion until an applicable authority or deterministic mapping establishes equivalence.

The Runtime SHALL NOT merge canonical identities on the basis of similarity scoring alone.

#5. Canonical Persistence and History

#5.1 Canonical Repository

The Canonical Repository provides the authoritative persistence boundary for canonical objects governed by the Runtime. It SHALL enforce the object-category and lifecycle distinctions established by the Canonical Model.

A generic document store MAY be used physically, but the repository contract must still prevent a Derived Configuration from being accepted as a canonical Formation or a projection from being written back as canonical state without the appropriate mutation operation.

#5.2 Persistence Model

A conformant implementation may use relational storage, append-oriented storage, document storage, graph storage, or combinations thereof. Physical persistence design SHALL preserve at minimum:

• canonical identity;
• revision;
• semantic kind;
• provenance;
• temporal state;
• lifecycle;
• references;
• semantic category; and
• reconstructable history where required.

Persistence convenience SHALL not collapse semantic distinctions.

#5.3 Local Transaction Boundary

Canonical changes occurring inside one authority boundary SHOULD use transactional semantics sufficient to preserve canonical invariants. An operation that creates several mutually dependent changes SHALL either commit the required state consistently or fail without leaving an invalid partial result.

The exact implementation may use database transactions, deterministic mutation plans, event-sourced commits, or another mechanism satisfying the same semantic property.

#5.4 Operation Journal

The Runtime SHOULD maintain an immutable or append-oriented Operation Journal containing the disposition of consequential protocol operations. The journal supports idempotency, auditability, recovery, and correlation without becoming a replacement for canonical objects themselves.

The journal SHOULD retain enough information to answer:

• which operation was attempted;
• who acted;
• for which Principal;
• which canonical objects were affected;
• which result was returned;
• which operation identifier governed idempotency; and
• when the operation was recorded.

#5.5 Canonical Change Journal

Canonical state changes SHOULD emit or append durable Change Records describing authoritative mutations. Change Records are infrastructure artifacts used to build projections, invalidate caches, notify subscribers, and support reconstruction.

They SHALL remain distinct from canonical domain Event objects.

The distinction is:

Domain Event
    something meaningful occurred in the modeled world

Canonical Change Record
    authoritative RSM state changed

Transport Message
    infrastructure carried information about that change

One domain Event may generate several Change Records or transport messages, while many canonical mutations may occur without representing domain Events.

#5.6 Transactional Publication

When canonical mutation and downstream change publication must remain consistent, the Runtime SHOULD use an outbox, journal, or equivalent mechanism ensuring that committed canonical state cannot permanently diverge from its required change notifications.

Infrastructure publication MAY be asynchronous. Canonical commitment SHALL not depend upon downstream projection systems being simultaneously available unless the applicable operation explicitly requires synchronous external confirmation.

#6. Authority, Policy, and Protocol Execution

#6.1 Operation Processor

The Operation Processor is the primary acceptance boundary for RSM protocol requests. It coordinates semantic validation, identity resolution, lifecycle validation, authority evaluation, policy, concurrency, idempotency, mutation planning, persistence, and receipt generation.

Applications and connectors SHALL use this boundary or an equivalent conformant path for ordinary canonical mutations.

#6.2 Execution Pipeline

A consequential operation should conceptually pass through:

The internal implementation may optimize this pipeline. Observable behavior SHALL preserve enough separation to explain why an operation was accepted or rejected.

#6.3 Authority Evaluator

The Authority Evaluator determines whether the authenticated Actor may exercise the requested operation on behalf of the stated Principal within the requested scope.

Authority evaluation may consider Delegation, governance position, statutory authority, Formation governance, direct ownership or control semantics, or another recognized AuthorityBasis.

The Runtime SHALL not infer authority merely from authentication or affiliation.

#6.4 Policy Evaluator

The Policy Evaluator decides whether an otherwise semantically valid and authorized operation is permitted under applicable policy. Policy may constrain operation, purpose, Subject, data sensitivity, Place, time, relationship state, role, quantity, or other domain context.

A policy decision SHOULD produce a traceable result identifying the applicable policy or rule set without exposing protected internal details unnecessarily.

#6.5 Determinism for Consequential Boundaries

Consequential authority, lifecycle, idempotency, and canonical mutation decisions SHOULD be deterministic for a given authoritative state snapshot and policy environment.

AI systems MAY assist with interpretation or recommendation, but nondeterministic model output SHALL NOT serve as the sole hidden mechanism deciding whether canonical authority exists.

#7. Projections, Biography, and Discovery

#7.1 Projection Architecture

A Projection is a non-authoritative representation derived from canonical, authorized remote, or other explicitly identified source state. Projections may be specialized for query performance, discovery, visualization, graph traversal, analytics, semantic search, or user experience.

Examples include:

Subject Profile Projection
Relationship Graph
Capability Index
Capacity Discovery Index
Network Map
Material Provenance View
Biography Timeline
Search Document
Vector Embedding Index
Outcome Dashboard

These artifacts MAY be materialized and heavily optimized while retaining semantic category PROJECTION.

#7.2 Projection Rebuild

A projection defined as reconstructable SHALL be rebuildable from its authoritative inputs. The Runtime SHOULD periodically prove this property through automated conformance or recovery tests.

Deletion of a search index, graph projection, or materialized Biography must not destroy authoritative RSM history.

#7.3 Projection Generation

A projection SHOULD preserve provenance sufficient to identify:

• source authorities;
• source revisions or checkpoints where material;
• generation time;
• semantic environment;
• purpose or audience where disclosure is bounded;
• freshness;
• projection version; and
• authorization scope.

A projection that combines several sources SHOULD retain enough lineage to identify which portions originated from which authority boundaries.

#7.4 Biography Builder

Biography is a governed projection over authoritative historical state. The Biography Builder reconstructs meaningful chronological or causal history for Subjects, Relationships, Materials, Instruments, and Formations.

A Biography MAY combine current state, historical revisions, domain Events, Activities, Commitments, Observations, Assertions, Outcomes, and other relevant canonical objects.

Biography SHALL not become an independently editable history.

#7.5 Purpose-Bounded Biography

Different purposes may justify different views of the same historical state. A buyer evaluating production Capability may receive prior fulfillment history while remaining unauthorized to inspect unrelated financial Evidence.

The Biography Builder SHALL therefore support policy- and purpose-bounded projections rather than assuming that historical inclusion implies universal disclosure.

#7.6 Discovery Index

Discovery is normally projection-based because querying every authority synchronously for every exploratory request would be inefficient and unnecessarily invasive. Nodes may therefore publish authorized discovery projections containing limited identity, Capability, domain types, broad Place, supported protocol operations, or other discovery-safe semantics.

A Discovery Index is not canonical authority. Consequential decisions must reconcile required state with the appropriate authoritative source.

#7.7 Search and Vector Systems

Full-text indexes, graph engines, embedding stores, vector databases, and machine-learning indexes MAY support discovery and reasoning. They SHALL be treated as projections or Derived infrastructure unless another specification explicitly establishes authoritative semantics.

Similarity does not create identity, authority, Commitment, or truth.

#8. Federation Architecture

#8.1 Federation Model

Federation connects independently governed RSM Nodes through common semantic and protocol boundaries. A federated deployment should allow each node to preserve local canonical authority while participating in discovery, query, disclosure, Commitment, Formation, and learning across network boundaries.

The architecture is:

The Discovery layer may help nodes find one another, but consequential interactions occur through the authority boundaries that own the relevant state.

#8.2 No Mandatory Central Node

RSM SHALL NOT require one central federation service to remain available for all node-to-node interactions. Deployments may use directories, registries, routing services, gateways, or peer discovery, but the architecture should not make one discovery operator the implicit owner of the network.

A deployment MAY centralize routing operationally while retaining federated authority semantically.

#8.3 Node Manifest

An RSM Node SHOULD expose or publish a minimal Node Manifest or equivalent federation descriptor containing enough information for compatibility and routing.

A manifest may describe:

nodeId: https://node.example.org/rsm
operatorRef: https://id.rsm.org/organization/01KPROCESSOR
rsmCoreVersion: 4.0
semanticEnvironments:
  - rsm-env:4.0/food-1.1
protocolOperations:
  - DESCRIBE
  - ASK
  - EVALUATE
  - COMMIT
  - DISCLOSE
interfaces:
  - rsm-protocol
discoveryScopes:
  - rsm:food/processing

The manifest SHOULD NOT expose private canonical state merely to advertise participation.

#8.4 Capability Manifest

Nodes MAY expose discovery-safe Capability Manifests describing Subjects, Capabilities, broad geographic applicability, protocol operations, or other information suitable for federation discovery.

A Capability Manifest is a Projection. Current Capacity, protected Evidence, precise Place, contractual terms, or other sensitive state SHOULD be excluded unless disclosure policy explicitly permits publication.

#8.5 Semantic Compatibility

Before consequential interaction, nodes must be able to determine whether they share sufficient semantic compatibility for the requested operation. Compatibility may require a common RSM Core version, compatible Domain Packs, supported Predicate versions, or agreed mappings.

Incompatibility SHALL be explicit rather than resolved through silent interpretation.

#8.6 Protocol Transport

Federation MAY carry RSM protocol operations through HTTP, message queues, event streams, local gateways, agent transports, secure peer channels, or other mechanisms.

Transport SHALL preserve:

• operation identity;
• Actor;
• Principal or actsFor;
• Subject;
• purpose;
• payload semantics;
• semantic environment;
• authority evidence where required;
• idempotency;
• result status; and
• correlation.

Transport-specific convenience SHALL not change protocol meaning.

#9. Authoritative Query and Reconciliation

#9.1 Discovery Versus Consequential State

Exploratory discovery MAY rely upon cached or indexed projections. Formation establishment, active Commitment, financial authorization, sensitive disclosure, or other consequential processing may require current authoritative confirmation.

The Runtime SHALL therefore distinguish discovery sufficiency from consequential sufficiency.

#9.2 Freshness

A federated projection SHOULD include freshness information sufficient to determine whether it remains suitable for its intended purpose.

Freshness is domain-dependent. A two-day-old Organization description may be entirely adequate for discovery, while two-day-old production Capacity may be unacceptable for a Commitment involving immediate delivery.

The Runtime SHALL not impose one universal freshness period.

#9.3 Reconciliation

Reconciliation rechecks material projected or cached state against the applicable authoritative source before a consequential transition that requires current authority.

For example:

Discovery projection:
    Processor Capacity = 4,500 tonnes
    observed 2029-03-12

Formation attempt:
    2029-03-18

Required action:
    reconcile with Processor authoritative node

Authoritative response:
    Capacity = 3,000 tonnes

Result:
    Configuration and Formation readiness must be re-evaluated

Reconciliation does not imply that the prior projection was erroneous. It establishes that the projection is no longer sufficient for the present consequential decision.

#9.4 Unavailable Authority

If an authoritative node cannot be contacted, the Runtime SHALL report the relevant authoritative state as unavailable rather than manufacturing a negative value.

For example:

Incorrect:
    processorCapacity = 0

Correct:
    authoritativeState = UNAVAILABLE
    cachedCapacity = 4,500 tonnes
    cachedAt = 2029-03-12
    consequentialUse = NOT_AUTHORIZED

An application may display cached state with clear qualification. It SHALL NOT silently use stale state as current authority when current authority is required.

#9.5 Conflict

When local projected state conflicts with authoritative remote state, authoritative state governs future consequential processing within that source's authority boundary. The conflict SHOULD invalidate or mark affected projections and derived artifacts for recomputation.

Historical projections remain valid records of what was previously known if their timestamps and provenance are preserved.

#9.6 Derived Artifact Invalidation

The Runtime SHOULD maintain enough derivation lineage to identify Derived artifacts affected by changed source state. A Candidate Configuration based upon withdrawn Capacity should not remain silently presented as current merely because the reasoning service has not been rerun.

Invalidation need not delete the Derived artifact. Historical reasoning may remain valuable when clearly marked as based upon superseded inputs.

#10. Cross-Node Coordination

#10.1 No Global Distributed Transaction Assumption

RSM federation SHALL NOT assume that independently governed nodes participate in one global database transaction. Such a requirement would make sovereignty dependent upon shared infrastructure and would be fragile across organizational boundaries.

Cross-node coordination instead uses canonical protocol operations and explicit state transitions.

#10.2 Commitment as Coordination Primitive

Commitment is a primary mechanism for turning federated intention into accountable coordination. Each authority records its own Commitment under its own governance and returns an idempotent receipt.

A Formation may then establish itself only when the applicable Commitments have reached the required states.

This architecture behaves more like a governed coordination protocol than a distributed table update.

#10.3 Conditional Commitments

Conditional Commitments allow participants to express obligations whose activation depends upon other conditions without requiring all nodes to commit atomically.

For example:

Buyer:
    commits demand if processing Capacity >= threshold

Processor:
    commits Capacity if financing becomes ACTIVE

Lender:
    commits financing if buyer demand becomes ACTIVE

The relevant intelligence system may reason about this dependency structure, but each authority controls its own canonical Commitment transition.

#10.4 Partial Failure

Federated operations may partially succeed. The Runtime SHALL preserve successful canonical changes and explicit failed or pending operations rather than pretending that an unreachable node participated.

Recovery can then continue through retry, reconciliation, alternate Pathway construction, or explicit withdrawal according to canonical semantics.

#10.5 Saga-Like Coordination

Implementations MAY use saga, orchestration, choreography, or another distributed coordination pattern. Infrastructure terminology is secondary to the RSM requirement that each consequential step remain attributable, idempotent, and semantically visible.

Compensating action SHALL use legitimate canonical operations such as REVOKE, withdrawal, supersession, or a new Commitment rather than directly rewriting historical state.

#11. Selective Disclosure and Data Sovereignty

#11.1 Progressive Disclosure

RSM federation is designed for progressive disclosure. A node may expose only enough information to become discoverable, disclose additional state during evaluation, reveal protected Evidence after an authorized request, and expose contractual details only when participants reach the applicable relationship state.

The Model therefore supports coordination without assuming global transparency.

#11.2 Disclosure Engine

A Runtime SHOULD provide a Disclosure Engine or equivalent policy boundary capable of producing purpose-bounded projections from canonical state.

Disclosure decisions may consider:

• Actor;
• Principal;
• purpose;
• Subject;
• relationship;
• role;
• sensitivity;
• Place precision;
• requested fields;
• applicable Consent;
• Delegation;
• policy; and
• time.

The result may be a filtered Projection rather than the canonical object itself.

#11.3 Precise and Broad Place

Location illustrates why disclosure belongs at runtime rather than inside foundational semantics. A farm may disclose a county or watershed for discovery while withholding an exact parcel boundary or precise coordinate from an unauthorized requester.

RSM SHALL therefore allow broad and precise Place projections to coexist without changing the underlying Subject identity.

#11.4 Evidence Disclosure

Evidence may contain confidential, proprietary, personal, regulated, or sensitive information. The Runtime MAY disclose a governed Assertion that criteria were satisfied without disclosing the underlying Evidence when policy permits such separation.

This allows a certifier or laboratory to establish a usable trust boundary without forcing all Evidence into public federation.

#11.5 Disclosure Receipt

Purpose-sensitive disclosures SHOULD produce auditable receipts recording the Actor, Principal, purpose, disclosure class, target, policy result, and time.

Audit records SHOULD avoid copying the protected content itself unless that content is required for audit or compliance.

#11.6 Data Ownership and Semantic Authority

RSM avoids treating every information relationship as a simplistic ownership question. Different systems may hold custody, processing rights, disclosure authority, authorship, or canonical authority over different aspects of the same Subject.

Runtime policy SHOULD preserve these distinctions rather than relying on one generic ownerId field to govern all access.

#12. Connectors and Existing Systems

#12.1 Connector Role

Most participants will not replace their operational systems merely to join RSM. A connector allows an existing ERP, farm-management system, laboratory platform, CRM, certification service, financial system, sensor platform, or other application to participate through RSM semantics and protocol.

A Connector is an adapter boundary, not a semantic shortcut.

#12.2 Connector Responsibilities

A conformant connector may need to:

• read authorized external state;
• map external identifiers to canonical RSM identities;
• map external concepts to governed RSM Concepts;
• preserve provenance;
• expose selected Capabilities or Capacity;
• transform external records into candidate canonical operations;
• receive authorized RSM operations;
• execute or forward actions to the external system;
• return execution results; and
• reconcile changes in either direction.

The connector SHALL not bypass RSM validation and authority merely because the external system considers its user trusted.

#12.3 Source Authority

A connector must identify whether the external source is authoritative for the state being projected. Reading a value from an ERP does not automatically make that ERP authoritative for every RSM interpretation of the value.

Authority mappings SHOULD therefore be explicit.

#12.4 Mapping Provenance

Connector mappings between external schemas and RSM semantics SHALL be versioned or otherwise traceable when changes can alter meaning.

A connector update that changes "processing_capacity" from daily to weekly interpretation, for example, is a semantic change requiring migration or transformation rather than a harmless code refactor.

#12.5 Inbound Canonicalization

Data imported through a connector SHALL become canonical only through the canonical mutation boundary. A connector may generate proposed canonical objects or protocol operations, but direct writes from external tables into canonical storage SHALL not be the ordinary integration mechanism.

This preserves validation, provenance, lifecycle, and authority.

#12.6 Outbound Action

When RSM requests action in an external system, the connector SHOULD return an execution receipt or result that can be correlated with the originating RSM operation.

Successful transmission is not necessarily successful external execution. Those states SHALL remain distinguishable.

#13. Digital Agents and Intelligence Systems

#13.1 Agents as Runtime Clients

DigitalAgents interact with RSM through the same identity, authority, protocol, and disclosure boundaries as other Actors. They SHALL not receive privileged direct database access merely because they are deployed within the same organization as the Runtime.

Agent capability and agent authority remain independent.

#13.2 Derived Intelligence

Systems such as Wellzai may use RSM projections to produce Candidate Configurations, gaps, dependencies, Pathways, recommendations, relevance assessments, or Formation-readiness conclusions.

These outputs remain DERIVED until a separate canonical operation creates the relevant authoritative state.

#13.3 Reasoning Access

An intelligence system SHOULD receive the minimum authorized state necessary for its reasoning purpose. It need not ingest every private canonical record into one global model.

Federated reasoning may operate by requesting purpose-bounded projections from relevant authorities and retaining the provenance of those inputs.

#13.4 Reasoning Trace

Consequential Derived artifacts SHOULD expose an inspectable reasoning trace at the level of factual inputs, rules, assumptions, semantic environment, dependencies, and derived conclusions.

This requirement does not require disclosure of hidden model chain-of-thought. It requires sufficient external explanation to determine why the artifact exists and which authorized inputs affected it.

#13.5 Machine Learning Stores

Prompt stores, model memory, embeddings, vector indexes, model checkpoints, and agent scratch state are not canonical RSM state by default. They MAY contain representations derived from RSM data and therefore inherit applicable policy and disclosure constraints.

Model persistence SHALL not silently create a new authority boundary.

#14. Events, Subscriptions, and Propagation

#14.1 Change Propagation

Nodes MAY publish change notifications concerning canonical mutations to authorized subscribers. Notifications can support projection refresh, cache invalidation, workflow continuation, derived-artifact invalidation, and federation synchronization.

A notification SHALL identify enough source and checkpoint information to detect duplication and ordering where those properties matter.

#14.2 At-Least-Once Delivery

Federated and asynchronous event transport SHOULD assume duplicate delivery is possible unless stronger semantics are explicitly guaranteed. Consumers SHALL therefore handle change notifications idempotently.

Exactly-once business meaning should be achieved through canonical operation identity and idempotency rather than relying solely upon transport delivery guarantees.

#14.3 Ordering

Global ordering across all RSM Nodes is neither required nor generally meaningful. A Node SHOULD provide deterministic ordering or causal information within scopes where ordering matters.

Cross-node reasoning may need to reconcile clocks, operation references, source revisions, or causal dependencies rather than relying upon one universal timestamp order.

#14.4 Subscription Authority

A subscription to change notifications is a disclosure relationship and SHOULD be governed by authority and purpose. Public events may be broadly available, while sensitive Capability, Capacity, Evidence, or relationship changes may require explicit authorization.

Subscription SHALL not imply direct access to underlying canonical objects.

#15. Offline, Edge, and Intermittent Operation

#15.1 Federation Must Tolerate Intermittence

Farms, field devices, ecological monitoring infrastructure, mobile systems, and remote facilities may operate with intermittent connectivity. RSM federation SHOULD therefore tolerate temporarily unavailable nodes without interpreting unavailability as semantic absence.

Nodes may continue operating within their own local authority boundaries when remote systems are unavailable.

#15.2 Local Canonical Operations

A node MAY commit canonical changes for which it is locally authoritative while disconnected, provided its local semantic environment, identity, authority, and policy requirements are satisfied.

Those operations should receive stable identities and later propagate through normal reconciliation when connectivity returns.

#15.3 Remote Consequential Operations

A node SHALL NOT fabricate remote Commitment, Assertion, Capacity, or other authoritative state merely because the remote authority is unavailable.

A request may remain queued or PENDING operationally, but remote canonical acceptance occurs only when the remote authority processes the operation and produces its receipt.

#15.4 Synchronization

Reconnect synchronization should exchange canonical changes, checkpoints, and relevant projection invalidations rather than blindly copying whole databases.

Conflicts SHALL be resolved according to authority boundaries and object semantics rather than generic timestamp precedence.

#16. Consistency and Reconciliation

#16.1 Consistency Domains

RSM accepts different consistency requirements for different semantic categories:

This architecture avoids imposing expensive strong consistency on data that does not require it while protecting consequential state.

#16.2 Projection Checkpoints

Projection builders SHOULD maintain source checkpoints sufficient to determine whether a projection is current relative to known canonical history.

A checkpoint MAY be revision-based, sequence-based, event-based, or another deterministic marker appropriate to the source.

#16.3 Rebuild Versus Repair

When a reconstructable projection becomes corrupt, rebuilding from authoritative state is preferable to manually repairing the projection as though it were canonical.

This keeps operational recovery aligned with the semantic architecture.

#16.4 Canonical Reconciliation

Canonical reconciliation is fundamentally different from projection rebuild. When two authoritative systems genuinely disagree, RSM SHALL preserve the conflicting authoritative Claims, Assertions, Observations, or other applicable states until the domain's reconciliation process resolves them.

The Runtime SHALL not manufacture consensus by overwriting one authority with another.

#17. Failure Semantics and Resilience

#17.1 Failure Is Part of Federation

Node failure, network partition, stale projection, semantic incompatibility, expired Delegation, unavailable policy service, and connector failure are expected runtime states rather than exceptional philosophical cases.

The architecture SHALL make them observable without corrupting semantic meaning.

#17.2 Failure Classes

Operational implementations SHOULD distinguish failures such as:

SEMANTIC_INVALID
IDENTITY_UNRESOLVED
REFERENCE_UNAVAILABLE
UNAUTHORIZED
POLICY_DENIED
REVISION_CONFLICT
DEPENDENCY_UNAVAILABLE
REMOTE_UNAVAILABLE
SEMANTIC_INCOMPATIBLE
TIMEOUT
TRANSPORT_FAILURE
INTERNAL_FAILURE

Exact error codes may vary, but the distinction between domain-negative state and infrastructure failure SHALL remain clear.

#17.3 Retry

Retries are appropriate for transient failures and SHALL reuse the same operation identity when the semantic operation is unchanged.

A retry after timeout SHALL not create a second Commitment merely because the first response was lost.

#17.4 Circuit Isolation

A failing federated node SHOULD be isolatable without making the entire RSM network unavailable. Discovery and reasoning may continue with explicit uncertainty while consequential operations requiring the unavailable authority remain blocked or qualified.

One node's failure SHALL not cause another node to rewrite its own canonical state incorrectly.

#17.5 Recovery

A Runtime SHOULD recover from process restart without losing canonical state, idempotency history required for active operations, projection checkpoints, or queued federation work whose continuation is necessary.

Derived caches may be discarded and rebuilt when recovery is simpler and semantically safe.

#18. Observability and Audit

#18.1 Operational Observability

The Runtime SHOULD expose sufficient telemetry to distinguish infrastructure health from domain state. Operators must be able to tell whether a request failed because the database is unavailable, authority was denied, a Predicate evaluated false, semantic resolution failed, or a remote node could not be reached.

A healthy service does not imply a viable Formation, while an infeasible Configuration does not imply unhealthy infrastructure.

#18.2 Correlation

Protocol operations, canonical mutations, Change Records, federation requests, connector actions, and receipts SHOULD share correlation identifiers or equivalent trace context where possible.

Correlation supports end-to-end investigation without collapsing the objects into one log record.

#18.3 Audit

The Runtime SHOULD maintain an audit trail for consequential authority, policy, disclosure, Commitment, Formation, Assertion, and revocation decisions.

Audit records should answer:

• who acted;
• for whom;
• which operation was requested;
• which Subject was affected;
• what authority was used;
• which policy decision applied;
• what canonical effect occurred; and
• when the decision was recorded.

#18.4 Audit Is Not Biography

Operational audit records and RSM Biography serve different purposes. Audit supports accountability and runtime investigation, while Biography is a meaningful domain projection of what occurred around a Subject.

A low-level database retry or policy-engine latency metric does not belong in an ecological or organizational Biography merely because it appears in an audit log.

#19. Security and Trust Boundaries

#19.1 Zero Implicit Trust Across Nodes

Federation SHALL not imply trust simply because another node speaks the RSM protocol. Nodes must authenticate peer identities, validate semantic compatibility, enforce local authority and policy, and treat inbound canonical proposals according to their own authority boundary.

Protocol compatibility is not equivalent to permission.

#19.2 Least Authority

Delegations and service identities SHOULD be granted the minimum operations and scope necessary for their purpose. A discovery service generally does not require authority to create Commitments, while an agent allowed to request Evidence does not automatically require permission to disclose that Evidence elsewhere.

Least authority reduces the consequences of compromised services or agents.

#19.3 Secrets and Credentials

Authentication secrets, private keys, passwords, access tokens, and equivalent credentials are runtime-security artifacts rather than RSM canonical semantics.

Canonical Delegation or AuthorityBasis may reference the result of secure authentication without storing sensitive authentication material inside canonical objects.

#19.4 Encryption

Sensitive data SHOULD be protected in transit and at rest according to deployment risk and applicable regulation. Encryption mechanisms are infrastructure concerns, but they SHALL preserve the ability to enforce identity, provenance, and purpose-bound disclosure.

#19.5 Tenant Isolation

Shared-hosting implementations SHALL isolate canonical authority, private projections, credentials, policy state, and disclosure boundaries among hosted participants.

A shared database does not eliminate the semantic requirement for separate authority boundaries.

#20. Portability and Infrastructure Abstractions

#20.1 Runtime Ports

The Runtime SHOULD expose explicit infrastructure contracts such as:

CanonicalRepository
OperationJournal
ChangeJournal
IdentityResolver
SemanticResolver
SemanticValidator
AuthorityEvaluator
PolicyEvaluator
ProjectionStore
ProjectionBuilder
BiographyBuilder
DiscoveryIndex
FederationGateway
DisclosureEngine
ConnectorAdapter
Clock
ObjectStore

The exact naming may differ. The architectural purpose is to keep infrastructure replaceable without changing canonical semantics.

#20.2 Relational Persistence

A relational database such as PostgreSQL may be well suited for canonical persistence, transactional mutation, revision control, idempotency, and policy metadata. RSM SHALL not assume that relational storage is the only conformant implementation.

Database tables are physical representations rather than the normative ontology.

#20.3 Graph Infrastructure

Graph stores MAY accelerate relationship traversal, network discovery, provenance exploration, and analytical projections. A graph projection SHALL remain disposable unless explicitly designated as canonical persistence by an implementation that preserves all canonical invariants there.

Graph connectivity SHALL not become authority merely because graph traversal is convenient.

#20.4 Vector Infrastructure

Vector stores MAY support semantic search, recommendation, similarity, or candidate discovery. Their contents are Derived or Projection state and must retain references to the canonical or authorized source material used to generate them.

Embedding similarity SHALL never by itself establish entity identity, Commitment, Evidence validity, or relationship truth.

#20.5 Message Infrastructure

Message brokers and event streams MAY distribute Change Records and federation messages. Transport retention and replay SHALL not be confused with canonical history unless the implementation explicitly uses an event-sourced canonical architecture that satisfies all canonical requirements.

#20.6 Cloud Portability

RSM infrastructure SHOULD avoid unnecessary provider-specific coupling in canonical semantics and core runtime contracts. Managed services may be used aggressively when operationally beneficial, provided an implementation can preserve the semantic contracts independently of those services.

#21. Deployment Topologies

#21.1 Single-Node Deployment

A small RSM installation may host canonical persistence, semantic resolution, policy, projections, discovery, and applications in one deployment. This topology is valid when one authority legitimately governs the modeled state.

The internal architecture SHOULD still preserve logical boundaries so that later federation does not require redesigning canonical semantics.

#21.2 Shared Multi-Authority Runtime

A service provider may host many Organizations or Communities within one Runtime. The deployment must preserve their separate identity, authority, disclosure, and canonical state boundaries even when infrastructure is physically shared.

This topology is operationally centralized but semantically federated.

#21.3 Federated Network

A mature RSM ecosystem may contain many autonomous nodes operated by farms, processors, laboratories, certifiers, lenders, communities, research institutions, public agencies, and other participants.

Shared services may provide routing, public vocabulary, discovery indexes, or network-wide projections without becoming owners of participant canonical state.

#21.4 Hybrid Edge and Cloud

A participant may maintain an edge Runtime near operational systems while publishing authorized projections and accepting federation requests through cloud infrastructure.

This topology is particularly appropriate when connectivity is intermittent or sensitive source data should remain close to its origin.

#22. Illustrative Federated Scenario

#22.1 Discovery

A buyer expresses an Intent and DemandExpression for regenerative food-grade wheat. An Outcome Formation service queries the federated Discovery Index and identifies several producer Subjects, one processor, a laboratory, and a logistics provider whose authorized projections appear relevant.

At this stage, the service has discovered possibilities rather than authoritative current commitments.

#22.2 Authoritative Capacity Query

The service issues ASK operations to relevant producer and processor nodes. Each node applies disclosure policy and returns purpose-bounded Capacity projections with source authority, freshness, and provenance.

One producer exposes Capability but no current Capacity for the required period. The system preserves the distinction rather than interpreting Capability as supply.

#22.3 Derived Configuration

Wellzai constructs a Candidate Configuration from the authorized inputs and identifies insufficient processor Capacity. The Configuration and Gap remain DERIVED, with source references and semantic environment recorded.

No participant's canonical state changes because the reasoning exists.

#22.4 Conditional Coordination

The processor Node receives a proposal to expand Capacity. A lender Node conditionally commits financing, the buyer conditionally commits future demand, and producers commit bounded future production.

Each Commitment is independently canonicalized under the authority of the participant that makes it.

#22.5 Reconciliation Before Formation

Before Formation establishment, the Runtime reconciles consequential Capacity and Commitment state against each authoritative node. One cached Capacity value has changed, causing the derived Configuration to be recomputed.

Formation establishment proceeds only when the revised canonical conditions satisfy the governing criteria.

#22.6 Execution

The Formation coordinates Activities across farms, the processor, laboratory, and logistics systems. Connectors translate between RSM operations and external farm, laboratory, and processing applications while preserving provenance and operation identity.

External execution results return through canonical Activity, Observation, domain Event, or other appropriate RSM operations rather than by direct database mutation.

#22.7 Outcome and Biography

Later Observations and Evaluations support Outcomes concerning soil condition, farm economics, processing performance, and other Subjects. Those canonical Outcomes become part of the authoritative history from which Biography projections are constructed.

Future discovery can use appropriate Biography-derived evidence without assuming that historical Capacity or conditions remain current.

#23. Runtime Invariants

#23.1 Authority Invariants

The Runtime SHALL preserve:

Storage Location ≠ Authority
Authentication ≠ Authority
Hosting ≠ Authority
Projection ≠ Authority
Discovery Result ≠ Authority
Cached State ≠ Current Authority

Authority must remain attributable to the legitimate boundary governing the state.

#23.2 Category Invariants

The Runtime SHALL preserve:

Canonical ≠ Derived
Canonical ≠ Operational
Canonical ≠ Projection
Graph Projection ≠ Canonical Graph
Vector Index ≠ Evidence
Biography Projection ≠ Canonical History

Infrastructure optimization SHALL not collapse semantic category.

#23.3 Federation Invariants

The Runtime SHALL preserve:

Federation ≠ Central Ownership
Discovery ≠ Disclosure
Disclosure ≠ Transfer of Authority
Unavailable ≠ False
Stale ≠ Current
Remote Failure ≠ Negative Domain Conclusion

These distinctions are mandatory for trustworthy distributed reasoning.

#23.4 Coordination Invariants

The Runtime SHALL preserve:

Proposal ≠ Commitment
Derived Readiness ≠ Formation
Message Delivery ≠ External Execution
Transport Success ≠ Canonical Acceptance
Cross-Node Coordination ≠ Global Database Transaction

Each consequential transition must occur through the authority responsible for it.

#23.5 Identity Invariants

The Runtime SHALL preserve:

External Identifier ≠ Canonical Identity
Similarity ≠ Identity
Projection Reference ≠ Identity Authority
Node Identity ≠ Subject Identity

Entity resolution and node routing must remain independently governed.

#23.6 History Invariants

The Runtime SHALL preserve:

Current State ≠ Biography
Canonical Change Record ≠ Domain Event
Audit Log ≠ Biography
Projection Rebuild ≠ Canonical Reconciliation
Historical State ≠ Current State

These distinctions prevent infrastructure records from contaminating domain meaning.

#24. Operational Conformance

#24.1 Runtime Conformance

A conformant Runtime SHALL provide or compose implementations of:

• canonical persistence;
• semantic resolution and validation;
• identity resolution;
• operation processing;
• authority evaluation;
• policy enforcement;
• idempotency;
• revision or concurrency protection;
• authoritative history;
• projection construction;
• federation;
• selective disclosure; and
• explicit result semantics.

A deployment MAY use different components or service boundaries if the same semantics remain observable.

#24.2 Projection Conformance

At least one significant projection SHOULD be destructible and rebuildable from its authoritative inputs with semantic equivalence for its intended queries.

This proves that projection infrastructure has not become a hidden source of canonical truth.

#24.3 Federation Conformance

A federated implementation SHALL demonstrate that independently governed nodes can interact without direct access to one another's private persistence.

At minimum, conformance should prove that discovery works through authorized projections, consequential state can be reconciled with its authoritative source, unauthorized disclosure fails, and remote unavailability does not become false domain state.

#24.4 Connector Conformance

A connector claiming RSM compatibility SHALL preserve source identity mapping, provenance, semantic mapping, authority boundaries, operation identity, and result semantics.

A connector SHALL not achieve interoperability by writing directly into canonical tables or bypassing policy.

#24.5 Agent Conformance

A DigitalAgent participating in RSM SHALL operate through identifiable Actor semantics and applicable authority. It MAY reason broadly over authorized projections but SHALL not create Commitment, Assertion, Formation, disclosure, or other consequential canonical effects outside its Delegation.

#24.6 Recovery Conformance

A Runtime SHOULD demonstrate cold restart, canonical recovery, idempotent retry after uncertain operation results, projection rebuild, and continuation of federation processing without duplicate consequential effects.

Infrastructure recovery is incomplete if semantic state becomes ambiguous after restart.

#25. Architectural Boundaries

#25.1 Relationship to the Canonical Model

The Canonical Model defines which objects and transitions are authoritative. The Runtime supplies persistence and execution machinery that preserves those semantics.

The Runtime SHALL not invent alternative canonical categories because they simplify storage implementation.

#25.2 Relationship to the Semantic Model

The Semantic Model defines Concepts, Domain Packs, Predicates, contexts, and validation semantics. The Runtime resolves and activates those artifacts.

A Semantic Resolver is an operational implementation of the semantic architecture, not the authority to redefine it.

#25.3 Relationship to Applications

Applications such as Ryzosphere consume RSM through client, protocol, projection, and discovery boundaries. They MAY maintain local UI state and caches but SHALL not bypass RSM canonical boundaries to manipulate authoritative state directly.

The intended dependency remains:

Application
    ↓
RSM Client / Protocol
    ↓
RSM Runtime
    ↓
Canonical + Semantic State

rather than:

Application
    ↓
RSM Database Tables

#25.4 Relationship to Outcome Formation Intelligence

Wellzai or another intelligence system consumes authorized RSM state and produces Derived reasoning. It may coordinate protocol operations but does not own the canonical state of the participants it coordinates.

This boundary allows intelligence to improve independently of the canonical substrate and allows alternative intelligence systems to operate over the same RSM infrastructure.

#26. Final Architecture Principle

#26.1 Federation as a Property of the Model

Federation is not an integration feature added after the RSM data model is implemented. It follows directly from the conceptual premise that regenerative systems are composed of autonomous Subjects, institutions, LivingSystems, communities, and authorities whose state cannot legitimately be collapsed into one owner.

The Runtime therefore treats sovereignty, authority, selective disclosure, reconciliation, and provenance as foundational operating concerns.

#26.2 Local Authority, Shared Meaning

RSM does not require every participant to use the same internal systems. A farm can retain its farm-management software, a laboratory its LIMS, a processor its ERP, a certifier its certification platform, and a Community its own governance tools.

What they share is enough semantic grammar, protocol behavior, identity, provenance, and authority structure to become mutually intelligible.

#26.3 Disposable Views, Durable Meaning

The architecture deliberately makes maps, indexes, search documents, embeddings, discovery views, network graphs, and Biography presentations disposable. These projections can evolve rapidly because the durable meaning beneath them remains governed.

This separation allows applications to innovate without repeatedly rewriting the semantic foundation.

#26.4 Accountable Intelligence

The Runtime provides a boundary within which increasingly powerful DigitalAgents and reasoning systems can participate safely. Intelligence may discover more possibilities, reason across more domains, build richer Pathways, and learn from longer histories while canonical authority remains tied to identifiable Subjects, legitimate Principals, policy, and inspectable provenance.

The resulting system can become more intelligent without becoming less accountable.

#26.5 Governing Principle

The RSM Runtime & Federation Architecture can therefore be summarized by one rule:

Authoritative state remains where legitimate authority resides; RSM supplies the shared semantics, protocol, runtime boundaries, and federated coordination required for that state to participate in a larger living ecology.

Local systems preserve sovereignty. Projections make the ecology visible. Federation makes it interoperable. Commitments make coordination accountable. Observations reconnect the system to reality. Outcomes reveal consequence, and Biography allows experience to accumulate without converting history into present truth.

Together, these mechanisms transform the Regenerative Systems Model from a shared ontology into operational infrastructure for a distributed, adaptive, and accountable outcome-forming ecology.