04Normative specification

RSM Canonical Model & Protocol Specification v2.0

Regenerative Systems Model — Normative Canonical and Interaction Specification

Status: Draft Normative Specification
Foundation: RSM Concept Paper — A Living Outcome-Forming Ecology
Source: docs/04-rsm-canonical-model-protocol-specification.md
Scope: Canonical state, canonical object families, identity, revision, provenance, lifecycle, authority-bearing relationships, Capability and Capacity, network expressions, evidence semantics, Commitment, Formation, Activity, Event, Outcome, derived-state boundaries, protocol operations, mutation semantics, idempotency, receipts, and canonical invariants
Related specifications: RSM Runtime & Federation Architecture; RSM Reference Implementation & Conformance Specification

#1. Purpose and Scope

#1.1 Purpose

The Regenerative Systems Model requires a clear boundary between information that participates in authoritative system state and information that merely describes, predicts, recommends, projects, or temporarily organizes that state. Without such a boundary, a discovered possibility can become indistinguishable from a Commitment, a machine-generated Configuration can masquerade as a Formation, an Activity can be mistaken for an Outcome, and a cached projection can acquire authority it does not possess.

The RSM Canonical Model & Protocol Specification defines that boundary. It establishes the object semantics through which durable RSM state is admitted, related, revised, revoked, and observed, together with the protocol grammar through which actors interact with that state under explicit identity, purpose, authority, policy, and provenance.

#1.2 Governing Question

The central question of this specification is:

What may RSM treat as authoritative durable state, and through what governed operations may that state be created, changed, observed, disclosed, or revoked?

The answer requires more than a data model. Canonical semantics and interaction semantics must remain aligned so that an object cannot acquire authority merely because an application wrote it to a database or an AI system emitted structurally valid JSON.

#1.3 Scope

This specification governs:

canonical object semantics;
canonical identity and revision;
provenance;
object-specific lifecycle;
authoritative relationships and participation;
Capability and Capacity;
Constraint;
Intent, Offer, Seek, and DemandExpression;
Observation, Claim, Evidence, Evaluation, and Assertion;
Commitment;
Formation;
Activity and domain Event;
Outcome;
canonical history and Biography semantics;
the boundary between Canonical, Derived, Operational, and Projection state;
protocol envelopes;
RSM protocol operations;
Actor, Principal, actsFor, Delegation, and Authority;
protocol validation;
idempotency;
optimistic concurrency;
mutation and revocation rules;
operation receipts and result semantics; and
canonical and protocol invariants.

Storage technology, database topology, event-store implementation, network transports, federation discovery, caching, projection infrastructure, and policy-engine implementation belong to the Runtime & Federation specification.

#2. Normative Language and Architectural Position

#2.1 Normative Terms

The terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY express normative requirements. SHALL identifies a requirement necessary for conformance, while SHOULD identifies a strong architectural expectation that may be departed from only for a documented reason.

Examples and illustrative field structures in this document communicate required semantics rather than prescribing a particular programming language, serialization library, database technology, or API framework.

#2.2 Position Within RSM

The Canonical Model sits between semantic meaning and runtime execution:

Figure 1

Rendering diagram...

The Semantic Model defines vocabulary and semantic interpretation. This specification defines authoritative RSM state that references those semantics, while the Runtime determines how canonical objects are persisted, distributed, reconciled, protected, and projected.

#2.3 Canonical Does Not Mean Universally True

CANONICAL means that an object has been admitted as authoritative RSM state within a defined authority boundary according to the applicable validation, identity, provenance, lifecycle, policy, and authority rules. It does not mean that every proposition contained in the object is universally true.

A canonical Claim remains a Claim. Canonical Evidence remains Evidence. A canonical Observation remains a record of what an Observer reported or measured, while a canonical Assertion remains a governed conclusion attributable to an identifiable authority.

Canonicality therefore answers:

Is this the authoritative RSM record of this statement, object, relationship, commitment, observation, or occurrence within this authority boundary?

It does not answer:

Is every proposition represented by this record objectively and permanently true?

#3. Semantic Categories and the Canonical Boundary

#3.1 Four Semantic Categories

RSM SHALL preserve four architectural categories:

Category	Meaning
`CANONICAL`	Authoritative durable RSM state
`DERIVED`	Computed interpretation, possibility, or recommendation
`OPERATIONAL`	Runtime or application context for conducting work
`PROJECTION`	Non-authoritative view, map, cache, index, or representation

An object or artifact SHALL have only the authority appropriate to its category. Persistence duration, database location, user-interface prominence, or confidence score SHALL NOT silently alter category.

#3.2 Canonical State

Canonical state contains admitted facts of record, authoritative expressions, governed conclusions, commitments, activities, observations, occurrences, outcomes, and identity-bearing entities. Canonical state may be revised or superseded while retaining historical lineage.

Canonical state supplies the durable substrate from which reasoning, coordination, projections, and Biography can be reconstructed.

#3.3 Derived State

Derived state represents reasoning about canonical or otherwise authorized inputs. Typical derived artifacts include:

text

Candidate Relevance
Candidate Configuration
Viability Assessment
Capability Gap
Capacity Gap
Evidence Gap
Dependency Graph
Pathway
Coordination Recommendation
Formation Readiness
Match
Opportunity

A derived artifact MAY be durably stored for reproducibility, audit, or collaboration. Durability SHALL NOT make it canonical.

#3.4 Operational State

Operational state organizes work without asserting independent facts about the world. An Outcome Context, investigation context, coordination workspace, session, conversation continuation, or application workflow may persist for long periods while remaining operational.

Operational state MAY reference canonical and derived objects. It SHALL NOT become an authority merely because applications depend upon it.

#3.5 Projection State

Projection state is assembled for discovery, navigation, analytics, visualization, search, or performance. Examples include a network projection, profile projection, Map, Biography timeline, search index, or cached Capability view.

RSM SHALL preserve:

text

Projection ≠ Canonical
Derived ≠ Canonical
Operational ≠ Canonical
Recommendation ≠ Commitment
Configuration ≠ Formation

These distinctions form a structural firebreak between intelligence and authority.

#4. Canonical Object Architecture

#4.1 Canonical Object

A Canonical Object is an RSM object admitted into authoritative durable state under the rules of this specification. Canonical objects possess stable identity where identity is meaningful, semantic kind, revision or immutability semantics, provenance, and sufficient temporal context to interpret their state.

Canonical objects SHALL preserve their own object-specific invariants. RSM SHALL NOT require unrelated objects to share fields merely to satisfy a universal base-class design.

#4.2 Minimal Canonical Envelope

Identity-bearing mutable canonical objects SHOULD expose a common logical envelope containing:

yaml

id: https://id.rsm.org/...
kind: rsm:Organization
category: CANONICAL
revision: 7
createdAt: 2029-01-01T00:00:00Z
updatedAt: 2029-03-14T16:00:00Z
provenance:
  sourceRef: ...
  recordedBy: ...
  operationRef: ...

The exact physical representation MAY differ. The semantic meanings of identity, kind, category, revision, time, and provenance SHALL remain distinguishable.

#4.3 No Universal Owner or Agency Field

The canonical envelope SHALL NOT require universal nullable fields such as:

text

owner
agencyStatus
actsFor
commitmentState
quantity
authority

when those concepts do not apply to every kind. Authority and agency are contextual, while Capacity, Commitment, and ownership semantics belong to the appropriate object families.

The model favors explicit applicable semantics over a universal record populated mostly with null values.

#4.4 Object Families

Canonical RSM state is organized conceptually into six families:

foundational entities;
relationship and participation state;
capability and constraint state;
network expressions;
epistemic state; and
coordination, execution, and consequence state.

These families describe semantic responsibility rather than physical database modules.

#5. Identity, Revision, and History

#5.1 Canonical Identity

Canonical identity SHALL be durable, unique within its identity authority, and independent of mutable labels or domain classifications. Changing an Organization's name, adding a domain type, or altering a Facility's Capability SHALL NOT require replacing the entity's identity.

Identifiers SHOULD avoid embedding mutable business semantics where those semantics could later change.

#5.2 Identity Is Not Vocabulary

Entity identity SHALL remain distinct from semantic vocabulary identity:

text

rsm:Organization
    semantic class

rsm:food/processor
    domain concept

https://id.rsm.org/organization/01K...
    actual Organization identity

Using a Concept IRI as if it identified a real entity SHALL violate RSM identity semantics.

#5.3 Revision

Mutable canonical objects SHOULD maintain monotonically advancing revision semantics. A mutation performed against a known revision SHOULD be able to specify expectedRevision so that stale writers cannot silently overwrite newer authoritative state.

An operation encountering an incompatible current revision SHALL return an explicit conflict rather than resolving the conflict through last-write-wins behavior.

#5.4 History Is Not Overwrite

Historical canonical state SHALL remain reconstructable where policy and law permit. Updating an object SHALL NOT mean that previous authoritative state never existed.

The Runtime may implement history through append logs, revisions, snapshots, temporal tables, or another mechanism. This specification requires the semantic result: meaningful prior state and the provenance of change must remain recoverable.

#5.5 Deletion and Erasure

RSM does not define ordinary destructive deletion as a semantic operation. Domain lifecycle changes SHOULD use explicit transitions such as withdrawal, revocation, supersession, retirement, closure, or invalidation where those meanings apply.

Legal or privacy-driven erasure is an infrastructure and governance concern distinct from semantic revocation. Where erasure is required, implementations SHOULD preserve only the minimum tombstone or lineage information legally permitted and necessary to prevent identity reuse or historical corruption.

#6. Foundational Entity State

#6.1 Entity Kinds

The RSM Subject Model defines ten foundational identity-bearing kinds:

text

rsm:Person
rsm:Organization
rsm:Community
rsm:LivingSystem
rsm:Place
rsm:Facility
rsm:Material
rsm:Instrument
rsm:DigitalAgent
rsm:Formation

The Canonical Model SHALL preserve these distinctions. Domain specialization occurs through rsm:domainType, relationships, capabilities, roles, and Domain Packs rather than by replacing foundational kind.

#6.2 Canonical Entity Description

An entity may contain durable descriptive state appropriate to its kind, including name, domain types, relevant references, public descriptors, lifecycle state, and other governed attributes.

Descriptions SHALL distinguish self-declared information, imported information, observations, claims, and assertions where the provenance or epistemic standing matters. A description field SHALL NOT become an escape hatch for storing untyped authoritative claims.

#6.3 Foundational Kind Is Stable

Changing a domain type does not normally change foundational kind. An Organization becoming a processor, lender, certifier, or service provider remains the same Organization.

Where a modeling error incorrectly assigned foundational kind, correction SHOULD be handled explicitly through supersession or identity reconciliation rather than silently rewriting the meaning of historical records.

#7. Relationship and Participation State

#7.1 Relationship

A Relationship is first-class canonical state connecting two or more identifiable Subjects under a governed relationship type. A Relationship may possess lifecycle, temporal validity, provenance, conditions, and Biography independent of the entities it connects.

The relationship instance and relationship-type Concept SHALL remain distinct:

text

Relationship instance
    https://id.rsm.org/relationship/01K...

