THE SOURCE AND ITS RELATIONS
An invented teaching encounter
A teacher chooses a short excerpt for one lesson. Review continues, and there is a duty to teach it within that scope.
Sovereign Relational Architecture
Learning model 2026-09-30.1
Follows the revised essay
A relation changes. What must continue?
Follow an invented language program from proposal to permission. Then change one thing at a time and see what is still permitted, and what is still owed.
Preparing the invented cases…
Each line starts with a claim from the essay. Its links open the matching case at the right step, with any earlier actions cleared.
This is version 2026-09-30.1 of the learning model. It follows the revised essay. To cite this version, use its frozen copy at /sra/v/2026-09-30.1/, which will not change. The earlier version, 2026-09-12.1, is still available at /sra/v/2026-09-12.1/. The March 2026 preprint linked above is an earlier release. Its “strengthen-only” transport rule has since been revised: receivers may now neither loosen nor tighten the conditions without the originating process's authorization. No private manuscript or real governing record is included here.
Each tab shows one mechanism with invented data. For a connected story, follow a case instead.
A true record, the wrong use
A receiver produces an artifact when it treats a partial account as enough to speak for the relations behind it, or as permission to use it on terms those relations do not allow. The essay names four mechanisms of this failure and one consequence downstream. Choose an example and reveal the author's analysis.
THE SOURCE AND ITS RELATIONS
A teacher chooses a short excerpt for one lesson. Review continues, and there is a duty to teach it within that scope.
WHAT THE RECEIVER HOLDS
A partial account carried as a relay. The receiver says what it leaves out and keeps the governing conditions in force.
Rule for this site: never enter or embed real protected information anywhere here.
Before anything is made
DVA judges one proposed digitization, not a kind of knowledge. This worksheet shows how a signed determination is issued, using invented entries. It gives no one authority. For a connected example, choose Follow a case.
Carrying a decision
A warrant is a signed record of one bounded determination. It carries only what can travel safely. It does not permit an action by itself: a short-lived grant does that, one action at a time.
In plain terms: this is the warrant exactly as signed, first as readable JSON, then as the canonical bytes the signature covers.
Before each action
The gate walks through the checks an enforcing system would run before one action. The checks on signatures, structure, dates, scope, policy, duties and grants are real code. Steps that would need real infrastructure are stand-ins, and they are labeled. Nothing here enforces anything outside this page.
SELECTED SCENARIO
Written to show:
Model clock:
In plain terms: each of the gate's twelve checks in order, with its exact message. Stand-in steps are marked.
In a real system, a grant would be tied to the one party allowed to use it (for example with mTLS or DPoP), and using it would release the content in one step that cannot be interrupted. That needs a real service. This model shows the grant's life cycle and its scope checks.
Constraint-preserving transport
More restrictive is not always more faithful. A receiver may neither loosen nor tighten the conditions without a signed, versioned change from the originating process. Tightening can block duties the community requires, such as teaching, return, circulation or renewal through use.
In plain terms: the conditions the source requires, beside the conditions this receiver says it accepts.
If the result cannot be determined, nothing is released. An ordinary safeguard such as encryption at rest passes only when it changes no permission and blocks no duty.
Who gets to know
A record of refusals can turn into a map of what to go after, so each kind of visibility is its own decision. A public refusal is a statement the community chooses to make. A restricted note belongs in a separate store the community controls. Non-disclosure of existence (NDE) allows no shared trace of the matter at all, though a community may keep its own internal note. The NDE example below uses one simple convention: an empty shared store.
An outsider asks about two identifiers: one the community holds under NDE, and one that never existed. Both queries go through the same lookup, and both get the same status, body and length.
Matching responses are not the whole job. In a real deployment, timing, caching, rate limits, logs and backups must also be tested by someone trying to tell the two apart; code alone cannot show this. This model shows the response shape only.
No public statement has been written.
No restricted note has been written.
This separate structure in browser memory shows only that the records are kept apart. It is not access control or secure storage.
Threat model
What could be exposed: content, the fact that something exists, protected standing, who disagreed with whom, warrants, revocation histories, query patterns, logs, backups and derivatives. Who might expose it: curious institutions, bad-faith receivers, stolen keys, insiders, coercive contracts, court orders and outside attackers.
A deployment can control its own release path, turn away receivers that cannot honor the conditions, keep shared records to a minimum, and make any change to a policy visible. It cannot control people who already hold the plaintext.
Ceremonial, kinship and other protected standing stays inside the governing process. The outside system receives a bounded decision, never a lasting description of who holds standing. Even so, bounded grants repeated for the same person can map standing that no single record names.
No shared entry about the matter is created. Whether timing, caching, rate limits, traffic, backups, endpoints and staff behave the same for both kinds of query still has to be tested in production.
A valid signature cannot make a captured process legitimate. Software can do exactly what it was told while amplifying a governing process that shut people out or was coerced.
Modeled versus real
The browser shows how the decisions work. It does not host, enforce, or protect real resources.
Relation before data
DVA asks a prior question, before any access control: can this proposed making or use uphold the conditions under which the knowledge stays itself? SRA carries the answer into the systems that would act on it. This model lets you watch that happen with invented cases.
A dam is not a false record of a river. It is a physical intervention that can destroy the conditions a river's life depends on. The artifact problem lives in the paperwork: accounts that render river as water inventory, bottomland as acreage and relation as title, then pass those accounts off as a full description of what is there.
The same care applies to more-than-human relations. A human steward cannot confirm a beaver's or a stream's consent. A warrant here can only be a bounded human undertaking about human action, grounded in sustained witnessing, recognized within the community, and open to correction by the relations it claims to have witnessed. It can record observations, sources, limits and precautions. It cannot exhaust the stream's authority.
A few rules run through every case. DVA is a governance determination, made by a governing process and never computed. NDE means nothing about the matter is written anywhere shared: no entry, identifier, reason or revealing count. Transport is constraint-preserving: receivers may neither loosen nor tighten the conditions without the originating process's authorization. A warrant carries one bounded decision; a grant permits one action. When the gate withholds an action, it publishes nothing.
This browser opens written cases and executable checks to inspection. It is not a proof. A technically successful path does not validate the theory or show that a governing process is legitimate.
Changes since version 2026-09-12.1, made so the model follows the revised essay: