Biography, Not Profile

1. Why current state is not enough

The RSM Canonical Model & Protocol puts the risk bluntly: an implementation that stores only the latest state risks destroying the biography that makes RSM useful. Its requirement is that material state changes be represented as events, or otherwise remain reconstructable from history, so that the network can always say how a participant, a relationship, a formation or the system as a whole arrived at its present condition. The protocol also states the negative form of the rule: a biography must not be implemented merely as an editable profile whose previous state disappears whenever the current representation changes.

The difference matters because almost every important question in coordination is a question about trajectory. Is a producer's food-grade capability newly declared or demonstrated across several deliveries? Has a processor's available capacity been stable, or did it fall short the last time it was relied on? Did a buyer that expressed demand go on to commit, and did it honour the commitment? The current state can answer none of these. A record that says "capable" looks the same whether it rests on years of observed performance or on a sentence typed yesterday.

This principle has also shaped what was built first. The corrected plan for the RSM reference kernel deferred biography projections, the views that present a participant's or a relationship's history, but made the history required to construct them mandatory from the start. Current state can change; the meaningful history behind it must remain reconstructable, and a material correction is recorded as an additional event or explicit revision, never as a destructive overwrite. A view can be added later. A history that was never kept cannot. How that ordering was reached is recorded in the Fieldnote The First Plan Had Semantic Debt.

2. What a biography is, and whose it is

In RSM a Biography is the temporally ordered, provenance-bearing record through which an entity, a relationship or a system becomes understandable over time. It is not one large document. It is a projection over durable history: assembled from observations, relationships, commitments, activities, events, assertions and outcomes associated with a subject, and capable of yielding different views for different purposes from the same underlying record. Different views of the same biography can be projected according to purpose and authorization, so a buyer evaluating a producer's capability need not, and should not, receive the producer's unrelated financial or operational history simply because it exists. Biography, in other words, is memory under governance, not memory made public.

The most distinctive feature of the model is who has a biography. Participants do, and so do living systems and facilities. But RSM also gives relationships biographies of their own. A producer–processor relationship may progress through discovery, feasibility evaluation, trial production, contracting, production, verification, delivery, settlement, renewal and expansion, and those events belong to the relationship rather than exclusively to either party. Wellzai's information architecture for Outcome Formation explains why this matters: a producer and processor that have coordinated successfully across several seasons represent a different network condition from two participants who are merely geographically compatible but have never worked together. A system that only records participants cannot see that difference. A system that records relationship histories can.

Formations have biographies too, and above them all sits a system biography: how the larger regenerative system changes through accumulated activity and outcomes, from new processing capacity established and practices validated to soil trajectories and habitat conditions. The conceptual reference gives that layer a pointed role. The system biography, it says, provides the basis for determining whether a network that calls itself regenerative is actually producing regenerative outcomes.

3. Withdrawal is history, and accountability runs both ways

A biography is only useful if it is honest about what did not happen as well as what did. RSM is explicit that permissions, offers, prospective commitments and delegations may be revoked where their meaning allows, but that revocation must not silently erase legitimate history. If a participant withdraws a commitment, its current state becomes withdrawn, and the biography preserves that the commitment existed and was later withdrawn. The runtime architecture adds that corrections should be represented through revision, supersession or another auditable mechanism, never by destructive replacement. That is not a punitive rule. Withdrawals happen for good reasons, and a network that erased them could neither learn from them nor give an accurate account of how a relationship actually developed.

The same discipline is applied evenly. Wellzai's information architecture for Outcome Formation describes biographical accountability as symmetric: the network should learn not only whether producers delivered but whether market participants converted their stated demand into commitments and fulfilled them. In many coordination systems, scrutiny falls almost entirely on supply, because supply is what can fail to arrive. A biography that records the demand side's conduct as carefully as the supply side's changes the incentives on both. A buyer's history of honoured commitments becomes as much part of the network's knowledge as a producer's history of deliveries.

4. Keep both numbers

The deepest reason RSM needs biography is that it refuses to let intention stand in for result. The Concept Paper says it directly: RSM does not treat the word regenerative as proof of a regenerative outcome. A participant may express regenerative intent, but actual ecological, social, economic, health or relationship outcomes require observation and appropriate evidence about real subjects, including living systems. Intent is a desired state; Outcome is what actually resulted, evaluated independently of the intent; and performing the planned activities does not establish that the intended outcomes occurred.

