Developers & integrators

Build on the model.
Keep authority explicit.

RSM is designed to be consumed through protocol and SDK boundaries. Applications, agents and connectors remain free to evolve without becoming hidden systems of record.

Understand the model

Start with the Concept Paper and Subject Model. Learn the distinctions before turning them into types.

Start with why →

Use the protocol

Applications should call RSM operations, not canonical tables. Authority and idempotency live at that boundary.

Protocol specification →

Integrate existing systems

Map identity, semantics and provenance through a Connector. Keep the source system authoritative where it legitimately is.

Integration architecture →

Prove conformance

Run positive and negative suites. RSM is real only when invalid transitions fail at the correct boundary.

Conformance →

The dependency rule

Applications never own the canonical shortcut.

The intended path stays the same whether the consumer is Ryzosphere, Wellzai, a laboratory connector or a future autonomous agent.

Application / Agent / Connector
        │
        ▼
   RSM Client / SDK
        │
        ▼
   RSM Protocol
        │
        ▼
   RSM Runtime
        │
        ▼
Canonical + Semantic State

✓ authority evaluated
✓ provenance retained
✓ idempotency enforced
✓ projection remains non-authoritative

Integration rules

Five rules that keep the ecology trustworthy.

RSM is permissive about implementation technology and strict about semantic boundaries.

Map identity explicitly.

Name similarity is not identity resolution.

Preserve provenance.

Every imported fact should remain traceable to its source.

Do not bypass canonical admission.

Connectors create operations, not privileged database rows.

Separate authentication from authority.

A valid login is not permission to commit on behalf of a Subject.

Treat projections as disposable.

Search, graph, spatial and vector systems are optimized views, never hidden truth.

Build on the model.Keep authority explicit.