FieldnoteBuilding the RSM kernel
Reading Your Own Records Is a Disclosure
The same adoption test showed that letting people see their own capabilities, offers and grants needs an authorized read from the canonical source, not a second copy, and that whether a name is discoverable is a privacy question nobody had yet governed.
When Wellzai was connected to the RSM kernel as its first external consumer, using only the public protocol, the second gap it found looked like a missing convenience. It turned out to be a question about disclosure.
A person who had described a capability, published an offer and recorded an affiliation could not be shown any of it. The kernel offered two kinds of read. Discovery answers from a projection and returns only discovery-safe facts: capabilities, offers and broad places. It has no seeks, no claims, no affiliations, no grants and no authority. Disclosure released exactly one protected field, the precise location of a place. A successful operation did return the identities it had created, but rebuilding someone's state from a trail of results would have meant the application keeping its own copy of canonical objects. The adoption test forbade that, for good reason.
The gap was more than cosmetic. To publish an offer on behalf of an organization, a person has to cite the stewardship or delegation grant that authorizes them, by its canonical identity. So people need to see the grants they hold. Grants seeded at setup could not be read back at all. Neither could an organization's records be shown to its authorized delegate.
The fix did not add a new kind of read. It added a new thing that disclosure can release, the subject's own records, and sent it through the same disclosure path, unchanged. The caller is bound to the subject. Current authority and policy are evaluated fresh on every request: acting for oneself, stewardship or delegation, the scope of the operation, purpose, time and lifecycle. Nothing is journaled or replayed. The records are read from the canonical source, never from the projection.
The rules are narrow on purpose. Records must be requested on their own, not bundled with other protected fields. The subject must be the party the caller is acting for. "Records of" a subject means its current objects, plus the affiliations, delegations and stewardships that name it as a party. History is left out. Only non-protected attributes are included: a place's precise point still requires its own disclosure. An ordinary affiliation cited as authority releases nothing, and so does a grant whose scope does not include disclosure.
Viewgraph6 frames
Building the RSM kernel
Two reads, two levels of trust
Discovery reads a disposable copy. Disclosure reads the source, under authority checked at the moment of asking.
Wellzai
Discovery
Discovery answers from a projection
A derived view, rebuilt from canonical state. Useful, and never an authority.
Rendering diagram…
The projection is downstream of the record. It can be destroyed and rebuilt.
Who offers which kind of capability, in which broad area. Not quantities, not names, not a precise location: discovery returns discovery-safe facts, and details remain the subject's records.
Disclosure
Disclosure answers from the source
Authority is evaluated fresh on every request. Nothing is cached, journaled or replayed.
Rendering diagram…
The projection appears nowhere on this path.
First external consumer
Stored correctly, found by no one
The view could be rebuilt. Nothing in the running service ever rebuilt it.
Rendering diagram…
Every part was correct on its own. The gap was between them.
The fix
Refresh the view, keep the boundary
The smallest application-neutral change that made applied state discoverable.
The projection is re-derived in full from canonical state.
A refresh cannot change whether an operation was applied.
A failed refresh leaves the last checkpoint in place and is reported to an operator.
A running node no longer answers from a projection it never built.
What the read revealed
The observation we keep returning to is that reading your own records is a disclosure. It feels like a free query, because whose data could be more yours? But the kernel cannot know who is asking, or on whose behalf, without asking the same questions it asks of anyone else. The person acting may be you, or someone representing your organization, or someone whose delegation ended yesterday. Treating self-access as an authorized, current-state read is what keeps the answer correct in each of those cases. It also keeps every application from holding a shadow copy of the network.
The same work surfaced a question nobody had governed. Discovery returns a subject's canonical identity but no name, because whether a person's or organization's name is discovery data is a privacy decision the RSM has not made. For the demonstration, Wellzai labelled its own demo identities from development data and otherwise showed a short identifier. That is a placeholder, not an answer. A broad area can be discoverable while a precise location stays protected. Where a name belongs on that line is open. So is the question of contact details, which the canon does not yet represent at all.
One limitation was recorded rather than fixed. People, organizations and grants cannot yet be created through the protocol. For the adoption test they were set up by a development-only bootstrap, and onboarding and grant issuance remain future protocol work.
What we did not treat as a gap is just as telling. Offer quantities and capability names do not appear in discovery results, and that was accepted. Discovery returns discovery-safe facts. Details are the subject's records, released under the subject's authority. The RSM Concept Paper says it directly: every view is "a governed projection, never an authority", and discovery does not create participation. Building the application made that sentence practical.