The reference implementation's specification turns this into a concrete requirement using an illustrative scenario that runs through the RSM documents. If an intent called for 10,000 tons of wheat and 9,740 were delivered, the system must preserve both values. It must compare the original intent with the observed outcome without rewriting the intent. The temptation in ordinary software is to update the target to match the result, or to record the delivery as a completed transaction and move on; either way, the gap between what was hoped for and what happened disappears, and with it the information the next attempt most needs.

Outcomes are also plural. The same specification asks that operational, economic, ecological and relationship outcomes be recorded, so that an outcome is never reduced to the completion of a transaction, and Wellzai's outcome model architecture adds that different outcome types require different evidence, without one universal measurement model imposed across them. Attribution needs equal care. Some outcomes are associated with a formation without being safely attributable to any one activity or participant, because living systems are complex and affected by events no one controls. The model therefore distinguishes observed association from causal attribution and requires appropriate evidence and methods before a causal claim is made. The shortcut it most wants to avoid is the one the Seednote Certification Is Not Regeneration names: mistaking evidence that a practice was followed for evidence of what the practice achieved.

5. Learning without rewriting history

A biography that only accumulated would be an archive. RSM wants a network that learns, and Wellzai's outcome model architecture defines learning narrowly and usefully: the network improves by comparing what it believed before coordination with what actually occurred. That requires keeping the beliefs as well as the results. Predictions and assumptions have to be preserved, not only the final outcome, or there is nothing to compare against. Learning can then update the network's understanding of capability reliability, capacity realization, relationship behaviour, dependency patterns, commitment conversion and the effectiveness of pathways.

The same documents are just as careful about what learning must not do. Patterns observed across many formations may inform future reasoning, but they must not silently rewrite historical evidence, and they must not convert statistical patterns into deterministic facts about individual participants. The reference implementation's specification puts the rule at its smallest scale: one scenario must not become a universal deterministic rule merely because it occurred once. A derived pattern carries provenance linking it to the history it came from and an honest statement of how limited its evidence is. Historical facts may shape a new reasoning cycle, but they remain distinguishable from current authoritative state and traceable to the events they came from; they are not timeless truths. The Seednote One Success Is Not a Rule takes up the question this leaves open, of when experience should become a prior.

Reasoning itself needs a biography of the same kind. Conclusions Wellzai derives are specified to carry references to their inputs and the version of the reasoning that produced them, so that when the underlying information changes, the network can tell which conclusions have gone stale, and so that a past recommendation remains interpretable according to the reasoning that produced it rather than being reinterpreted under a later method. That advice decays is the subject of Advice Has a Timestamp. And memory is deliberately divided: canonical historical facts stay with the participants, relationships, formations and outcomes they describe, while the intelligence layer keeps only its derived patterns and reasoning. The outcome model architecture gives the reason in one line: this separation prevents the intelligence layer from becoming the sole owner of network history.

6. The questions a living network asks

RSM's reference implementation specification closes by describing the loop it must eventually prove, and it phrases each stage as a question. What are we trying to make possible? What already exists? What could work together? What is missing? What must change? What will participants contribute? What has actually come together? What was done? What was observed? What actually happened? And finally: what does the network now know? The answer to the last question becomes the starting point for the next intent.

Most of those questions are the business of Outcome Formation, and other essays in this series treat them. The last one belongs to biography alone, and it is what distinguishes a network that persists from one that merely repeats. Without biography, every intent starts from zero, every withdrawal vanishes, every shortfall is overwritten by a revised target, and every success is either forgotten or turned into a rule. With it, the network carries forward what it has actually seen, attributed to where it was seen, with its uncertainty intact. That is a modest form of intelligence. For systems whose purpose is change over time, it is the form that matters.

Sources

• RSM Concept Paper v3.0, §7 Formation Before Transaction; Persistence Before Repetition; §8 Regeneration Requires Observed Consequence.
• RSM Normative Conceptual Reference v1.1, §2.3 Foundational Principle; §5 Biographical Interfaces; §22 Normative Distinctions.
• RSM Canonical Model and Protocol Specification v1.0, §5.1 Biography Model; §15.3 Revocation and Historical Integrity; §16 Events and Biographical Persistence.
• RSM Runtime and Federation Architecture Specification v1.0, §6 Biography Runtime.
• Wellzai Outcome Formation Information Architecture Working Paper, §3.3 Relationships; §13.4 Procurement and Buyer Execution.
• Wellzai Outcome Formation Reasoning Architecture Specification v1.0, §16 Outcome Evaluation; §17 Learning Architecture; §19 Explainability and Provenance.
• RSM Reference Implementation and Acceptance Specification v1.0, §15 Observation and Outcome Implementation; §16 Learning Implementation; §30.1 What the Reference Implementation Must Prove.