Distinctions That Must Not Collapse

1. Quiet failures and the families of distinction

The conceptual reference on which RSM is built states the requirement in one sentence: implementations must not collapse ecological evidence, market requirements, participant claims, evaluations, configurations, formations or outcomes into a single undifferentiated representation. The list is worth reading slowly. Every item on it is something that ordinary software would happily store as a row in the same table, distinguished at most by a status column. And every item answers a different question: what was observed, what is wanted, what someone says, what an evaluator concluded, what could work, what has actually been organized, and what in the end happened.

A collapsed distinction is dangerous precisely because it produces confident answers. A system that cannot tell capability from capacity does not report that it does not know how much is available; it reports a quantity. A system that cannot tell a claim from evidence does not flag the claim as unsupported; it treats it as support. The failure is not a gap in the data but an answer that sounds more certain than anything the network actually knows.

The canonical model groups its invariants into families, and the grouping is a useful guide to where coordination is exposed. Agency distinctions keep apart a Self and an organization, a person and the role they play, participation and representation. Association and authority distinctions keep apart affiliation, membership and the authority to act. Core distinctions keep apart capability and capacity, offers and capabilities, claims, evidence and assertions. Formation distinctions keep apart intent, configuration, formation, activity and outcome. And cross-layer distinctions keep apart views and authority, derived conclusions and canonical facts, history and current state. The agency and authority families carry enough weight to need their own treatment, in Affiliation Enables Representation, Not Participation. The rest are taken in turn below.

2. What can be done, and how much is available

The first core distinction is the one RSM names in the title of a whole section of its Concept Paper. Capability is what a person, an organization or a facility can credibly contribute. Capacity is how much of that capability is available, bounded by quantity, period, place and state. A capability may exist with no current availability at all. A facility can be constrained in a period even when the organization that operates it is generally capable. The canonical model's instruction for capacity is short and unambiguous: consult it; never infer it from capability.

The reason is that the two answer different questions for different decisions. Discovery asks who could contribute; configuration has to ask who can, in this season, at this place, in this quantity. If the second is inferred from the first, a formation is assembled around supply that does not exist, and the shortfall is discovered only when someone acts on it. The reference implementation's specification lists "treating an inferred Capability as committed Capacity" among the shortcuts that would mean the architecture had not been correctly realized.

A neighbouring distinction separates an Offer from the capability behind it. An offer is a participant-governed expression of willingness to make something available. It is directional and situational, not a permanent classification of the participant as a seller, just as a seek does not make anyone a buyer. Keeping offer and capability apart protects both directions of reasoning. A system that knows only offers cannot see what participants could do but have not advertised, which is often where the possibility for a new formation lies. A system that treats every capability as an offer assumes a willingness no one has expressed.

Underneath both sits the oldest distinction in the model: an entity is not a role. The same organization may act as processor, buyer, storage provider or market participant in different contexts, and the same person may be a producer in one formation and an advisor in another. Identity persists while roles change. Encoding roles as fixed types forces a choice between duplicating identities and losing the roles, and both corrupt the history the network depends on.

3. What is observed, said, shown and concluded

The second cluster of core distinctions concerns knowledge. RSM separates five things that most systems blur into one notion of data. An Observation records what was observed about a subject at a particular time, under identifiable conditions and by an identifiable method. Evidence is information used to support, challenge or evaluate a proposition, and is not equivalent to truth; its provenance, quality, method and relevance remain material. A Claim is a proposition asserted by an identifiable actor. An Evaluation applies a stated predicate, policy or method to relevant evidence in a defined context. An Assertion is the governed result of that evaluation, which can be communicated to another party.

The conceptual reference gives an illustration that makes the separation concrete. A soil test result is an observation or evidence. "Soil organic matter is improving" is a claim. "This field satisfies the soil condition required by a particular procurement programme" is an evaluation-derived assertion. They are related, and each can support the next, but they are not interchangeable, and the model requires that it remain possible to say which actor made which observation or claim and which evidence supports it. When the separation holds, a participant can say something without it being mistaken for proof, an evaluator can reach a conclusion without that conclusion being mistaken for the measurements behind it, and an assertion can be shared without the evidence travelling with it. That last property is the foundation of the disclosure architecture described in Answer the Question, Keep the Evidence.

Two further distinctions in this cluster protect against a market quietly deciding what is true. A requirement is not ecological truth: the demand side may require a condition, but that condition has to be evaluated against appropriate evidence about the land or the living system. And a market extension to the model cannot redefine a procurement requirement as ecological evidence, any more than a domain extension can redefine a desirable practice as an outcome. A related rule addresses absence. Unknown is not false: missing or inaccessible evidence does not establish that a proposition is unsatisfied, a point developed in the Seednote Unknown Is Not False. The conceptual reference adds one more, aimed at a common shortcut: certification may evidence specified requirements, but certification is not regeneration, which has to be understood through observed trajectories and outcomes.

4. What was wanted, what was possible, what happened

The formation family protects the stages through which something moves from desire to reality. An Intent is a desired state. It is not a Commitment, because interest in a future condition does not establish willingness or obligation to contribute to it. A Configuration is a hypothetical arrangement of participants, capabilities, capacity, resources, relationships and dependencies that could satisfy an intent; it is not a Formation, which is an actual organized arrangement established through commitments and an authorized act. A configuration is not a Pathway either: one describes what must come together, the other how the arrangement could progress. A Recommendation is not a commitment, and formation readiness, a judgement that enough is in place, is not the formation itself. Why that boundary between possibility and agreement is the most consequential in coordination is the argument of Possibility Is Not Agreement.

