RSM Technology & Infrastructure Architecture

#1. Purpose

#1.1 Implementation Objective

The RSM normative specifications establish the meaning, authority boundaries, protocol, runtime behavior, federation model, and conformance requirements of the Regenerative Systems Model. This document defines the technology and infrastructure architecture through which those specifications will be realized.

The implementation architecture is deliberately conservative at the core. RSM semantics, canonical authority, and protocol behavior must remain stable even as storage engines, graph systems, vector databases, model providers, messaging systems, and deployment platforms evolve.

The governing implementation principle is:

RSM Core owns meaning and authority. Infrastructure adapters provide specialized ways to persist, locate, connect, search, reason over, and exchange that meaning.

#1.2 Architectural Objective

The initial implementation must be simple enough to build and operate while exposing all of the infrastructure boundaries required by the long-term RSM architecture.

Accordingly, RSM will not initially require specialized Graph, Vector, LLM, message-broker, or orchestration infrastructure. It will, however, define stable ports for these capabilities from the beginning so that later implementations can be introduced without restructuring the canonical model or breaking application interfaces.

#1.3 Realization Strategy

RSM SHALL be:

federated externally and modular internally.

Each RSM Runtime Node will initially be implemented as a cohesive Go modular runtime with strongly enforced module and adapter boundaries. Independent RSM Nodes federate through the RSM Protocol rather than through shared database access.

Microservice extraction may occur later where scaling, security isolation, availability, deployment cadence, or ownership provides a clear operational justification.

#2. Technology Stack

#2.1 Primary Stack

The initial RSM realization stack is:

Go modular runtime + PostgreSQL with PostGIS, full-text search, trigram indexing and optional pgvector + JSON-LD/RDF/SHACL semantic contract + explicit Search, Graph, Spatial, Temporal, Vector, Embedding and Model-provider ports + HTTPS/JSON protocol + OIDC authentication + native RSM authority and policy + transactional change journal and projection framework + S3-compatible evidence storage + deterministic reference reasoning + TypeScript SDKs + containerized multi-node conformance.

The architecture deliberately separates the technology that implements a capability from the semantic contract governing that capability.

#2.2 Technology Matrix

#3. Runtime Architecture

#3.1 Logical Architecture

The RSM Runtime is organized into four principal planes:

The diagram defines dependency direction rather than mandatory process boundaries.

#3.2 Canonical Plane

The Canonical Plane owns locally authoritative state and the rules governing its mutation. It includes canonical persistence, semantic validation, identity resolution, authority, policy, revisions, lifecycle, provenance, operation journal, and change journal.

No projection or intelligence component may mutate canonical state directly.

#3.3 Projection and Discovery Plane

The Projection Plane transforms authoritative state into specialized, rebuildable views optimized for different classes of query.

RSM defines four primary discovery projections:

• Search for structured and lexical retrieval;
• Graph for relationship and network traversal;
• Spatial for geographic and spatiotemporal discovery;
• Vector for semantic similarity.

Biography represents an additional historical projection over canonical history.

All projections SHALL remain:

rebuildable
checkpointed
source-provenanced
non-authoritative
permission-aware
invalidatable

#3.4 Intelligence Plane

The Intelligence Plane consumes authorized RSM state and projections and creates Derived reasoning artifacts. It does not own canonical participant state.

The initial deterministic Reference Reasoner will later be replaceable by systems such as Wellzai without modifying the canonical runtime.

#4. Go Runtime Architecture

#4.1 Why Go

Go remains the primary RSM implementation language because the prior kernel experiments demonstrated that RSM semantic distinctions can be represented as strong type boundaries, validating constructors, sealed interfaces, and executable conformance rules.

The same implementation model proved compatible with both in-memory and PostgreSQL substrates while preserving authority, idempotency, concurrency, rollback, and protocol behavior.

Go also provides a suitable runtime for:

• compact RSM Node deployment;
• federation concurrency;
• edge and intermittent deployments;
• protocol servers;
• connectors;
• background projection workers;
• command-line tooling; and
• deterministic conformance infrastructure.

#4.2 Modular Monolith

The initial RSM Node SHALL be a modular monolith. Modules communicate through explicit application and port interfaces rather than importing infrastructure details from one another.

Potential future service extraction SHALL preserve the same interfaces.

#4.3 Dependency Direction

The dependency rule is:

Applications / Agents / Connectors
              ↓
          RSM Protocol
              ↓
        Runtime Services
              ↓
       Canonical Domain
              ↓
     Infrastructure Ports
              ↓
     Technology Adapters

Core and canonical packages SHALL NOT import PostgreSQL, HTTP framework, graph database, vector database, model-provider, or application-specific packages.

#5. Canonical Persistence

#5.1 PostgreSQL

PostgreSQL is the initial canonical persistence substrate for an RSM Node.

It will store:

• canonical Subjects;
• Relationships;
• Participation and authority-bearing relationships;
• Capability and Capacity;
• Offers, Seeks, and DemandExpressions;
• Intent;
• Observations;
• Claims;
• Evidence metadata;
• Evaluations;
• Assertions;
• Commitments;
• Formations;
• Activities;
• domain Events;
• Outcomes;
• revisions and historical state;
• operation journal;
• canonical change journal;
• transactional outbox; and
• locally materialized projections.

#5.2 Relational First

Canonical semantics SHOULD use explicit relational structures where identity, lifecycle, referential integrity, authority, and transaction semantics matter.

RSM SHALL NOT collapse the canonical model into one universal:

objects(id, type, jsonb)

table merely for schema flexibility.

JSONB may be used for governed extensibility and domain-specific attributes where the semantic architecture explicitly permits open vocabulary.

#5.3 SQL Access

Go will use pgx for PostgreSQL connectivity and transaction control and sqlc or equivalent generated-query tooling for type-safe query interfaces.

A heavyweight ORM SHALL NOT become the domain model.

#5.4 Migrations

Database migrations SHALL be explicit, ordered, version-controlled SQL artifacts.

Schema migration is an implementation concern and SHALL remain distinct from RSM semantic vocabulary migration.

#6. Spatial and Temporal Infrastructure

#6.1 Spatial Semantics Are Foundational

Spatial information is not an application-level convenience in RSM. Place is a foundational Subject kind, and spatial relationships connect people, organizations, facilities, living systems, materials, activities, observations, formations, and outcomes.

RSM therefore treats spatial infrastructure as part of the initial Runtime architecture.

#6.2 PostGIS

PostGIS SHALL be enabled in the first PostgreSQL deployment.

It provides authoritative and projected support for:

• points;
• parcels;
• polygons;
• facility footprints;
• fields;
• service areas;
• watersheds;
• ecological regions;
• corridors;
• routes;
• overlapping boundaries; and
• proximity queries.

#6.3 Place and Spatial Extent

Geometry SHALL not be duplicated across every Subject.

RSM maintains the conceptual pattern:

Subject
    ↓ relationship
Place
    ↓
Spatial Extent

A Person, Organization, Facility, Material, Activity, Observation, or Formation references Place in the appropriate context.

A spatial extent is implementation state describing the geometry of a Place; it is not a new foundational Subject kind.

#6.4 Spatial Extent

A spatial record SHOULD support:

placeRef
geometry
coordinate reference system
precision
source
authority
validFrom
validUntil
recordedAt
provenance

This allows RSM to distinguish exact, generalized, historical, authoritative, and Derived geometry.

#6.5 Spatial Ports

RSM SHALL define at minimum:

SpatialRepository
SpatialIndex
SpatialDisclosure
Geocoder
RoutingProvider

The latter two may initially have no production adapter.

#6.6 Spatial Disclosure

The Runtime SHALL support policy-bounded spatial projection.

A Place may be exposed differently depending upon purpose:

Public discovery
    county or watershed

Authorized participant
    generalized region

Active Formation
    exact field polygon

Possible projection strategies include:

• exact geometry;
• simplified geometry;
• centroid;
• bounding geometry;
• administrative region;
• watershed;
• hierarchical spatial cell; and
• no disclosure.

#6.7 Hierarchical Spatial Index

RSM SHOULD define a SpatialCellIndex port for future use by H3 or equivalent hierarchical spatial indexing.

The initial implementation may remain PostGIS-only.

The future adapter may support:

• large-scale discovery;
• regional network partitioning;
• foodshed analysis;
• density analysis;
• approximate geographic routing; and
• privacy-preserving coarse location.

#6.8 Temporal Semantics

RSM will distinguish:

valid time — when a condition was true in the represented world;

and:

recorded time — when the RSM Runtime learned or recorded it.