Relationship type
    rsm:relationship/operates

#7.2 Affiliation

An Affiliation records an association between a Person and an Organization or another supported context. Affiliation may represent employment, advisory association, professional association, or another declared connection.

Affiliation SHALL NOT by itself imply membership, participation, representation, or authority.

#7.3 Membership

A Membership records governed membership in a Community or another membership-bearing structure. Membership may include state, validity, membership class, or stewardship references as defined by the applicable domain.

RSM SHALL preserve:

text

Membership ≠ Authority
Membership ≠ Affiliation
Membership ≠ Participation

#7.4 Participation

A Participation records that an entity participates in a bounded context such as a Formation or Activity and MAY carry one or more contextual roles.

Participation does not rewrite identity. An Organization participating as buyer in one Formation may participate as supplier in another without acquiring a permanent foundational buyer or supplier type.

#7.5 Stewardship

Stewardship represents an explicit responsibility relationship toward a Community, Place, LivingSystem, Instrument, Formation, or another governed Subject. Stewardship may entail duties or decision rights depending upon the governing policy.

Stewardship SHALL NOT automatically imply representation or unrestricted authority. Any consequential authority derived from stewardship must be explicit.

#7.6 Delegation

A Delegation is canonical authority-bearing state through which a Principal grants an Actor permission to perform bounded operations on its behalf.

Delegation SHOULD identify at least:

principal;
delegate Actor;
permitted operations;
applicable Subjects or scope;
purpose constraints where applicable;
temporal validity;
delegation depth where re-delegation is permitted;
revocation state; and
provenance.

Authentication, employment, membership, or application access SHALL NOT substitute for Delegation where delegated authority is required.

#8. Capability, Capacity, and Constraint

#8.1 Capability

A Capability represents what a Subject can credibly do, provide, perform, produce, observe, transform, coordinate, or otherwise contribute. Capability describes potential function rather than current availability.

A Capability SHOULD reference:

capable Subject;
governed capability type;
applicable domain semantics;
relevant Place or operating scope where material;
conditions or qualifications;
evidence references where credibility matters; and
provenance.

#8.2 Capacity

Capacity represents the bounded availability of a Capability. Capacity SHALL reference a Capability and SHOULD express the quantity, time, Place, conditions, state, or other bounds that determine actual availability.

RSM SHALL preserve:

text

Capability ≠ Capacity

A Subject may possess Capability while exposing zero available Capacity for a requested period. Discovery SHALL NOT treat Capability alone as proof of available Capacity.

#8.3 Capacity Is Contextual and Temporal

Capacity may change independently of Capability. A Facility may retain milling Capability across many years while weekly available Capacity varies continually.

Consequential coordination SHOULD therefore reconcile current Capacity rather than relying indefinitely upon historical or projected availability.

#8.4 Constraint

A Constraint represents a condition that limits, conditions, excludes, or bounds what may be considered viable. A Constraint may apply to a Subject, Capability, Capacity, Intent, Commitment, Formation, Activity, or other governed context.

Constraints may include:

temporal limits;
geographic requirements;
regulatory conditions;
financial boundaries;
material specifications;
ecological thresholds;
policy restrictions;
infrastructure dependencies;
acceptance criteria; and
authority restrictions.

A Constraint MAY reference a governed Predicate when machine evaluation is required. The Predicate definition belongs to the Semantic Model, while the Constraint is canonical state declaring that the condition applies in this context.

#9. Intent and Network Expressions

#9.1 Intent

An Intent is a canonical expression of a desired future condition sponsored by an identifiable Actor or Principal. Intent describes what is sought, not what exists and not what eventually occurs.

An Intent MAY contain goals, boundaries, target Subjects, Place, time horizon, relevant constraints, priorities, and other information necessary to understand the desired state.

RSM SHALL preserve:

text

Intent ≠ Outcome
Intent ≠ Commitment
Intent ≠ Formation

#9.2 Offer

An Offer represents an authorized expression that something may be made available under stated conditions. The offered thing may concern Capability, Capacity, Material, Facility access, Instrument, expertise, service, Evidence access, or another governed contribution.

Offer SHALL NOT be treated as permanent seller identity. The same Subject may create Offers and Seeks in different contexts.

#9.3 Seek

A Seek represents an authorized expression of something a Subject wishes to find, obtain, accomplish, access, or make possible. Seek may be exploratory and need not contain the specificity required for a transactional demand.

Seek SHALL NOT imply that the desired thing currently exists or that the seeking Subject has committed to acquire it.

#9.4 DemandExpression

A DemandExpression is a richer canonical network expression describing a valued future condition together with requirements that may include quantity, quality, time, Place, acceptance criteria, economics, incentives, or conditional commitment state.

A DemandExpression may participate in market-facing coordination while remaining distinct from both Seek and Commitment.

#9.5 Expression Lifecycle

Offers, Seeks, and DemandExpressions MAY expire, be withdrawn, superseded, or become inactive. Expiration or withdrawal SHALL preserve historical fact rather than erase that the expression once existed.

An expired Offer does not automatically revoke an independent Commitment previously made from it.

#10. Epistemic Canonical State

#10.1 Observation

An Observation records something perceived or measured concerning a Subject. It SHOULD identify the Observer or responsible Actor, Subject, observed property, result, relevant procedure or method, temporal context, and provenance.

An Observation records what was observed. It does not by itself establish a universal conclusion about why that observation occurred.

#10.2 Claim

A Claim is a proposition attributable to an identifiable source. A Claim may be supported, challenged, unevaluated, disputed, or superseded without losing its identity as the proposition that was made.

Claim SHALL NOT contain a universal verified=true field that collapses Evidence and evaluation into the proposition itself.

#10.3 Evidence

Evidence is information used to support, challenge, contextualize, or evaluate a Claim, Predicate, Assertion, Outcome, or other proposition-bearing context.

Evidence SHALL remain distinct from the proposition it concerns. Evidence may itself have provenance, access restrictions, temporal relevance, sensitivity, and quality characteristics.

#10.4 Predicate

A Predicate is a governed semantic condition defined by the RSM Semantic Model or an active Domain Pack. Predicate is not ordinary canonical world state and SHALL therefore be referenced by semantic identity and version rather than recreated as an application-local canonical object for every use.

Examples include:

text

available capacity >= 500 tonnes
protein content >= 12.5 percent
distance <= 150 kilometers
certification status = active

Historical Evaluations SHALL retain which Predicate version governed the evaluation.

#10.5 Evaluation

An Evaluation records that an identifiable evaluator applied one or more Predicates, criteria, methods, or reasoning procedures to specified inputs and obtained a result.

Evaluation SHOULD reference:

evaluator;
Subjects or proposition evaluated;
Predicate or criteria version;
Evidence and Observation inputs;
applicable semantic environment;
evaluation result;
time; and
provenance.

A canonical Evaluation means that the Evaluation record is authoritative as the record of what was evaluated and concluded by that evaluator. It does not make the conclusion universally incontestable.

#10.6 Assertion

An Assertion is a governed conclusion adopted or attested by an identifiable authority within a defined scope. Assertion is stronger than Claim because it includes an authority basis and acceptance boundary.

RSM SHALL preserve:

text

Observation ≠ Claim
Claim ≠ Evidence
Evidence ≠ Evaluation
Evaluation ≠ Assertion
Claim ≠ Assertion

An Assertion may later expire, be superseded, revoked, or challenged without rewriting the history of its prior existence.

#11. Commitment

#11.1 Definition

A Commitment represents an authoritative undertaking by a Principal to contribute, reserve, perform, provide, refrain from, or accept something under defined conditions.

Commitment marks a fundamental transition in the RSM ecology because it converts a possible contribution into accountable obligation.

#11.2 Commitment Requirements

A consequential Commitment SHOULD identify:

committing Principal;
Actor performing the operation;
authority basis where Actor and Principal differ;
committed subject, Capability, Capacity, Material, Instrument, Activity, or other contribution;
quantity or scope where applicable;
applicable Formation or purpose;
conditions precedent;
validity period;
withdrawal or revocation rules;
state; and
provenance.

A Commitment SHALL NOT exist merely because a recommendation predicted that the participant would probably agree.

#11.3 Conditional Commitment

RSM MAY represent conditional Commitments whose effectiveness depends upon explicit conditions, such as minimum demand, financing approval, certification, infrastructure completion, or commitments from other participants.

Conditional state SHALL remain distinguishable from active unconditional Commitment. A reasoning engine MAY evaluate whether conditions appear satisfied, but authoritative activation requires the applicable canonical transition.

#11.4 Commitment Lifecycle

An illustrative Commitment lifecycle may include:

text

PROPOSED
    ↓
CONDITIONAL
    ↓
ACTIVE
    ↓
FULFILLED

Alternative terminal states may include WITHDRAWN, REVOKED, EXPIRED, or BREACHED where domain semantics support them.

The exact lifecycle MAY vary by Commitment type, but implementations SHALL preserve the distinction between proposal, accepted obligation, and historical completion.

#12. Formation

#12.1 Definition

A Formation is a bounded, identity-bearing arrangement of participants, commitments, responsibilities, governance, and purpose that has actually come together sufficiently to coordinate Activity.

Formation is canonical because the existence of the arrangement itself becomes durable system state once the applicable establishment criteria have been satisfied.

#12.2 Configuration Is Not Formation

A candidate Configuration is derived reasoning about what might work. Formation records what has actually assembled under sufficient Commitment and governance.

RSM SHALL preserve:

text

Configuration ≠ Formation
Recommendation ≠ Formation
Formation Readiness ≠ Formation
Proposal ≠ Formation

No confidence score or reasoning result may bypass the establishment boundary.

#12.3 Formation Establishment

Formation establishment SHOULD require:

a defined purpose;
identifiable participants;
required active or conditionally satisfied Commitments;
governance appropriate to the Formation;
authority to establish it;
satisfaction of mandatory constraints;
provenance; and
an establishment operation or equivalent canonical transition.

The specific sufficiency rules may be domain-specific and may be evaluated through governed Predicates or policy. The resulting state transition must nevertheless remain authoritative and inspectable.

#12.4 Formation Agency

A Formation may become an Actor only where governance and authority support such agency. The mere existence of a Formation SHALL NOT automatically grant it unrestricted authority over participants or their underlying state.

A Formation may act through an authorized Person, Organization, or DigitalAgent whose representation and authority remain explicit.

#12.5 Formation Lifecycle

A Formation MAY transition through states such as:

text

ESTABLISHED
ACTIVE
SUSPENDED
COMPLETED
DISSOLVED

A completed or dissolved Formation remains historically identifiable. Its participants return fully to the wider persistent ecology and may participate in later Formations.

#13. Activity, Event, and Transformation

#13.1 Activity

An Activity records action that has actually begun, occurred, or been completed in the world or operational system. Planned work that has not begun SHOULD remain represented through Intent, proposal, Commitment, schedule, or operational planning rather than being recorded as completed Activity.

Activity MAY reference:

Actor or responsible Subjects;
Formation;
activity type;
affected Subjects;
input Materials;
output Materials;
Instruments;
Place;
start and completion time;
related Commitments;
Evidence; and
provenance.

#13.2 Activity Is Not Outcome

Activity records what was done. It SHALL NOT serve as proof that the intended consequence occurred.

RSM SHALL preserve:

text

Activity ≠ Outcome
Completion ≠ Success
Execution ≠ Evidence of consequence

The distinction is required even when an Activity was executed exactly as planned.

#13.3 Domain Event

An Event represents a meaningful occurrence in the modeled world or operational domain. Examples include harvest completion, shipment arrival, equipment failure, permit issuance, flooding, Commitment breach, or certification expiration.

A canonical Event SHOULD identify what occurred, affected Subjects, occurrence time, source, and provenance.

#13.4 Domain Event Is Not Infrastructure Event

RSM SHALL distinguish:

text

Domain Event
    modeled occurrence in the ecology

Runtime Event / Change Notification
    infrastructure message concerning system state

An infrastructure event may announce that a canonical Event or other object was created. The message and the domain occurrence SHALL NOT be treated as the same object merely because both are called events.

#13.5 Material Transformation

Activity may transform Materials and SHOULD preserve lineage between input and output identities where provenance matters.

For example:

text

Grain Lot A
    input-to → Milling Activity

Milling Activity
    produces → Flour Lot B

Flour Lot B
    derived-from → Grain Lot A

Transformation SHALL create new Material identity where the resulting material requires independently meaningful provenance, custody, observation, or lifecycle.

#14. Outcome

#14.1 Definition

An Outcome is an evaluated consequence concerning one or more Subjects after relevant Activity, Event, or other system change. Outcome records what the system has sufficient basis to say changed, rather than what participants hoped would change.

An Outcome SHOULD identify:

affected Subjects;
Outcome type;
temporal scope;
relevant Activity or Events;
supporting Observations;
Evidence;
Evaluations or Assertions where applicable;
uncertainty or qualification where required by domain semantics;
provenance; and
responsible evaluator or authority.

#14.2 Outcome Is Not Observation

Observation provides evidence concerning state. Outcome expresses an evaluated consequence that may require one or more Observations, baselines, criteria, comparisons, or other evidence.

A single measurement may sometimes support a simple Outcome, but RSM SHALL preserve the conceptual boundary.

#14.3 Outcome Is Not Intent

RSM SHALL preserve:

text

Intent ≠ Outcome
DemandExpression ≠ Outcome
Commitment ≠ Outcome
Activity ≠ Outcome
Observation ≠ Outcome

This prevents target achievement from being presumed merely because the target was declared, funded, or acted upon.

#14.4 Multi-Subject Outcomes

An Outcome may affect more than one Subject. A regenerative transition may have separate ecological, economic, community, Material, or human consequences whose evidence and timing differ.

RSM SHOULD represent those consequences explicitly rather than collapsing them into one universal regenerative score.

#15. Biography and Canonical History

#15.1 Biography as Semantic History

Biography represents the meaningful historical account accumulated around a Subject, Relationship, Formation, Material, Instrument, or other durable entity. It may include state transitions, Relationships, Commitments, Activities, Events, Observations, Assertions, Outcomes, and other relevant canonical history.

Biography is essential to RSM because future reasoning depends upon what happened previously, not merely upon current state.

#15.2 Biography Is a Projection, Not a Parallel Truth Store

Biography SHOULD normally be realized as a governed projection over canonical history rather than as a second independently mutable canonical object containing copies of historical facts.

This means:

text

Canonical revisions + Events + Relationships + Activities + Outcomes
        ↓
Biography Projection

Implementations MAY materialize Biography for performance. A materialized Biography SHALL remain a PROJECTION and must be reconstructable or reconcilable from authoritative history.

#15.3 Biography Is Not Current State

Historical state SHALL not silently become current truth. A previously active certification, available Capacity, valid relationship, or ecological Observation may no longer describe present conditions.

RSM SHALL preserve:

text

Biography ≠ Current State
Historical Observation ≠ Current Observation
Historical Capacity ≠ Current Capacity

#16. Derived Outcome-Formation Artifacts

#16.1 Purpose

Outcome Formation requires reasoning artifacts that are essential to coordination but should not be mistaken for world facts. RSM therefore defines their architectural category even though their detailed algorithms belong to intelligence systems such as Wellzai.

#16.2 Candidate Configuration

A Candidate Configuration represents a proposed combination of Subjects, Capabilities, Capacity, Materials, Instruments, relationships, constraints, and other elements that could potentially satisfy an Intent.

Candidate Configuration is DERIVED. It SHALL carry sufficient references to identify the canonical or authorized inputs from which it was constructed.

#16.3 Gap

A Gap represents a derived finding that a condition required for viability is absent, insufficient, unresolved, or unavailable. Examples include Capability Gap, Capacity Gap, Evidence Gap, infrastructure gap, financing gap, policy gap, or relationship gap.

Gap is not the missing canonical object itself. It is a reasoning conclusion about what is currently insufficient.

#16.4 Dependency

A Dependency represents a derived or operational relationship indicating that one required condition depends upon another condition being satisfied. A dependency graph may order Pathway steps or expose bottlenecks.

Dependencies SHALL NOT become canonical Relationships unless an independently meaningful persistent Relationship exists and is explicitly admitted canonically.

#16.5 Pathway

A Pathway represents a derived sequence or graph of changes that may make a desired future state viable. It may include proposed Activities, prerequisite Instruments, required Capacity, conditional Commitments, and other steps.

Pathway is not a Commitment and is not proof that the proposed sequence will succeed.

#16.6 Recommendation and Formation Readiness

A Recommendation expresses a derived suggested action. Formation Readiness expresses a derived assessment concerning whether required canonical conditions appear sufficient for establishment.

Neither artifact has authority to establish a Formation. Formation creation remains a governed canonical transition.

#16.7 Derived Artifact Requirements

Consequential derived artifacts SHOULD identify:

input references;
semantic environment;
reasoning implementation or version;
relevant assumptions;
applicable time;
derivation provenance; and
category DERIVED.

Derived objects SHALL NOT be accepted by the canonical repository merely by changing their category field.

#17. Protocol Design

#17.1 Purpose

The RSM Protocol defines a transport-independent behavioral grammar through which Actors interact with Subjects and canonical state. The protocol is concerned with semantic operation rather than whether the invocation arrives over HTTP, messaging, local function call, agent transport, or another mechanism.

Transport adapters SHALL preserve the operation semantics defined here.

#17.2 Interaction Grammar

The governing interaction pattern is:

text

Actor
    + Principal / actsFor
    + Authority
    + Purpose
    + Context
        ↓
Operation
        ↓
Subject
        ↓
Payload / Requested Effect
        ↓
Validation + Policy + Authority
        ↓
Canonical Mutation, Derived Result, Projection, or Rejection
        ↓
Receipt

The presence of a valid Actor or authenticated connection does not guarantee permission to perform the requested operation.

#17.3 Core Protocol Operations

RSM defines the following core operations:

text

DESCRIBE
OBSERVE
OFFER
SEEK
RELATE
CLAIM
ASK
EVALUATE
PROPOSE
COMMIT
ACT
ATTEST
DISCLOSE
LEARN
REVOKE

Not every Actor or endpoint must support every operation. Unsupported operations SHALL return explicit protocol results rather than being interpreted as negative domain conclusions.

#18. Protocol Envelope

#18.1 Request Envelope

A protocol request SHOULD contain enough information to determine operation identity, Actor, represented Principal where applicable, Subject, purpose, semantic environment, temporal context, concurrency expectation, and correlation.

An illustrative request is:

json

{
  "operationId": "op-87431",
  "operation": "ASK",
  "actorRef": "https://id.rsm.org/digital-agent/01KAGENT",
  "actsFor": "https://id.rsm.org/formation/01KFORM",
  "subjectRef": "https://id.rsm.org/organization/01KFARM",
  "purpose": "evaluate-wheat-capability",
  "timestamp": "2029-03-14T18:00:00Z",
  "semanticEnvironment": "rsm-env:4.0/agriculture-1.2/food-1.1",
  "correlationId": "corr-452",
  "payload": {
    "question": "available-food-grade-wheat-capacity"
  }
}

Transport credentials, cryptographic proofs, or protocol-specific authorization tokens MAY travel outside the semantic envelope. Their verification must nevertheless resolve to the Actor and authority semantics represented by the operation.

#18.2 Operation Identity

operationId SHALL uniquely identify a consequential operation within its idempotency scope. Retrying the same operation after an uncertain transport result SHALL not create duplicate canonical effects.

A client SHALL NOT reuse one operationId for semantically different requests.

#18.3 Actor

actorRef identifies the entity performing the operation. The Actor must be of a kind and state capable of the requested operation.

A Subject being acted upon SHALL NOT automatically be assumed to be the Actor.

#18.4 actsFor

actsFor identifies the Principal whose authority the Actor is exercising when the Actor is not acting solely on its own behalf. actsFor SHALL be explicit when consequential representation matters.

Employment, authentication, membership, or possession of application credentials SHALL NOT cause actsFor to be inferred automatically.

#18.5 Subject

subjectRef or equivalent references identify what the operation concerns. Operations MAY concern multiple Subjects where the semantic operation requires them.

The Subject need not possess agency.

#18.6 Purpose

Consequential operations SHOULD identify purpose where authority or disclosure is purpose-bounded. Purpose allows policy systems to distinguish, for example, discovery access from contracting access or research disclosure from public disclosure.

Purpose SHALL NOT be treated as free-form decoration when policy decisions depend upon it.

#18.7 Expected Revision

Mutating operations MAY specify expectedRevision for affected canonical objects. Where supplied, the operation SHALL fail with an explicit conflict if the current canonical revision is incompatible.

This provides transport-independent optimistic concurrency.

#19. Operation Semantics

#19.1 DESCRIBE

DESCRIBE communicates or changes authorized descriptive canonical state about a Subject. It may create or update entity description, supported domain types, declared Capabilities, public characteristics, or other semantics explicitly allowed by the target object's model.

DESCRIBE SHALL NOT be used to bypass more specific operations such as COMMIT, OBSERVE, CLAIM, or ATTEST. Describing a commitment in prose does not create a canonical Commitment.

#19.2 OBSERVE

OBSERVE records a canonical Observation. The operation SHALL identify an authorized or attributable Observer, the Subject observed, and sufficient measurement or observation context for the resulting Observation to be meaningful.

OBSERVE SHALL NOT automatically create an Assertion or Outcome.

#19.3 OFFER

OFFER creates, updates, withdraws, or otherwise transitions an Offer under the authority of the offering Principal.

The offered contribution and any referenced Capacity SHALL remain distinct. Creating an Offer concerning a Capability does not fabricate current Capacity.

#19.4 SEEK

SEEK creates or changes a Seek or, where the payload satisfies the richer semantics, a DemandExpression. Implementations SHALL preserve the semantic difference between an exploratory Seek and demand carrying acceptance criteria, quantities, or conditional economic terms.

SEEK SHALL NOT create a buyer identity class.

#19.5 RELATE

RELATE proposes, establishes, updates, or terminates a canonical Relationship, Affiliation, Membership, Participation, or other relationship-bearing state according to the relationship type's governance rules.