Once a formation acts, two more distinctions take over. A planned activity is not an actual activity; in the canonical model an activity is recorded only when it is reported as having occurred. And an activity is not an outcome: performing a regenerative practice is not proof of a regenerative result. Finally, intent is not outcome. What was hoped for and what resulted are evaluated independently, so that the second can be compared with the first instead of being written over it, which is the ground of the argument in Biography, Not Profile.

Read together, these pairs describe the stages of becoming that a regenerative system passes through. Collapsing any two of them erases a stage, and each stage marks a place where someone has to decide something: whether to commit, whether the conditions for establishment are met, whether what happened is what was intended. A model that cannot represent the stage cannot represent the decision.

5. Views, conclusions and the authority behind them

The cross-layer distinctions concern the relationship between a system and its own outputs, which makes them easy to lose sight of even in carefully built software. A projection is not authority: every view, whether a map, a profile, a network diagram or a biography, is a governed projection and never the source of truth for what it shows. Visibility is not permission: being able to see something does not authorize using it. A graph is not the living network: it is one computational projection of an evolving system of entities, relationships, biographies, commitments, activities and outcomes. And historical evidence is not current state: what was true of a participant three seasons ago is part of their biography, not a description of today.

The most important of these for an intelligent system is that derived intelligence is not canonical fact. Relevance, viability, gaps, leverage and recommendations are conclusions computed about the network. In RSM they must carry the inputs and the reasoning version that produced them, so that they can be recognized as stale when those inputs change and never be mistaken for something a participant asserted or did. The conceptual reference applies the same rule to artificial intelligence directly: AI-generated interpretations must remain distinguishable from observations, authoritative evidence, participant commitments and governed assertions. What follows from that for models and agents is taken up in Models Propose, Participants Commit.

A last group of cross-layer distinctions describes what the network is not. The persistent network is not a marketplace. A community is not a social feed, and it is not the bounded reasoning space opened for one outcome. These read like definitions, but they work as boundaries: they stop the shared foundation from being reshaped, one convenience at a time, into an application that happens to be in the room.

6. Why the distinctions belong in the type system

It would be possible to honour all of these distinctions with discipline alone: careful naming, status fields, code review. RSM's semantic architecture refuses that option. Its design rule is that pairs the canonical model keeps apart are different classes, "never flags". Capability and capacity are disjoint kinds, and capacity binds to a capability and carries its own quantity, period, place and state. An offer is disjoint from a capability. A configuration is disjoint from a formation. A derived instance must name what it was derived from and which reasoning version produced it, or it is not valid.

The difference between a class and a flag is the difference between a boundary and a reminder. A flag can be defaulted, forgotten, flipped by a bulk update or ignored by a downstream consumer that never knew it existed. A separate kind cannot be passed where the other is expected without the mismatch being visible. The canonical model makes the same demand of storage: whatever the physical design, certain firebreaks must be physically real, among them participant-as-role, capability and capacity, configuration and formation, and the rule that the space reasoning about an outcome references persistent objects without owning them.

The distinctions also have to hold in behaviour, not only in structure. When building the reference kernel reached concepts the canon names but cannot yet express, the right response was to refuse the operation and record the gap as governance work, rather than invent a meaning to make the request succeed. That experience is recorded in the Fieldnote Fail Closed When the Canon Is Silent.

The RSM Canonical Model & Protocol draws the conclusion that makes all of this more than style. Its invariants, it says, are more fundamental than any serialization format or interface design, and an implementation that violates them is not semantically compatible with RSM even if it uses the same field names. The reference implementation's specification turns the same idea into a test: it must never require treating a configuration as a formation, an inferred capability as committed capacity, a recommendation as a commitment, an activity as proof of outcome, an assertion as its underlying evidence, a graph projection as canonical truth, or Wellzai as the owner of participant state. Compatibility, on this view, is not agreement about names. It is agreement about which things are different.

That is finally why the distinctions matter beyond any single system. Many independently governed participants can rely on one another's statements only if each knows what kind of statement it is receiving: a measurement or a claim, an offer or a commitment, a possibility or an arrangement, a view or an authority. The distinctions are the part of the shared model that makes trust between systems something other than hope.

Sources

• RSM Concept Paper v3.0, §6 Capability is not Capacity; Intent is not Outcome.
• RSM Canonical Model v3.0, §3.3 The anti-collapse rules; §6 Capability, Capacity, Resource, Constraint, Expressions; §7 Knowledge, Coordination, Reality, Memory; §10 Invariants; §11 Logical Realisation Notes.
• RSM Semantic Model and Taxonomy Architecture v3.0, §1.2 Design rules; §7 How the Vocabulary Encodes the RSM Invariants.
• RSM Normative Conceptual Reference v1.1, §1 Purpose; §7 Observations, Evidence, Claims, and Assertions; §19.3 Network Intelligence; §22 Normative Distinctions.
• RSM Canonical Model and Protocol Specification v1.0, §18.2 Semantic Compatibility; §20.2 Unknown Is Not False; §23.1 Semantic Invariants.
• RSM Reference Implementation and Acceptance Specification v1.0, §28.3 Semantic Completion.