This distinction establishes a path toward bitemporal semantics without requiring every object to use a complete bitemporal representation immediately.

#6.9 Temporal Infrastructure

PostgreSQL temporal and range capabilities SHALL form the initial implementation:

timestamptz
daterange
tstzrange
GiST indexes

RSM SHALL expose a TemporalQuery port so that applications do not invent inconsistent interpretations of:

current
active
during
overlaps
before
after
effective-at
known-as-of

Spatial and temporal reasoning SHOULD compose naturally.

#7. Semantic Infrastructure

#7.1 Semantic Contract

The executable semantic stack is:

Go canonical semantics
        +
JSON-LD semantic projection
        +
RDF/Turtle governed vocabulary
        +
SHACL executable constraints
        +
Golden fixtures

These components serve different responsibilities and SHALL not be collapsed.

#7.2 JSON-LD

The Runtime SHALL use the governed RSM JSON-LD context for semantic interchange.

Core and application code SHALL not create parallel private definitions of governed RSM vocabulary.

#7.3 RDF/Turtle

RSM Core vocabulary and Domain Pack semantics will be represented in RDF-compatible governed artifacts, using Turtle as the primary source representation where appropriate.

RDF is a semantic representation layer, not the required operational persistence substrate.

#7.4 SHACL

SHACL defines executable semantic validation for RSM semantic artifacts and interchange.

The initial toolchain will retain Python, RDFLib, and pySHACL because this toolchain is mature and already validated through prior RSM experiments.

SHACL SHALL primarily serve:

• CI;
• conformance;
• Domain Pack validation;
• imported semantic payload validation;
• JSON-LD fixture validation; and
• semantic round-trip verification.

Runtime Go validation will enforce performance-critical canonical invariants directly.

#8. Search Infrastructure

#8.1 Search Port

RSM SHALL define:

SearchIndex

as a first-class Projection boundary.

#8.2 Initial Implementation

The first implementation will use:

• PostgreSQL full-text search;
• pg_trgm;
• structured relational filters; and
• semantic Concept references.

This is sufficient for initial Subject, Capability, Offer, Seek, and discovery use cases.

#8.3 Future Search Engines

OpenSearch or another specialized search engine may later implement SearchIndex without changing RSM Core.

#9. Graph Infrastructure

#9.1 Graph Is a Projection

RSM is relational by nature, but graph infrastructure SHALL not become synonymous with canonical RSM state.

A graph database or graph representation is a Projection optimized for network traversal.

#9.2 Graph Port

The Runtime SHALL define a GraphProjection contract from the first milestone.

It should support responsibilities such as:

project node
project edge
remove projection
neighbors
bounded traversal
path query
checkpoint
rebuild

It SHALL NOT expose canonical mutation operations.

#9.3 Initial Adapter

The initial PostgresGraphProjection will use canonical Relationship and Participation state projected into indexed PostgreSQL structures.

Recursive CTEs and relational indexes should be sufficient for the reference implementation.

#9.4 Future Adapters

Possible future adapters include:

Neo4jGraphProjection
MemgraphGraphProjection
other graph engines

Changing the Graph adapter SHALL not change canonical identities or relationships.

#10. Vector and Embedding Infrastructure

#10.1 Separate Responsibilities

RSM SHALL separate:

EmbeddingProvider

from:

VectorIndex

The first generates vector representations; the second stores and searches them.

#10.2 Vector Index

A VectorIndex adapter will be defined in the initial infrastructure architecture.

The initial implementation may use pgvector while remaining optional for baseline conformance.

#10.3 Embedding Provider

The initial EmbeddingProvider used in conformance SHALL be deterministic and non-ML so that tests remain reproducible.

Later providers may use local or external embedding models.

#10.4 Vector Semantics

Vector similarity may produce candidate references or rankings.

It SHALL NOT establish:

identity
relationship truth
authority
evidence validity
commitment
formation
outcome

Vector state remains Projection or Derived infrastructure.

#11. Model and Reasoning Infrastructure

#11.1 Model Provider

RSM SHALL define a ModelProvider infrastructure port even though no generative model is required in the initial canonical implementation.

A Model Provider may later support:

• structured generation;
• classification;
• extraction;
• summarization;
• tool-mediated reasoning; and
• other model capabilities.

#11.2 Reasoning Provider

RSM SHALL separately define:

ReasoningProvider

for domain-level formation reasoning.