Some relationship types may be unilateral, while others require acceptance or multi-party consent. The protocol SHALL honor the governance semantics of the relationship type rather than impose one universal consent rule.

#19.6 CLAIM

CLAIM records a canonical Claim attributable to the claiming source. It does not establish that the Claim is supported, verified, accepted, or authoritative beyond the fact that the Claim was made.

Evidence and Evaluation remain separate.

#19.7 ASK

ASK requests authorized information, evaluation input, semantic description, or another non-mutating answer. The response may contain canonical references, projections, Evidence, Assertions, derived results, or explicit unavailable and indeterminate states.

An unsuccessful ASK SHALL distinguish at least:

text

NOT_FOUND
UNAVAILABLE
NOT_AUTHORIZED
INDETERMINATE
UNSUPPORTED

Absence of accessible information SHALL NOT be converted automatically into a negative domain answer.

#19.8 EVALUATE

EVALUATE applies governed Predicates, criteria, or evaluation methods to specified Subjects, Claims, Evidence, Observations, or other inputs.

Where the Evaluation itself is admitted as canonical state, it SHALL preserve evaluator, inputs, Predicate version, result, provenance, and relevant semantic environment.

#19.9 PROPOSE

PROPOSE communicates a proposed change, Configuration, agreement, Formation, Commitment, Pathway step, or other prospective action without creating the authoritative consequence being proposed.

A proposal MAY be operational or derived depending upon its semantics. PROPOSE SHALL never be treated as implicit consent.

#19.10 COMMIT

COMMIT creates or transitions an authoritative Commitment under validated Principal authority. Because Commitment changes the accountability state of the ecology, COMMIT is consequential and SHALL require idempotency, authority evaluation, policy evaluation, and applicable concurrency checks.

A successful COMMIT SHALL return the canonical Commitment identity and resulting revision or state.

#19.11 ACT

ACT records or advances an Activity that has actually begun or occurred under applicable authority. Planned future work that has not begun SHOULD remain represented as Commitment, proposal, schedule, or operational state.

ACT SHALL NOT create an Outcome automatically upon Activity completion.

#19.12 ATTEST

ATTEST creates or changes an Assertion under identifiable authority. The operation SHOULD reference the Claim, Observation, Evidence, Evaluation, or other basis supporting the attestation where those references are available.

An Actor SHALL not attest beyond its governed authority merely because it has access to the underlying Evidence.

#19.13 DISCLOSE

DISCLOSE releases authorized information or a purpose-bounded projection to a requesting context. The operation does not transfer canonical ownership of the disclosed Subjects and does not turn the disclosed projection into an authoritative source.

Disclosure SHOULD produce an auditable receipt sufficient to determine what class of information was disclosed, to whom, under what purpose and authority, without unnecessarily duplicating protected content into the audit record.

#19.14 LEARN

LEARN communicates a structured learning or proposed update arising from Biography, Outcome, repeated experience, or derived reasoning. LEARN SHALL NOT create truth merely because a machine or participant inferred a pattern.

A learning operation may result in a new Claim, proposed Capability change, relationship update, domain-specific semantic artifact, or other canonical mutation only after the appropriate validation and acceptance boundary is crossed.

#19.15 REVOKE

REVOKE withdraws or terminates an applicable authority, Delegation, Commitment, Offer, Assertion, disclosure grant, or other revocable state according to its lifecycle rules.

Revocation SHALL preserve historical provenance and SHALL NOT erase the fact that the prior state existed and was once active.

#20. Authority, Representation, and Policy

#20.1 Authentication Is Not Authority

Authentication answers who or what is interacting with the system. Authority answers whether that Actor may perform a specific operation concerning a specific Subject, Principal, purpose, and context.

RSM SHALL preserve:

text

Authentication ≠ Authority
Capability ≠ Authority
Affiliation ≠ Authority
Membership ≠ Authority
Agency ≠ Authority

#20.2 Principal

A Principal is the entity whose authority, interest, or accountable standing is exercised through a consequential operation. A Person may be its own Principal, while a DigitalAgent may act for an Organization or Formation.

The Principal and Actor MAY be the same entity. When they differ, representation SHALL be explicit.

#20.3 Authority Basis

Authority may arise from direct control, governance position, Delegation, statutory authority, contractual authority, Formation governance, or another governed basis.

Protocol processing SHOULD produce enough traceability to identify the authority basis used for consequential acceptance.

#20.4 Delegated Operations

A Delegation MAY restrict:

operation types;
Subject scope;
Principal scope;
purpose;
time;
data sensitivity;
monetary or quantitative bounds;
re-delegation;
Place; and
other domain-specific constraints.

An operation outside any applicable bound SHALL fail even when the Actor is authenticated and technically capable of invoking it.

#20.5 Policy

Policy evaluation determines whether the operation is permitted under current governance. Policy MAY consider Actor, Principal, authority basis, purpose, Subject, operation, semantic category, lifecycle, Place, sensitivity, relationship state, and other context.

A policy denial SHALL remain distinguishable from semantic invalidity and technical failure.

#21. Canonical Mutation Semantics

#21.1 Mutation Boundary

Canonical mutation SHALL occur only through an explicit acceptance boundary that performs the applicable semantic, structural, reference, lifecycle, authority, policy, and concurrency checks.

Writing directly to underlying storage SHALL NOT constitute a conformant canonical mutation mechanism.

#21.2 Validation Sequence

A conformant implementation SHOULD conceptually evaluate a mutating request through the following stages:

Figure 2

Rendering diagram...

Implementations may optimize or combine stages internally, but observable results SHALL preserve the distinctions necessary for explainability.

#21.3 Atomicity

