Developers

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.

DEVELOPER PATH

Developer path

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.

Application / Agent / Connector
        |
        v
   RSM Client / SDK
        |
        v
   RSM Protocol
        |
        v
   RSM Runtime
        |
        v
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.