This separation prevents model-provider technology from becoming RSM reasoning semantics.

#11.3 Reference Reasoner

The Reference Implementation will initially use a deterministic Go reasoner capable of producing:

• Candidate Relevance;
• Candidate Configuration;
• Gap;
• Dependency;
• Pathway;
• Recommendation; and
• Formation Readiness.

All resulting artifacts remain DERIVED.

#11.4 Wellzai

Wellzai may later implement ReasoningProvider using:

SearchIndex
GraphProjection
SpatialIndex
TemporalQuery
VectorIndex
SemanticResolver
ModelProvider
RSM Protocol

Wellzai remains a consumer of RSM rather than the owner of canonical RSM state.

#12. Change Propagation and Event Infrastructure

#12.1 Initial Strategy

RSM will initially use PostgreSQL transactions and a transactional outbox for durable canonical change propagation.

This supports:

• projection update;
• discovery refresh;
• federation notification;
• cache invalidation;
• Derived artifact invalidation; and
• asynchronous connector work.

#12.2 Change Ports

The architecture SHALL define:

ChangeJournal
ChangePublisher
ChangeSubscriber

from the beginning.

The first adapters may all be PostgreSQL-backed.

#12.3 Future Brokers

Kafka, NATS JetStream, Pulsar, or another event infrastructure may later implement the publisher/subscriber ports.

No broker is required for RSM v1.

#12.4 Event Distinction

The infrastructure SHALL preserve:

Domain Event
≠ Canonical Change Record
≠ Transport Message

A broker SHALL never redefine RSM Event semantics.

#13. Evidence and Object Storage

#13.1 Canonical Evidence Metadata

PostgreSQL will store canonical Evidence metadata including:

Evidence identity
Subject
provenance
media type
digest
source
authority
timestamps
policy
payload reference

#13.2 Blob Store

Large or binary payloads SHALL use the BlobStore port.

The initial adapters will include:

FilesystemBlobStore
S3BlobStore

Any S3-compatible backend may later be used without altering Evidence semantics.

#14. Authentication, Authority, and Policy

#14.1 Authentication

RSM will use standards-based authentication such as OIDC, OAuth2, and JWT.

Authentication produces an authenticated runtime identity.

It does not itself create RSM authority.

#14.2 Authority Flow

The canonical path is:

OIDC / Authentication
        ↓
Authenticated Actor
        ↓
Identity Resolver
        ↓
Authority Evaluator
        ↓
Delegation / AuthorityBasis
        ↓
Policy Evaluator
        ↓
Allowed / Denied

#14.3 Native Authority

The RSM AuthorityModel will remain native Go domain logic.

External identity-provider roles SHALL NOT silently become RSM authority.

#14.4 Policy

The first PolicyEvaluator will also remain native Go.

PostgreSQL RLS MAY provide defense in depth for shared-hosting deployments but SHALL not define the canonical meaning of RSM authority.

OPA, Cedar, or other policy technologies may later implement appropriate adapter boundaries if justified.

#15. Protocol and SDK Architecture

#15.1 Transport Independence

The RSM ProtocolExecutor SHALL remain transport-independent.

The stack is:

HTTP / Other Transport
        ↓
Transport Adapter
        ↓
RSM Protocol Envelope
        ↓
Protocol Executor

#15.2 Initial Transport

The reference transport will use HTTPS and JSON.

JSON-LD representations may be exposed where semantic interchange requires them.

#15.3 OpenAPI

The reference HTTP surface SHALL expose an OpenAPI 3.1 description suitable for SDK generation and integrator documentation.

#15.4 SDKs

The first SDKs will be:

Go
    server / connector integration

TypeScript
    Ryzosphere and web applications

Applications SHALL communicate through SDK and protocol boundaries rather than database adapters.

#16. Connector Architecture

#16.1 Connector Port

Existing systems participate through Connector adapters.

A connector may map:

external identity
external schema
external vocabulary
external authorization
external execution

into governed RSM semantics.

#16.2 Connector Rules

Connectors SHALL preserve:

• identity mapping;
• provenance;
• semantic mapping;
• authority;
• operation identity;
• execution status; and
• canonical mutation boundaries.

A Connector SHALL NOT obtain privileged access to canonical tables.

#17. Deployment Architecture

#17.1 Development Environment

Local development will use Docker Compose.

The full conformance environment SHOULD support:

RSM Node A
RSM Node B
RSM Node C
RSM Node D
PostgreSQL/PostGIS per authority boundary
Reference external system
Reference reasoner
Conformance harness

Nodes may share infrastructure during lightweight development where logical isolation remains testable.

#17.2 Hosted Deployment

Production-oriented deployment uses OCI containers with managed PostgreSQL/PostGIS.

The architecture remains provider-independent.

#17.3 Managed PostgreSQL

Any standards-compliant PostgreSQL provider may be used.

Supabase is acceptable when used as:

RSM PostgreSQL Adapter
        ↓
Supabase PostgreSQL

RSM Core SHALL NOT depend directly upon provider-specific Auth, Realtime, client SDK, or policy semantics.

#17.4 Web Applications

Vercel or comparable application hosting may be used for Ryzosphere, administrative interfaces, and documentation.

The canonical RSM Runtime SHOULD execute as an independently deployable containerized service.

#18. Observability

#18.1 Telemetry

RSM will use OpenTelemetry-compatible tracing and metrics with structured Go logging.

Telemetry SHOULD cover:

• protocol requests;
• authority evaluation;
• policy evaluation;
• canonical transactions;
• projection updates;
• federation;
• reconciliation;
• connectors;
• reasoning;
• semantic validation; and
• recovery.

#18.2 Semantic and Operational Diagnostics

Operational diagnostics SHALL distinguish infrastructure failure from domain and semantic conditions.

For example:

REMOTE_UNAVAILABLE
≠ zero Capacity

POLICY_DENIED
≠ semantic invalidity

INDETERMINATE
≠ false

#19. Repository Structure

#19.1 Proposed Structure

An illustrative repository structure is:

rsm/
├── docs/
│   ├── README.md
│   ├── 01-rsm-concepts-paper.md
│   ├── 02-rsm-subject-model.md
│   ├── 03-rsm-semantic-model-taxonomy.md
│   ├── 04-rsm-canonical-model-protocol-specification.md
│   ├── 05-rsm-runtime-federation-architecture.md
│   ├── 06-rsm-reference-implementation-and-conformance.md
│   └── technology/
│       └── rsm-technology-infrastructure-architecture.md
│
├── semantic/
│   ├── context/
│   ├── vocabulary/
│   ├── domain-packs/
│   ├── shapes/
│   └── fixtures/
│
├── canonical/
│   ├── subject/
│   ├── relationship/
│   ├── capability/
│   ├── expression/
│   ├── epistemic/
│   ├── commitment/
│   ├── formation/
│   ├── activity/
│   └── outcome/
│
├── protocol/
│   ├── envelope/
│   ├── operations/
│   ├── receipts/
│   └── executor/
│
├── runtime/
│   ├── persistence/
│   ├── semantic/
│   ├── identity/
│   ├── authority/
│   ├── policy/
│   ├── history/
│   ├── projections/
│   │   ├── search/
│   │   ├── graph/
│   │   ├── spatial/
│   │   ├── temporal/
│   │   ├── vector/
│   │   └── biography/
│   ├── federation/
│   └── disclosure/
│
├── intelligence/
│   ├── embeddings/
│   ├── models/
│   └── reference-reasoner/
│
├── connectors/
│   ├── sdk/
│   └── reference/
│
├── transport/
│   └── http/
│
├── sdk/
│   ├── go/
│   └── typescript/
│
├── conformance/
│   ├── semantic/
│   ├── canonical/
│   ├── protocol/
│   ├── runtime/
│   ├── federation/
│   └── golden/
│
└── deployments/
    ├── docker/
    └── examples/

The precise package layout may evolve while preserving the architectural dependencies.

#20. Infrastructure Ports

#20.1 Required Ports

The following infrastructure contracts SHALL exist by the completion of R0, even where only a minimal adapter is initially implemented:

CanonicalRepository
HistoryRepository
OperationJournal
ChangeJournal
ChangePublisher
ChangeSubscriber

SemanticResolver
SemanticValidator
IdentityResolver
AuthorityEvaluator
PolicyEvaluator

ProjectionBuilder
SearchIndex
GraphProjection
SpatialRepository
SpatialIndex
SpatialDisclosure
SpatialCellIndex
TemporalQuery
VectorIndex

EmbeddingProvider
ModelProvider
ReasoningProvider

DiscoveryIndex
FederationTransport
DisclosureEngine
ConnectorAdapter

BlobStore
Authenticator
KeyProvider
Telemetry
Clock

This set creates the architectural sockets required for future infrastructure without requiring those technologies to be operational immediately.

#20.2 Adapter Principle

Every infrastructure adapter SHALL obey:

technology implements RSM port

and never:

RSM semantics depend on technology behavior

Therefore:

PostGIS does not define Place.
Neo4j does not define Relationship.
pgvector does not define truth.
An LLM does not define Assertion.
OIDC does not define Authority.
Kafka does not define Event.
PostgreSQL does not define Policy.

#21. Technology Decisions Deferred by Design

#21.1 Graph Engine

No specialized graph database is required initially.

The GraphProjection port is mandatory; its specialized implementation is deferred.

#21.2 Vector Database

No external vector database is required initially.

The VectorIndex port and pgvector adapter establish compatibility without creating an operational dependency.

#21.3 Generative Models

No LLM is required for baseline RSM conformance.

The ModelProvider port establishes the future extension boundary.

#21.4 Event Broker

No Kafka or NATS dependency is required initially.

The ChangePublisher and ChangeSubscriber ports allow future substitution.

#21.5 Orchestration

Kubernetes and workflow engines are not part of initial RSM architecture requirements.

Formation semantics remain canonical RSM state rather than being delegated to a workflow engine.

#22. Five-Milestone Realization Plan

#22.1 R0 — Foundation and Canonical Core

R0 consolidates the previous R0, R1, and R2 work into one foundation milestone.

Its objective is to reconcile the existing Go kernel with the completed six-document normative RSM foundation and establish the complete infrastructure skeleton.

R0 includes:

• audit existing kernel against normative specifications;
• update terminology from Map to Model;
• implement Subject Model foundational kinds;
• establish JSON-LD context v4;
• update RSM Core vocabulary;
• establish Domain Pack framework;
• update SHACL shapes and semantic fixtures;
• define all infrastructure ports;
• enable PostgreSQL;
• enable PostGIS;
• establish temporal primitives;
• create canonical relational model;
• complete canonical types and constructors;
• implement provenance, revision, history, and lifecycle;
• establish BlobStore;
• scaffold Search, Graph, Spatial, Temporal, Vector, Embedding, and Model ports;
• maintain full semantic round-trip and conformance.

At completion, RSM has a stable executable semantic and canonical foundation with no architectural holes requiring later restructuring.

#22.2 R1 — Protocol, Read Runtime, and Projection Plane

R1 consolidates the previous R3 and R4 work.

Its objective is to make the canonical Model operational through the complete protocol and a rebuildable read/projection plane.

R1 includes:

• complete protocol operations;
• AuthorityModel;
• Delegation and Principal semantics;
• PolicyEvaluator;
• operation journal;
• idempotency;
• optimistic concurrency;
• transactional canonical mutation;
• change journal and transactional outbox;
• ASK;
• DISCLOSE;
• SearchIndex;
• GraphProjection using PostgreSQL;
• SpatialIndex using PostGIS;
• TemporalQuery;
• optional pgvector VectorIndex;
• Biography projection;
• discovery projection;
• spatial disclosure;
• projection rebuild;
• stale projection detection;
• derived-artifact invalidation boundary;
• recovery tests.

At completion, one RSM Node is a fully usable canonical and query runtime.

#22.3 R2 — Federation and Integration

R2 consolidates the previous transport and federation work.

Its objective is to connect independently governed RSM Nodes and existing external systems without weakening authority boundaries.

R2 includes:

• HTTPS/JSON protocol transport;
• OpenAPI specification;
• Go SDK;
• TypeScript SDK;
• Node Manifest;
• Capability Manifest;
• semantic compatibility negotiation;
• multi-node federation;
• authoritative reconciliation;
• selective disclosure;
• federated ASK;
• federated COMMIT;
• node-failure semantics;
• Connector SDK;
• reference external-system connector;
• spatially scoped federation discovery;
• federation conformance scenarios.

At completion, RSM becomes a distributed infrastructure rather than a standalone runtime.

#22.4 R3 — Outcome Formation and Intelligence Infrastructure

R3 realizes the derived reasoning plane.

Its objective is to demonstrate that RSM can support outcome formation while preserving the distinction between intelligence and authority.

R3 includes:

• deterministic Reference Formation Reasoner;
• candidate relevance;
• Candidate Configuration;
• Gap detection;
• Dependencies;
• Pathway;
• Recommendation;
• Formation Readiness;
• conditional Commitment;
• Formation establishment;
• reasoning provenance;
• Search + Graph + Spatial + Temporal candidate composition;
• EmbeddingProvider activation;
• VectorIndex integration;
• ModelProvider adapter contract tests;
• optional external Graph adapter proof;
• optional model-provider proof;
• change-driven Derived artifact invalidation.

At completion, the complete Intent-to-Formation reasoning cycle exists without requiring Wellzai.

#22.5 R4 — Full Conformance and Ecosystem Adoption

R4 is the system-integration milestone.

Its objective is to prove the complete architecture and hand the resulting platform to applications and intelligence systems.

R4 includes:

• full semantic conformance;
• canonical conformance;
• protocol conformance;
• runtime conformance;
• federation conformance;
• connector and agent conformance;
• fault injection;
• cold-start verification;
• projection rebuild;
• restart recovery;
• all golden scenarios;
• material provenance scenario;
• cross-domain scenario;
• spatial/temporal discovery scenario;
• Outcome and Biography learning loop;
• Gate J Full RSM Reference Conformance;
• publish SDKs;
• integrate Ryzosphere with real RSM Runtime;
• integrate Wellzai as a ReasoningProvider;
• produce reference deployment and evidence bundle.

At completion, RSM is no longer an architecture or reference kernel. It is a conformant infrastructure platform ready to support applications, agents, and federated ecosystem participants.

#23. Milestone Dependency Model

The five milestones are cumulative but produce meaningful independently verifiable systems:

The milestone boundaries represent architectural capabilities rather than arbitrary development timeboxes.

Each milestone SHALL leave the repository in a fully verifiable state.

#24. Realization Rules

#24.1 No Architecture Debt by Deferral

A deferred technology SHALL still have its architectural boundary defined before code begins to depend directly upon a substitute implementation.

For example, using PostgreSQL for graph traversal is acceptable only because callers depend upon GraphProjection, not PostgreSQL graph SQL directly.

#24.2 No Premature Infrastructure

Defining a port does not justify deploying a specialized technology before requirements demand it.

RSM therefore separates:

architectural completeness

from:

infrastructure proliferation

The first is required immediately. The second is intentionally delayed.

#24.3 Conformance Before Optimization

Every implementation optimization must preserve the same contract suites.

A new graph engine, vector store, search engine, broker, model provider, spatial index, or persistence adapter SHALL pass the relevant conformance contract before replacing the existing adapter.

#24.4 Canonical Firebreak

No infrastructure adapter may create canonical state outside the Protocol Executor and canonical acceptance boundary.

This applies equally to:

• Connectors;
• Graph systems;
• AI agents;
• model providers;
• search systems;
• vector systems;
• federation gateways; and
• administrative tools.

#25. Final Architecture Principle

#25.1 Complete Architecture, Minimal Initial Infrastructure

RSM should not confuse technological simplicity with architectural incompleteness. The first implementation deliberately uses PostgreSQL to satisfy several infrastructure roles because PostgreSQL is capable, operationally simple, and already proven by earlier RSM experiments.

At the same time, specialized capabilities are represented through independent contracts from the outset. Graph traversal, spatial reasoning, vector retrieval, semantic search, model inference, event distribution, evidence storage, identity, and federation can therefore evolve independently.

#25.2 Space, Time, Relationship, and Meaning

Four dimensions are especially important to the RSM runtime:

Meaning determines what an entity or relationship represents.

Relationship determines how entities participate in an ecology.

Space determines where entities, capabilities, activities, and consequences exist or apply.

Time determines when state was valid, available, observed, or known.

Search, Graph, Spatial, Temporal, and Vector infrastructure provide complementary ways to discover and reason over these dimensions while canonical authority remains in the underlying RSM state.

#25.3 Governing Implementation Principle

The Technology & Infrastructure Architecture can therefore be summarized by one rule:

Build every architectural doorway now, but install only the machinery required today.

PostgreSQL and PostGIS provide the initial operational substrate. Go provides the canonical runtime. JSON-LD, RDF, and SHACL provide semantic interoperability. Explicit ports preserve the path to graph engines, vector systems, model providers, message infrastructure, and specialized geospatial services.

The result is an architecture that begins simple without becoming structurally temporary.