When one protocol operation requires several canonical changes to preserve an invariant, those changes SHOULD be committed atomically or fail as one semantic operation.

A Formation establishment operation, for example, SHALL not leave the system in a state where the Formation exists canonically while mandatory establishment relationships failed to commit.

#21.4 Mutation Does Not Rewrite Provenance

A later mutation SHALL preserve or supersede earlier provenance rather than making the new Actor appear to have originated historical state.

Each consequential revision should remain attributable to the operation that produced it.

#22. Idempotency and Concurrency

#22.1 Idempotency

Consequential protocol operations SHALL support idempotent retry. Retrying an operation because a response was lost SHALL not create duplicate Commitments, Activities, Formations, Assertions, or equivalent canonical effects.

For example:

text

operationId:
    commit-green-valley-2029-wheat-v1

first submission:
    APPLIED

retry:
    ALREADY_APPLIED

canonical Commitment:
    same identity
    same semantic effect

#22.2 Idempotency Conflict

If the same operationId is reused with a semantically different payload, the implementation SHALL reject the request as an idempotency conflict rather than guessing which request the client intended.

#22.3 Optimistic Concurrency

Where canonical objects are mutable, expected revision checks SHOULD prevent stale updates. A caller operating on revision 7 SHALL not silently overwrite revision 8.

A concurrency conflict is not semantic invalidity. The caller may need to reconcile current state and issue a new operation.

#22.4 Duplicate Observation and Event Handling

Idempotency does not imply that similar Observations or Events are duplicates. Two independent soil tests returning the same value may legitimately be two canonical Observations.

Duplicate detection SHALL use operation or source identity where applicable rather than payload similarity alone.

#23. Protocol Results and Receipts

#23.1 Receipt

Every consequential operation SHOULD return or make available an immutable receipt sufficient to explain the disposition of the request. A receipt is not itself the canonical object created by the operation.

An illustrative receipt may include:

json

{
  "operationId": "commit-green-valley-2029-wheat-v1",
  "status": "APPLIED",
  "actorRef": "https://id.rsm.org/person/01KMARIA",
  "actsFor": "https://id.rsm.org/organization/01KFARM",
  "canonicalRefs": [
    "https://id.rsm.org/commitment/01KCOMMIT"
  ],
  "revisions": {
    "https://id.rsm.org/commitment/01KCOMMIT": 1
  },
  "recordedAt": "2029-03-14T18:04:32Z"
}

Transport-specific metadata MAY accompany the receipt without becoming part of the canonical protocol semantics.

#23.2 Result States

The protocol SHOULD distinguish at least:

Result	Meaning
`APPLIED`	Requested canonical effect was successfully committed
`ALREADY_APPLIED`	Idempotent retry of an already completed operation
`RETURNED`	Non-mutating operation successfully produced a result
`NO_CHANGE`	Request valid but produced no semantic state change
`REJECTED`	Request violated semantic or structural requirements
`UNAUTHORIZED`	Actor or authority basis was insufficient
`DENIED`	Policy prohibited an otherwise meaningful operation
`CONFLICT`	Revision, lifecycle, idempotency, or state conflict
`NOT_FOUND`	Requested identifiable object could not be resolved
`UNAVAILABLE`	Authoritative source or required state could not be reached
`INDETERMINATE`	Available information was insufficient for a definitive result
`UNSUPPORTED`	Target does not support the requested operation

Applications MAY map these results to transport-specific status codes. The semantic distinction SHALL remain observable.

#23.3 Unavailable Is Not False

RSM SHALL not convert unavailable authoritative state into a negative value. If current processor Capacity cannot be reached, the correct result is not automatically 0.

A projection may expose stale cached information with its age and authority limitations, but consequential processing must distinguish cached history from current authoritative state.

#24. Lifecycle and Revocation

#24.1 Object-Specific Lifecycle

RSM SHALL not impose one universal lifecycle state machine upon every canonical object. Formation, Commitment, Offer, Instrument, Relationship, and Assertion have materially different lifecycle semantics.

Each object family SHALL define the states and transitions that matter to its behavior.

#24.2 Valid Transition

A canonical lifecycle transition must be valid for the object's current state, Actor authority, policy, and applicable conditions.

An invalid transition SHALL fail rather than mutating the object into an impossible state.

#24.3 Supersession

Supersession replaces a prior semantic record with a newer authoritative record while retaining the earlier object's historical existence. Supersession is appropriate when the meaning or record has been replaced rather than simply withdrawn.

The successor SHOULD reference the superseded object where lineage matters.

#24.4 Revocation

Revocation invalidates or terminates authority or applicability prospectively according to object semantics. Revocation does not mean that the revoked object never existed.

A revoked Assertion, Delegation, or Commitment remains part of Biography.

#25. Disclosure and Projection Boundary

#25.1 Authoritative Source and Projection

RSM federation and applications frequently operate on projections rather than direct access to complete canonical state. The protocol must therefore preserve the distinction between the information returned and the authority behind it.

A projection SHOULD carry enough metadata to identify:

source or sources;
generation time;
applicable purpose;
semantic environment;
freshness where relevant;
authorization scope; and
whether consequential reconciliation is required.

#25.2 Purpose-Bounded Disclosure

A participant MAY disclose enough information for discovery without disclosing evidence, contractual terms, precise Place, or commercially sensitive Capacity. Later interactions may authorize deeper disclosure.

The protocol therefore supports progressive disclosure rather than assuming that network participation implies universal transparency.

#25.3 Projection Cannot Be Re-Imported as Truth

An application SHALL NOT take an RSM projection, modify it locally, and write it back as canonical state merely because the fields resemble the canonical object.

Canonical changes must cross the appropriate mutation boundary with authority and provenance.