# Distributed Context

> **Published.** Last updated 2026-09-05.
>
> Canonical human-readable version: https://writings.withnative.ai/distributed-context
> Canonical Markdown source: https://github.com/withnative/writings/blob/main/src/content/writings/distributed-context.md
> Revision history: https://github.com/withnative/writings/commits/main/src/content/writings/distributed-context.md
> Editorial context: [0e13ae8](https://n8v.to/0e13ae8).

## Abstract

Software agents now do consequential work with people across sessions, tools and organisations. Yet we still treat the context they depend on as material for a prompt: retrieve it, summarise it, consume it and throw it away. I argue that context should instead be shared state. **Distributed Context** is durable, connected, governed state shared by people and agents across applications, sessions, organisations and time. Every unit keeps a stable identity, a recorded history, explicit relationships, defined authority and attribution. Corrections and movement between custodians remain part of the state too.

Seven requirements follow. Different kinds of work—a message, a task, the decision that settled it—have to live in one world we can traverse without being flattened into one type or interface. That world must carry its own history, authority, attribution and corrections. Its interfaces must account for the way agents actually work. And because no custodian should have to hold everything, federation between independently governed domains follows from the definition rather than arriving as an optional feature.

[Native](https://github.com/withnative/native), a context system built on these premises, is the principal case. Within one workspace it is implemented, inspectable and used daily to build itself. Its public snapshot supports claims about a typed record spine, an event-authoritative write path with rebuildable projections, temporal and change reads, caller-relative authorization, attribution distinct from truth, advisory coordination, and a portable SQLite node that a reader can export, rebuild and run. Hosted composition and identity custody are described only at the architectural level. Across custodians, Native is protocol and kernel rather than an operated service: federation roles, wire schemas, an encrypted relay and an identity kernel are experimental, while cross-workspace delivery is not operational. Every material claim carries an evidence class. Early operating data from Native's own use, across two generations of the engine, suggest that recording is predominantly agent work and that retrieval tracks connectedness. These data are instrumentation, not a study. The remaining limits are deliberate recording, lexical search, advisory claims, non-operational cross-domain delivery and freshness.

---

## 1. Context as a transient input, and why it fails

A person asks an agent to prepare a decision memo. The agent reads a folder of Markdown notes, a chat export and three application records, writes the memo, and the session ends. Two weeks later, a different agent in a different client is asked whether the decision still stands. It finds the memo. It does not find the message that made a colleague change their mind, the task that was opened as a result, the revised decision that superseded the memo, or the fact that the person who wrote the original note has since left the project. It answers from the memo.

Nothing in that story is exotic. It is the ordinary shape of agent work in 2026. We gather context for one inference, place it in a prompt and consume it. This framing makes sense: the prompt is where a model meets its context, and much of agent engineering is organised around that meeting. Retrieval-augmented generation selects passages for the prompt [29]. Long-context models enlarge it, though models still struggle to use material from the middle [30]. Agent-memory systems page information into and out of it [31, 42]. The practice now called context engineering asks what to put there and when [37]. These are real advances. They also share an assumption: context is *material for the model*, while the durable world lives somewhere else.

That split detaches four things that consequential work needs.

**Correction is detached from the thing corrected.** A file can remain plausible after the answer changed. The correction lives in a later conversation, in a person's memory, or in a different application. A reader with no memory of the thread has no in-band signal that the file is superseded, so a later agent acts on it. This is the failure most agents will recognise from experience with local context files, and it is a failure of *placement*: the correction exists, but not where the reader is.

**Authority is detached from content.** Prompt assembly flattens everything into text of equal standing. Who asserted a statement, whether they were authorised to decide it, whether it is a proposal or a ruling, and whether a later authority overrode it are not properties of a retrieved passage. Summarisation compresses these distinctions first, because they are not in the words.

**Provenance is detached from action.** An agent does something because of what it read. Later, nobody can say which reading caused which action, which version of a record the agent saw, or whether it saw a version that has since been withdrawn. The transcript, if it survives, is a record of the conversation, not of the state of the world the agent acted on.

**Movement is detached from meaning.** When context crosses a boundary (between applications, between a person's machine and a hosted service, between organisations) it is usually copied as bytes. Identity, history, relationships and access policy do not survive the copy, so the receiving side acquires content without the properties that made it trustworthy.

Application silos solve each problem in isolation and deepen the problem as a whole. A task tracker preserves task history. A chat tool preserves messages. A document store preserves versions. Each keeps its own objects and loses the transitions between them. The request, the task it opened, the document the work produced, the decision that document informed and the later decision that replaced it end up in five systems, held together by human memory and pasted links. Enterprise search may find all five. It still cannot say how they relate or which one governs.

There is an economic reason to care. Research on general-purpose technologies describes them as pervasive, continually improving and able to spawn complementary innovation [44]. But capability and adoption alone do not produce their full effect. People must also build the infrastructure and change the organisations around them, often before the benefits show up in measured output. Brynjolfsson, Rock and Syverson call this lag and later harvest the productivity J-curve, and analyse AI alongside earlier general-purpose technologies in those terms [45].

Distributed Context is a proposal for one such complement to agentic AI. Better models will not, by themselves, preserve a decision's history, carry a correction to the next reader, distinguish authority from authorship, or keep provenance attached as work crosses applications and organisations. This paper does not estimate a productivity effect, and the economic literature does not validate the architecture proposed here. The narrower claim is motivational: if agents are to do consequential work across those boundaries, we must develop the infrastructure that holds the state of that work alongside the models that act on it.

Figure 1 contrasts the two framings.

![Figure 1. Context as transient input versus context as shared state](/figures/distributed-context/fig1-transient-vs-shared.svg)

*Figure 1. Context as transient input versus context as shared state. On the left, each session assembles a prompt from files, chat history and application databases and leaves nothing durable behind except a transcript; corrections, authority and provenance are lost between sessions. On the right, sessions read from and write to one governed body of shared state that carries identity, history, relationships, authority and attribution, so that a later reader can reconstruct the chain of work and see what superseded what. The figure is a statement of the framing, not evidence for it.*

These detachments follow from treating context as input rather than state. Treat it instead as *durable, connected, governed state shared across actors and time*, and identity, history, relationships, authority, attribution, correction and movement are no longer auxiliary metadata. They are the context. Section 2 defines that state and derives its requirements. Sections 3 to 7 follow the architectural consequences through Native. Section 8 states what is implemented and on what evidence; Section 9 states the limits.

Native is not merely an architecture. The team that builds it also uses it as the shared context layer for product decisions, research and agent hand-offs; this essay and its review by eight independent reader agents were coordinated and recorded there. That is internal use by a small team, not adoption. Section 8.4 therefore distinguishes what seventeen days of instrumented use on the current engine and nine months on its predecessor can and cannot show. Within one workspace, Native is a working, inspectable system: a reader can run the local node over stdio, export a verified SQLite snapshot, replay its logs through conformance, and exercise temporal reads, change traversal, message expectation, interventions and the authorization census. Hosted composition is held, and the public snapshot is an inspection surface rather than a supported build or self-hosting distribution. Across workspaces, federation remains experimental protocol and kernel rather than an operated service. These boundaries govern every claim that follows.

---

## 2. Definition and requirements

### 2.1 Definition

> **Distributed Context** is durable, connected, governed state shared by people and AI agents across applications, sessions, organisations and time. Each unit of that state has stable identity, a recorded history, explicit relationships to other units, defined authority over who may see and change it, and attribution of who asserted what on what evidence. Corrections, supersessions and movement between custodians are recorded within the state rather than outside it.

*Durable* means the state outlives the session, the model, the client and the run that produced it. *Connected* means units refer to one another through relationships that are themselves part of the state, so that a later reader can traverse from any unit to the units that caused, produced, informed or replaced it. *Governed* means visibility and change are subject to explicit, inspectable policy relative to a caller, and that consequential operations leave a record of who performed them and why. *Shared* means people and agents act on the same state through the same semantic boundary, with distinct identities. *Distributed* carries two senses that Section 7 separates: the state is distributed across the actors who read and write it, and it may be distributed across independently governed custodians who cooperate without a universal owner.

The clause about corrections is the one most easily dropped and most important to keep. A system can be durable, connected and governed and still leave correction outside itself, in which case it reproduces the first detachment of Section 1 at larger scale. Distributed Context requires that "this was superseded by that" be a fact *of the state*, discoverable from the superseded unit, not a fact about the state held somewhere else.

### 2.2 What it is not

The familiar alternatives are all useful. None carries the whole definition.

| Alternative | What it provides | What it lacks relative to the definition |
|---|---|---|
| **Prompt context** | The material a model attends to during one inference | Durability, identity, relationships, authority; it is a view, not state |
| **Model memory** (parametric, or an agent's private memory store) | Continuity for one model or one agent | Sharing across actors with distinct identity; inspectable history; governance; attribution to anyone but the agent |
| **Retrieval-augmented generation** | Selection of relevant passages from a corpus | The corpus is unstructured with respect to relationships, authority and correction; retrieval returns text, not governed units |
| **A folder of context files** | Durable, portable, human-editable content | In-band correction, attribution, authority, typed relationships; a file has no place to record what superseded it |
| **An application database** | Durable, typed, governed state for one application's objects | Connection to the other kinds of work the objects relate to; transitions across application boundaries; history and attribution designed for other applications' readers |
| **Enterprise search** | Discovery across many sources | Relationships, authority, correction; it finds everything and governs nothing |

The contrast with a folder of files deserves emphasis. Possession is one of the strongest properties a context system can offer: files provide portability and independence from any vendor. On their own, however, they cannot provide the in-band correction and attribution the definition requires. Section 7 returns to possession as a requirement that Distributed Context must satisfy rather than abandon.

### 2.3 Requirements

Seven requirements follow from the definition. They are properties of the state, independent of any implementation.

- **R1 The thing keeps its name.** Every unit has a stable, addressable identity that survives edits, moves and export.
- **R2 The past stays inspectable.** Every consequential change to a unit is recorded with its actor, and earlier states remain reconstructable.
- **R3 The links survive the hand-off.** Units refer to other units through explicit, typed relationships that are part of the state and traversable in both directions.
- **R4 Access follows the caller, not the link.** Visibility and change are governed by policy evaluated relative to the caller, and a relationship between units never by itself grants access to either.
- **R5 Who said it is not whether it is true.** The state records who asserted or assessed what, on what evidence, without collapsing attribution into truth, endorsement, consensus or permission.
- **R6 The correction finds the reader.** When something is superseded, retracted or closed, that is a fact of the state, discoverable from the thing it happened to—not a fact about the state kept somewhere else.
- **R7 The state moves without losing its meaning.** The state can move between storage and custodians without losing R1 to R6, and cooperation between custodians does not require any one of them to hold everything.

R1 to R6 concern one context domain. R7 is the requirement that turns "a context system" into "Distributed Context" and drives Section 7. Notice what the list does not include: it does not require a particular storage engine, a particular consistency model, event sourcing, cryptography, or any single interface. Those are choices an implementation makes to satisfy the requirements, and Section 4 is explicit that Native's event-authoritative design is one such choice, not part of the definition.

---

## 3. One connected, typed world

### 3.1 The accountable chain

Consider one chain of ordinary work. Application silos sever it at every link.

A person sends a message asking a colleague to evaluate a supplier. The message expects action, not merely a reply. The colleague opens a task derived from that message and completes it, producing a comparison document. A decision is recorded that cites the document and selects the supplier. Three weeks later, new information arrives and a second decision supersedes the first. An agent, asked to draft the purchase order, acts on the second decision. Six months later, an auditor (human or agent) needs to reconstruct why the purchase happened and whether the reasoning still holds.

Figure 2 draws the chain. Its nodes are of five different kinds: a message, a task, a document, two decisions, and an agent's run. Every kind has semantics the others lack. A message has a sender and an addressed audience and cannot be edited after sending without misrepresenting what was said. A task has an owner and a lifecycle. A document has a body whose exact bytes matter. A decision is an authorised resolution among alternatives that is withdrawn by supersession, not by deletion. An agent run has an intent and a sequence of writes.

![Figure 2. One accountable chain across distinct record types](/figures/distributed-context/fig2-accountable-chain.svg)

*Figure 2. One accountable chain across distinct record types. A Message whose expectation is action is satisfied by a recipient-owned WorkItem derived from it; the work produces a Document; the Document informs a first Resolution; a second Resolution supersedes the first; an agent run acts on the second. A later reader reconstructs the chain by traversing recorded relationships and history rather than by remembering it. The relationship names shown are those Native's public spine guarantees (`derived_from`, `supersedes`) together with the Message expectation facet; the conceptual chain does not depend on those exact names.*

It is tempting to simplify this chain in one of two ways: make everything a document, or give each kind of work its own application. Both are reasonable, and both lose half of what the later reader needs. Collapse the five things into one type and their distinct semantics disappear: a decision that can be silently edited is not a decision, and a message whose audience can be rewritten after the fact is not evidence of what was said. Split them across five systems and the transitions disappear instead. The reader can no longer answer, “Why did this happen, and does the reason still hold?” The five kinds of thing must remain distinct *and* inhabit one world.

### 3.2 A shared floor and open extension

A *shared floor* beneath distinct types resolves the tension. Native defines ten spine types—Document, Program, WorkItem, Outcome, Entity, Collection, Resolution, Conversation, Message and Annotation. They share identity, one canonical place in a containment tree, a small set of spine facets, links and governed relationships, event history, query, and caller-relative policy. Beneath each closed type, `kind` stays open: a Document may be a note, a page, an attachment or an artifact; an Annotation may be a comment or a suggestion; a Resolution may be a decision or a policy. Facets add typed or governed attributes without widening the spine. [^a1]

[^a1]: **A1 — public current.** Ten spine types share identity, placement, facets, links, relationships, history, query and policy; kinds extend them openly. Evidence: [contract.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/schema/contract.rs); [record-types.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/record-types.md); `cargo run --bin conformance`. *Limit: Only deliberately recorded content is in the world.*

Two choices keep “one world” from turning into “one schema”.

First, *the type is closed and the kind is open*. The closed type vocabulary lets tools, clients and other implementations interoperate: every reader knows what a Message or a Resolution is and which operations apply. The open kind vocabulary lets a workspace express forms the designers did not anticipate without forking the spine. The record-type guide says that a subtype must never become a new top-level type, and that a novel kind is better than a dishonest match with a governed one. An ordinary update cannot change type. Only a separately governed correction operation can do that, and conformance enforces the rule in the event fold rather than through a database constraint. [^a2]

[^a2]: **A2 — public current.** Record type is immutable through ordinary update and changeable only by a governed correction. Evidence: [mod.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/conformance/mod.rs) (type-immutability). *Limit: Correction operation is itself governed and recorded.*

Second, *placement and association are separate*. Every record has one canonical browse home in a containment tree and may have many links. Containment is never inferred from links, and links never move a record. [^a3] The supplier decision can live in the procurement folder while linking to a message in the buyer's conversation, a task on a colleague's board and the comparison document in research. The links say what relates; the tree says where to browse. Whether one mandatory structural coordinate is an enduring principle or a pragmatic implementation choice remains open in Native's own design discussion. It is not part of the definition of Distributed Context. [^a3]

[^a3]: **A3 — public current.** Placement is single and canonical; links are plural and never change placement. Evidence: [placement.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/placement.md). *Limit: Whether single placement is a principle is open.*

### 3.3 What "together" means

“Together” now has a precise meaning. Two records are in one world when a caller can address both, traverse the relationship between them, read each history, ask what changed after a given point, see who asserted what, and meet one policy model along the way. They need not share a table, a user interface, a lifecycle vocabulary or identical operations. Messages pass through messaging operations that preserve a sealed sender, sealed audience and immutable expectation. Decisions and tasks use ordinary record operations. Annotations attach to other records. [^a4]

[^a4]: **A4 — public current.** A Message seals sender, audience, reply/supersession links and expectation at creation. Evidence: [message-first-conversations.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/message-first-conversations.md); [messaging.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/tools/messaging.rs). *Limit: Native messaging only.*

The message-to-work transition is the cleanest evidence that this is more than a data model. A Native Message declares, atomically and immutably at creation, its sender, its complete addressed audience, its reply and supersession links, and an *expectation* drawn from a closed vocabulary: `none`, `ack`, `reply`, `action` or `decision`. The expectation is a sender's declaration of what would satisfy the message. Its satisfaction is not a status flag the sender sets; it is derived, live, from recipient-authored evidence: an `action` expectation is satisfied when a WorkItem owned by the recipient, derived from the message, reaches a governed terminal-positive lifecycle state; a `decision` expectation is satisfied when the recipient authors a governed decision derived from the message. A reply never satisfies `action` merely because prose was sent. [^a5] The communication, the work it created and the outcome remain one connected structure with the sender's intent reconciled from the recipient's durable evidence rather than from anyone's assertion.

[^a5]: **A5 — public current.** `action` and `decision` expectations are satisfied only by recipient-authored governed evidence derived from the message. Evidence: [message_expectation.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/message_expectation.rs); [message_expectation.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/records/message_expectation.rs). *Limit: Cardinality across several recipients is deferred cross-domain.*

That design has an intellectual ancestor. Winograd and Flores's account of conversations for action, and the Coordinator system built on it, treated a request as a speech act that opens an obligation and is closed by declared completion [22, 23]. Native's expectation semantics keep the structure of a request with an expected completion and change what counts as completion: not a declaration by either party, but governed evidence authored by the party who owes the completion. The difference matters for agents, which are prone to declaring things done.

### 3.4 Counterexamples and costs

One connected world sounds like an argument for putting everything into one system. It isn't. Some things should stay outside, and connection has a cost.

*Some information should not enter the world.* Native's product model states that it keeps explicit, durable records and does not passively remember everything; ordinary conversation is not silently converted into durable memory, and an agent's private working context is an intentional, separately placed alternative to a workspace record. [^a6] A context system that captured everything would be a surveillance system, and one that captured every intermediate agent thought would bury the accountable chain under transcript. The acquisition boundary is a deliberate act of recording, and Section 9 treats the cost of that act as the system's principal residual burden.

[^a6]: **A6 — public current.** Ordinary conversation is not silently converted into durable state; private agent context is a separate placement. Evidence: [product-model.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/product-model.md). *Limit: Recording is a deliberate act and a cost.*

*Some boundaries are correctly application-specific.* Payroll, source control and medical-records systems have integrity constraints, retention obligations and performance envelopes that a general context world should not try to absorb. The right relationship is reference, not ingestion: a unit in the context world can point to an external object and record what was decided about it. Distributed Context connects work; it does not put all work into one system.

*Connection has a cost.* Someone must record relationships, declare audiences, choose types and kinds, and correct records when reality changes. A folder of files asks for none of this. Native's own guidance observes that a one-off task with stable context and one contributor may receive more structure than value, and that the system is a poor fit if nobody will maintain the shared state. [^a6] In consequential work among several actors, however, people already pay the cost through reconstruction and error. Paying it when the work happens leaves something the next reader can recover.

---

## 4. History, authority, attribution and correction as context

History (R2), authority (R4), attribution (R5) and correction (R6) belong in the state, not in an administrative layer beside it. Native offers one way to do this. It makes staleness *visible in band*; it does not abolish staleness.

### 4.1 Authoritative history and rebuildable views

Native answers R2 with an event-authoritative write path. Every successful content mutation appends an event to the authoritative log and updates the queryable projection in the same transaction. No other code path updates those projection tables. Separate logs and folds apply the same discipline to schema and vocabularies, policy, relationships, instruction control and derivations. To test the promise, replay folds the ordered events through the same projectors into a fresh database. The conformance runner compares that rebuilt state with the live one and fails if they drift. [^a7][^a8]

[^a7]: **A7 — public current.** Every content mutation appends an event and projects in the same transaction; projections are never independent truth. Evidence: [store.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/store.rs); [lib.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/lib.rs); [invariants.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/kernel/invariants.rs). *Limit: Rebuild equality is not a truth or security proof.*

[^a8]: **A8 — public current.** Replay rebuilds projections and conformance diffs them against live state. Evidence: [rebuild.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/conformance/rebuild.rs); `cargo run --bin conformance`. *Limit: Same as A7.*

This is Native's mechanism for R2, not part of the definition of Distributed Context. Versioned rows, a bitemporal schema in the tradition of Jensen and Snodgrass [17], or an immutable log in Helland's sense [9] could also satisfy R2 without event-sourcing every write. The requirement is simpler: reconstruct earlier states and record the actor behind every change. Event authority does both and adds a property used in Section 5: the *history of the world* and the *world* cannot disagree. A reader can ask for the world as it stood at any event position.

Three read surfaces follow from the log and are inspectable in the public snapshot.

*Temporal reads.* Structured reads accept an `as_of` selector by content sequence or timestamp. A historical read replays the content prefix and echoes the resolved sequence beside the live head, so a caller always knows how far behind the present it is reading. The historical boundary is deliberately mixed: records, links and facets come from the replayed prefix while schema, vocabularies and authorization are live, and the documentation says so rather than pretending to a total time machine. Lexical search and SQL do not accept `as_of`. [^a9]

[^a9]: **A9 — public current.** Structured reads accept `as_of` by sequence or timestamp and echo the resolved position beside the live head. Evidence: [temporal-reads.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/temporal-reads.md); [as_of.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/kernel/as_of.rs). *Limit: Schema, vocabulary, authorization live; search and SQL not historical.*

*Change traversal.* A stateless, authorization-filtered traversal answers "what changed after position N that this caller may see?" It pins a high-water mark on the first page so that concurrent writes cannot enter a traversal in progress, groups events by record, actor and run, and guarantees that hidden events cannot shrink a visible page or produce a false continuation. [^a10]

[^a10]: **A10 — public current.** Change traversal is stateless, authorization-filtered, pins a high-water mark and never shrinks a page for hidden events. Evidence: [whats-changed.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/whats-changed.md); [whats_changed.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/kernel/whats_changed.rs). *Limit: Caller-visible only.*

*Write receipts.* A successful direct write returns the highest event sequence on the record before the write began, so a caller can read the pre-write state exactly. Twelve mutating tools require a stated reason, and the reason lands in the event payload beside the actor and run context. [^a11]

[^a11]: **A11 — public current.** Direct writes return the pre-write highest sequence; twelve mutating tools require a stated reason stored in the event. Evidence: [lifecycle.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/lifecycle.md); [write_path.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/kernel/write_path.rs). *Limit: Count is snapshot-specific.*

### 4.2 Correction that travels with the work

Imagine opening last month's decision memo just before a meeting. The prose still looks current. In an ordinary file store, you need to know that someone reversed the decision in a conversation you never saw. Under R6, the old memo itself leads you to the correction.

Native does this with `supersedes`, one of nine guaranteed spine relationships. The replacing record points to the replaced one, and the index runs both ways, so a reader of the old memo sees what replaced it. Lifecycle is an open facet that workflows use for coordination status; archiving is a separate reversible engine facet; deletion is a soft tombstone that freezes the record and keeps it inspectable by exact identity and through history. [^a12]

[^a12]: **A12 — public current.** `supersedes` is a guaranteed spine relationship indexed in both directions; deletion is a soft tombstone. Evidence: [links.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/links.md); [lifecycle.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/lifecycle.md). *Limit: Someone must record the supersession.*

For Messages, whose content is sealed at creation, correction is *only* possible through supersession: a corrected message is a new message linked to the old one. Expectation is immutable sender-authored content and a correction is a new Message with a `supersedes` link. [^a4][^a12] That constraint is the design in miniature: the thing that was said stays said, and the correction is attached to it rather than overwriting it.

The defensible claim is narrower than the marketing version. Native does not stop context going stale. It makes staleness visible at the point of reading and repairable in band: a superseded record still says what it said and identifies what superseded it, which a file cannot do. The mechanism applies only when someone or something records the supersession. The architecture moves the failure from *invisible on read* to *someone has to maintain it*. Native's public documentation states this residual directly, and I adopt it as the appropriate standard: a still-live but wrong record remains misleading, and no system can recover a rationale that was never recorded. [^a13] A third form of staleness also escapes in-band detection: a fact may remain true while its audience changes, making a measurement correctly attributed to one environment misleading in another. Section 8.4 measures in-band repair in Native's own use; Section 9 returns to the problem.

[^a13]: **A13 — public current (stated limit).** Native does not abolish staleness; a live but wrong record remains misleading. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md); [capability-map.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/capability-map.md) row 1. *Limit: Adopted as the paper's standard.*

### 4.3 Authority that is not inferred from structure

A link feels like an invitation: click it and expect the other end to open. That intuition is useful in public information and dangerous in governed work. R4 says that a relationship cannot grant access to either of the things it connects.

Native evaluates a View, Edit or Manage disposition for every registered operation before that operation crosses the storage boundary. Policies form complete replacement boundaries anchored at records; grants are never copied or unioned down the containment tree. The policy tier has its own authoritative log, so replaying content cannot invent or reactivate a grant. The host supplies membership at evaluation time, allowing it to add or remove a member without rewriting the portable file. [^a14][^a36]

[^a14]: **A14 — public current.** View/Edit/Manage is evaluated per registered operation; policies are complete replacement boundaries with no inheritance; policy has its own log. Evidence: [authorization.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/authorization.rs); [policy-kernel](https://github.com/withnative/native/tree/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/crates/policy-kernel); [authorization-contract.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/authorization-contract.md). *Limit: Local stdio authorization advisory at process boundary.*

[^a36]: **A36 — held current.** Membership is evaluated at request time and changes without rewriting the file. Evidence: [authorization-contract.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/authorization-contract.md) (evaluation input, public); host composition (held). *Limit: Same.*

The authorization contract is unusual in being a census rather than a policy statement. At the public snapshot it enumerates 72 registered tools and 179 operations, declares for every mutating operation an explicit no-write-on-deny obligation with named negative evidence, and fails continuous integration when a production operation is missing, when a schema action changes, or when a sensitive operation drops its non-disclosure obligation. [^a15] The relevant architectural point is not the numbers but the discipline: a claim of "fail-closed authorization" is checkable per operation, with the positive and negative case adjacent.

[^a15]: **A15 — public current.** The authorization census lists 72 tools and 179 operations with negative evidence and fails CI on omission. Evidence: [authorization-contract.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/authorization-contract.md); [authorization_contract.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/tools/authorization_contract.rs). *Limit: Counts are snapshot-specific.*

Two boundaries deserve repetition because summaries easily omit them. First, possession of the SQLite file is a storage capability, not application authorization: a database-file holder on a local stdio node can bypass application policy, so local authorization is advisory at the process boundary. Second, a Conversation is thematic classification, not a roster; conversation policy never widens message access, and sharing message history with a new recipient is an explicit, bounded, idempotent grant that cannot recall bytes already delivered elsewhere. [^a14][^a16]

[^a16]: **A16 — public current.** Conversation policy never widens message access; sharing history is an explicit bounded grant. Evidence: [message-first-conversations.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/message-first-conversations.md). *Limit: Cannot recall bytes already delivered.*

### 4.4 Attribution that is not truth

R5 protects distinctions that a summary naturally compresses. Native keeps at least seven of them apart.

*Visibility* is what a caller may read. *Authorship* is who physically wrote a record, established by the actor stamped on each event. *Contribution* is a richer, explicitly limited description returned with a record: the principal, the executor that acted, the channel and the run, each with a stated assurance level, and each accompanied by machine-readable interpretation limits such as "principal association does not establish endorsement" and "run key does not establish persistent agent identity". *Stance* is a claim that a subject expresses or endorses a view over an exact content revision or passage. *Confidence* is an ordinal on a stance. *Evidence* is a Native-issued action attestation, minted transactionally for an accepted write, that a claim may cite as basis or counter-evidence. *Endorsement* by a person is available only through the person's own exact structured declaration, and cannot be manufactured from a credential, from delegation, from repetition, or from an agent's assessment however confident. [^a17]

[^a17]: **A17 — public current.** Visibility, authorship, contribution, stance, confidence, evidence and endorsement are kept distinct; endorsement only by a person's own declaration. Evidence: [interpretive-claims.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/interpretive-claims.md); [interpretive-claims-conformance.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/interpretive-claims-conformance.md); [attribution.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/records/attribution.rs). *Limit: Attribution does not certify truth or consensus.*

The conformance document for this subsystem lists invariants that read as a summary of R5: delegation does not establish endorsement; confidence does not establish truth; claim counts do not establish consensus; a standing-guidance record is interpretable content, not an instruction binding; an external-facing draft does not authorise publication; and hidden, sealed, imported or invalidated evidence never becomes confirmation by omission. When a reader cannot see evidence, the response says so with a withheld marker and no hidden cardinality, rather than returning a smaller number.

Attribution in this sense resembles the provenance literature's separation of entities, activities and agents [15, 16], but adds one distinction essential to agent work: an explicit *stance* layer between provenance and content. “An agent wrote this summary” and “a person holds this view” are therefore never the same fact, however the summary was produced.

### 4.5 Why these cannot be metadata beside the state

A reasonable objection is that any serious database already has history, policy and attribution. Calling them “context” can sound like relabelling. But prompt-centred systems tend to drop exactly these properties where the model meets the world. Retrieval returns a passage without its policy. A summary repeats a claim without its attribution. A file returns its current bytes without its supersessor. Store these properties beside the state but strip them at read time, and the agent still works without them; the four detachments of Section 1 return. The read surface must carry them by default, and the write surface must not let them disappear. Distributed Context is first a claim about the shape of state, and only then a claim about where we keep it.

---

## 5. An architecture designed for agents

### 5.1 The constraints

Picture two agents opening the same task. Both read that it is unclaimed. One claims it; the other's write times out. The second agent does not know whether the claim failed or merely lost its reply, and while it decides what to do, a person edits the premise of the task. A chat-like interface hides too much of this. A conventional API leaves too much for the caller to infer.

Agents work under a particular set of constraints. The principles below answer those constraints rather than borrowing an interface designed for either programs or people.

- **C1 Bounded context.** The agent can attend to a limited amount of material at once, and what it attends to displaces what it does not. Loading everything is not an option, and loading the wrong thing crowds out the right thing [30, 37].
- **C2 Stale reads.** Every read is a view of the world at a moment. Between the read and the write that depends on it, another person or agent may have changed the premise.
- **C3 Retries and duplication.** Agents retry. Networks fail, tool calls time out, and a harness may re-run a step. A consequential write that is not idempotent will eventually be performed twice.
- **C4 Uncertain authority.** The agent acts through a client for a principal. It is not that principal, may not be the only agent acting for them, and cannot see the full policy that governs what it may do.
- **C5 Coordination.** Other agents and people are working in the same world at the same time on overlapping subjects.
- **C6 Hand-off.** The next contributor does not inherit the agent's context window. Whatever the agent does not record does not exist for them.
- **C7 Lossy summarisation.** Agents compress. Summaries drop exactly the distinctions Section 4 argued must be preserved: authority, attribution, confidence, evidence, and the difference between "recorded" and "true".

### 5.2 Nine principles

The principles are numbered for independent citation. Each identifies the constraint it answers, the mechanism Native uses and the limit that remains.

**P1 Progressive disclosure.** *From C1.* Start with a bounded orientation and give the agent precise routes to deeper context, not a dump. Native's `bootstrap` returns the caller's footing, active standing instructions, a run correlation handle, a small scan of recent activity and open work, and a short list of context-sensitive next operations. It calls itself “a bounded, point-in-time orientation, not proof that no other relevant state exists”. From there, the agent can enter through several distinct doors: an exact read by identity, a structured query, lexical search, a cross-axis scan, or a lower-level relational query for questions the others cannot express. Tool discovery offers *focused* and *complete* profiles with declared byte ceilings. Filtering discovery is a lossy presentation control; it changes neither authorization nor exact-name dispatch. [^a19][^a20] *Limit:* orientation cannot know what the task will make relevant. The guides teach a search discipline—widen, diagnose empty results, change doors when the question changes—instead of promising that the right context arrives unasked.

[^a19]: **A19 — public current.** `bootstrap` returns bounded orientation, standing instructions, a run handle and next operations, and says it is not proof of absence. Evidence: [render.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/render.rs). *Limit: Orientation cannot know the task.*

[^a20]: **A20 — public current.** Tool discovery has focused and complete profiles with byte ceilings that change neither authorization nor dispatch. Evidence: [tool-surface.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/tool-surface.md); [tool-surface.generated.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/tool-surface.generated.md). *Limit: Lossy presentation control.*

**P2 Semantic operations.** *From C4 and C7.* Preserve the meaning of an action instead of reducing every task to generic reads and writes. Native registers typed operations once and dispatches them through every transport. A messaging operation sends a Message and seals its sender, audience and expectation. A claim operation claims work. An attribution operation asserts a stance over an exact content target. A governed relationship lets one decision supersede another. Generic link mutation cannot add a Message recipient, and generic update cannot change a record's type. [^a21] This is not elegance for its own sake. A later reader can understand “superseded decision 1 with decision 2” in an event log; “updated row 4127” has to be interpreted again. *Limit:* semantic operations multiply. Native's public surface is 72 tools and 179 operations, and P1 needs a descriptor byte budget because that surface would otherwise consume the context it is meant to conserve.

[^a21]: **A21 — public current (stdio); held current (hosted).** Typed operations are registered once and dispatched through every transport. Evidence: [registry.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/registry.rs); [stdio.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/stdio.rs). *Limit: Hosted composition not inspectable.*

**P3 Inspectable transitions.** *From C6 and C7.* Consequential writes should leave durable, attributable history that a later reader can inspect without the writer's transcript. Native stamps an actor on every event, requires a stated reason on twelve mutating tools and stores it in the event payload, correlates writes with a run key and optional parent run so that one activity can be reconstructed across compaction and hand-off, and returns action attestations for accepted writes that later claims may cite as evidence. [^a11][^a17][^a25] *Limit:* the run key is a correlation handle, not identity. The contribution metadata states this in machine-readable form because summaries can easily collapse the distinction.

[^a25]: **A25 — public current.** Run intent and lineage let a later session resume an activity. Evidence: [intent.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/tools/intent.rs); [coordination.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/coordination.md). *Limit: Run key is not identity.*

**P4 Explicit authority.** *From C4 and C7.* Visibility, authorship, confidence, evidence, consensus and permission must not collapse into one another. Section 4.4 gave the mechanisms. The principle adds one interface consequence: a response must be able to say "withheld" without saying how much is withheld. Native's interpretive-claims and freshness responses return a non-counted withheld marker and normalise "hidden" and "absent" to identical errors so that a caller cannot infer the existence of a record it may not see. [^a18] *Limit:* explicit authority is only as good as the policy someone wrote. The system distinguishes the dimensions; it does not decide what anyone is allowed to do.

[^a18]: **A18 — public current.** Withheld evidence is marked without cardinality; hidden and absent are indistinguishable. Evidence: [interpretive-claims-conformance.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/interpretive-claims-conformance.md); [context-freshness-runtime-proof.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/context-freshness-runtime-proof.md). *Limit: Per-operation contract, no general theorem.*

**P5 Conflict as information.** *From C2, C3 and C5.* When the second agent in the opening scene tries to claim the task, Native refuses it inside the write transaction rather than queuing or overwriting the first claim. The refusal says that another holder owns the claim. The agent must re-read and decide again, not retry past the evidence. Consequential writes carry idempotency keys, so an identical retry returns the durable result while a changed intent under an occupied key conflicts and writes nothing. Historical reads and change traversal let the agent check whether the premise of its pending write has moved. [^a22][^a23] *Limit:* a claim is advisory coordination, not a lock or permission. Claims do not expire or release on disconnect; ordinary record updates remain independent of claim occupancy. Treating a claim as mutual exclusion misreads it, and the public documentation warns against exactly that reading.

[^a22]: **A22 — public current.** Work claims are checked in one transaction, refuse a second claimant by name, and are advisory. Evidence: [work.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/tools/work.rs); [coordination.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/coordination.md). *Limit: Not a lock; no expiry; updates ignore occupancy.*

[^a23]: **A23 — public current.** Consequential writes carry idempotency keys; identical retry returns the durable result; changed intent conflicts. Evidence: [working-in-a-shared-world.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/working-in-a-shared-world.md); [context-freshness-runtime-proof.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/context-freshness-runtime-proof.md). *Limit: Per-operation.*

**P6 Bounded and honest responses.** *From C1 and C7.* Scope, historical position, omissions, authorization and unsupported operations require deliberate semantics. Native's structured reads echo the resolved content sequence and the live head on every historical response; change traversal pins its window and states that hidden events cannot shrink a page; scan censuses are labelled as orientation rather than complete matching sets; a standby node in read-only mode rejects writes with a stable code rather than pretending; and unsupported adapter operations fail closed rather than approximating. [^a9][^a10][^a33][^a45] *Limit:* honesty about bounds is a property of each operation's contract, established one operation at a time; there is no general theorem that every response is complete about its own incompleteness.

[^a33]: **A33 — public partial / directional.** Local standby consumes verified snapshots, promotes only on a closed frontier comparison, rejects writes, and rejects transparent failover. Evidence: [local-standby.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/local-standby.md); [standby](https://github.com/withnative/native/tree/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/standby). *Limit: Refresh, activation, packaging absent.*

[^a45]: **A45 — public current (stated limit).** Search is stemmed lexical; the embedding hook is a no-op seam. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md); [effective-searching.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/effective-searching.md). *Limit: Semantic retrieval over governed units is open.*

**P7 Cross-session recovery.** *From C6.* Recorded state should survive the current model, context window, client and run. This is the requirement that motivates the whole paper, and in Native it is realised by the combination of durable records, run intent that a later session can resume, interventions that pause an agent action durably until a person records an authorising decision, and a portable node. The intervention design is the sharpest example: when policy blocks a message send, the harness is told to treat the blocked state as a durable pause rather than a failure to retry, may end its process, and a later session in a different client can query the same intervention and continue from its projection. [^a24][^a25] *Limit:* recovery is of recorded shared state, not of hidden reasoning or unrecorded model memory. Native's public evaluation route says this in as many words.

[^a24]: **A24 — public current.** Interventions pause an agent action durably until a person decides; a later session in another client can continue. Evidence: [agent-interventions.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/agent-interventions.md); [interventions.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/records/interventions.rs). *Limit: Recovery is of recorded state only.*

**P8 Qualified human-agent symmetry.** *From C4 and C5.* People and agents should work in the same world through the same semantic boundary where useful, while retaining distinct identity, attribution and authority. Native's guides address the agent as a contributor who acts through a client for a principal and is not that principal. Attribution distinguishes a person's own declaration from an agent's assessment of a person and from an agent's own opinion, and none is upgraded to another by confidence or repetition. Interventions give a person durable authority over an agent action that survives the agent's session. [^a17][^a24][^a29] The symmetry is *qualified* in both directions: agents get the same retrieval, history and coordination surfaces as people, and people retain forms of authority (direct declaration, policy binding at member or workspace scope, intervention decisions) that an agent cannot manufacture. *Limit:* symmetry of the semantic boundary does not imply symmetry of interface. Section 6 takes this up.

[^a29]: **A29 — public current.** Ephemeral representations are not shared context until recorded or linked. Evidence: [render.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/render.rs); [working-in-a-shared-world.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/guides/working-in-a-shared-world.md). *Limit: Norm, not mechanism.*

**P9 Plural projections.** *From C1, C6 and C7.* Neither people nor agents are confined to one interface, and a representation constructed for a purpose does not silently become the underlying authority. This principle is developed in Section 6.

### 5.3 What the principles rule out

These principles give up some attractive simplifications. “Load the folder into the prompt” is easy to understand, but violates P1 and P6. A private memory can give one agent excellent continuity, but violates P3, P4 and P8. Optimistic merge works beautifully for concurrent characters in a document, but a merged decision is not a decision anyone made; making it the default for decisions and messages violates P5 (conflict-free replicated data types [11] remain the right tool for the document case). The principles also rule out treating an agent's summary as the record of what a person decided (P4), or letting context end with the agent's context window (P7).

They do not rule out prompt assembly, retrieval, summarisation or agent memory. All of those remain necessary; they become *downstream uses* of Distributed Context rather than substitutes for it. Retrieval selects from governed units and returns them with their attribution; summarisation produces a representation whose status Section 6 defines; memory is a private placement choice within the same world rather than an invisible layer beside it.

---

## 6. Plural projections: governed state, maintained views, durable artifacts, ephemeral representations

Suppose one person wants project work as a board, another wants decisions in a chronological list, and an agent needs a compact graph of what depends on what. Asking all three to share one interface would make “one connected world” a constraint rather than a benefit. They need the same underlying state, not the same view of it.

That distinction separates four things people often conflate.

**Governed state** is the world itself: records, events, links, facets, policies and attributions. Governed operations write it; authorised queries read it. In Native, event logs and their projections sit behind the semantic operation boundary.

**Maintained product views** are interfaces a vendor keeps working over the governed state. Native's Workbench is one such view. Its browser client uses the same registered tool handlers that agents call, never writes projections directly, and keeps Markdown as the source of truth for ordinary records. [^a26] The public snapshot ships two bounded optional MCP App views—record-version difference and suggestion review—that are explicitly not the Workbench. [^a27] One fact makes the Workbench a projection rather than an authority: it has no write path of its own.

[^a26]: **A26 — held current.** The Workbench writes only through the registered tool handlers and has no private write path. Evidence: none public. *Limit: Architectural description only.*

[^a27]: **A27 — public experimental.** Two bounded MCP App views ship publicly and are not the Workbench. Evidence: [mcp-apps](https://github.com/withnative/native/tree/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/web/mcp-apps); [capability-map.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/capability-map.md). *Limit: Bounded extensions.*

**Durable governed artifacts** are representations that have themselves become records, with identity, history, policy and provenance. In Native, an artifact is a Document whose body is runtime-owned source. The host resolves and authorises its exact inputs, and the renderer returns an inert plan instead of executing in the reader's context. The artifact model is public, and a version-pinned module system lets one artifact import another's exact published release. [^a28] A durable artifact is governed state *about* other governed state. It can be cited, superseded and attributed like anything else, and a later reader can identify exactly what it represented.

[^a28]: **A28 — public current.** Artifacts are Documents with runtime-owned source, exact authorised inputs, inert render plans and version-pinned modules. Evidence: [artifact-runtimes.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/artifact-runtimes.md); [artifacts.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/mcp/tools/artifacts.rs); [artifact-runtime](https://github.com/withnative/native/tree/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/crates/artifact-runtime). *Limit: Browser verifier held.*

**Ephemeral representations** are things an agent or person makes for the task at hand: a prose explanation, a Mermaid diagram, a generated HTML page, a local file, a comparison table. These can be useful without being durable. Native's guidance says not to treat them as shared context until someone deliberately records or links them: “do not assume an exploratory read has become durable shared context”. [^a29]

Figure 3 places these against the planes of Section 4 and Section 7.

![Figure 3. Three planes of a Distributed Context system](/figures/distributed-context/fig3-planes.svg)

*Figure 3. Three planes of a Distributed Context system, with Native's realisation of each. Plane 1 is the governed world: authoritative event logs, the projections rebuilt from them, and the history and change surfaces they support. Plane 2 is how people and agents inhabit that world: a maintained human projection (Workbench, held), agent clients calling typed operations over MCP, and the purpose-specific representations agents construct, which are not canonical unless deliberately recorded. Both enter through one semantic operation boundary where caller identity and policy are evaluated. Plane 3 is where custody and distribution boundaries keep "one world" from meaning "one omniscient database": a portable workspace database, a content-free host catalog that routes to it (held), principal identity custody kept outside content databases (held and architectural), and experimental federation roles. Labels mark which components are publicly inspectable, held, or experimental; the diagram is a map of the argument, not evidence for it.*

Three consequences follow.

First, *the human interface is not the specification of the world*. The Workbench writes through the same operations as agents. A capability absent from the Workbench may still exist in the world, and an agent-constructed view need not be second-class. Native's exploratory work argues that the system should not ask which single representation correctly organises the world. It should maintain one coherent world and let projections make different aspects legible. I advance that formulation as a conceptual thesis, not as evidence that any particular projection model is settled implementation. [^a30]

[^a30]: **A30 — directional.** "One coherent world, many projections". Evidence: Native record `1640e39` (private). *Limit: Conceptual thesis, not settled implementation.*

This is where a governed context world meets *malleable software*: people should be able to adapt tools to their own needs with little friction; the obstacle is ecosystem rather than skill; and code generation alone is not enough because a one-off tool has nothing shared to compose over [46]. The argument needs a substrate. Section 2 describes one. Put identity, history, relationships, authority and attribution in the state rather than in the application that displays it, and the display can change without moving the world. Reading records might appear as a list, a table, or a shelf ordered by rating and last-opened date. A board might show a backlog beside the decisions that produced it. These examples illustrate the argument; this paper does not claim that those views exist.

Native's artifact runtimes are the present-tense evidence for the replaceable half of that claim, and their boundaries carry as much weight as their capability. An MDX artifact declares named ports; the host binds each port to a governed Collection query, selection or folder record and resolves it into a frozen input envelope. Authored MDX composes record lists, tables, cards, fields and charts over exactly those inputs, executes on the server with no network, database, filesystem or tool authority, and returns an inert safe tree rather than code that runs in the reader's browser. Interactions are declared rather than assumed: each is bound to a named port, revalidated and reauthorised inside the write transaction that performs it, while arbitrary live query and mutation are denied. A second runtime accepts a complete self-contained authored HTML document over exact read-only inputs. [^a28][^a53] Two consequences follow for the definition. "All your data" in such a view means all *caller-authorised* data deliberately bound to a port, not ambient access to a workspace. And the division of labour is legible: the author controls selection, grouping, density, layout and permitted interaction; the host retains authorization, provenance, write validation and audit. Malleable presentation is compatible with R4 and R5 precisely because a presentation is a projection.

[^a53]: **A53 — public current (MDX); held current (HTML).** MDX artifacts bind named ports to governed Collections, selections or folders; authored source runs with no network, database or tool authority and returns an inert safe tree; interactions are declared, port-bound and reauthorised in the write transaction, with arbitrary live query and mutation denied. Evidence: [artifact-runtimes.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/artifact-runtimes.md); [tool-surface.generated.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/tool-surface.generated.md). *Limit: the HTML runtime's contract and the hosted authoring experience are held; nothing here is evidence about usability.*

The boundary is plain. Replaceable authored views over governed state exist and can be inspected. Replacing a maintained product shell with authored views is a direction, not a shipped capability, and nothing here shows how good such views are to use. [^a27][^a30]

Second, *a representation can be useful without becoming authoritative*. An agent that draws the accountable chain of Figure 2 as a diagram has produced something a person may act on. The diagram is not the chain. If it is worth keeping, it becomes a durable artifact with exact inputs and its own history; if not, it is a transient view and the guidance says so. The failure mode this prevents is the one where a generated summary quietly replaces the records it summarised.

Third, *projections are where lossy summarisation is supposed to happen*. Section 5's constraint C7 is not a defect to be eliminated; it is what a projection is for. The architecture's job is to make sure that what is lost in a projection can be recovered from the state beneath it, which is why every durable artifact carries exact inputs and why every ephemeral representation is treated as non-canonical.

---

## 7. Custody, portability and federation

R7 says that state must move between storage and custodians without losing R1 to R6, and that custodians must be able to cooperate without any one of them holding everything. This leads from possession, through hosted composition, to federation.

### 7.1 Possession, and the layers of portability

Imagine that the company hosting a team's context closes on Friday. On Monday, can the team hold the state of its work, inspect it and run a compatible reader without asking the former operator? If not, R7 has already failed. So has the local-first argument that ownership of data should not depend on the continued goodwill of a cloud service [8].

Native's strongest present evidence for possession is its portable node. The complete reference database is one SQLite file. `export_snapshot` produces a verified copy whose pages are consistent, retryable and bound to the requesting principal. Anyone holding such a file can run conformance against it, check it against the frozen spine contract and confirm that its projections match its logs. [^a31]

[^a31]: **A31 — public current.** The complete reference database is one SQLite file and `export_snapshot` produces a verified copy. Evidence: [export.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/export.rs); [export_snapshot.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/tests/tools/export_snapshot.rs). *Limit: A file is not hosted composition.*

Possession is necessary and insufficient. Portability has four distinct layers, and collapsing them produces the most common overclaim in this area.

1. **Possession of content bytes.** The workspace database can be exported, copied, and read by a compatible node. *Native: current.*
2. **Logical movement between storage engines.** Content can be moved to a different backend with its semantics intact. *Native: bounded.* Storage profiles describe an engine, its SQL frontend, connection mode and capabilities independently; canonical interchange defines an explicit envelope; a Postgres adapter and an exact-local Turso adapter implement bounded, contract-tested portions of the same domain boundary and fail closed on unsupported operations. SQLite-to-Postgres interchange is bounded and one-way; the reverse, Turso import and export, and cross-backend round trips are absent. The public documentation says these are not interchangeable backends and must not be described as database-agnostic. [^a32]
3. **Runtime continuity.** A person can keep reading their workspace when the hosted service is unavailable. *Native: staged.* A local standby contract fixes a read-continuity design in which hosted Native remains the canonical authority, the standby consumes verified immutable snapshots, promotes them only when a closed frontier comparison proves no regression, and rejects every write with a stable code; the snapshot producer and the offline accept-and-promote kernel are implemented while refresh, activation, packaging and status remain separate slices, and the design explicitly rejects transparent failover because it can hide a change of authority from agents. [^a33]
4. **Product self-hosting.** A person can operate the complete product independently: identity, authentication, membership, backup, restore and coordination domains. *Native: directional.* The public README names this as the intended third publication stage and states that no delivery date is promised. [^a34]

[^a32]: **A32 — public partial.** Postgres and Turso adapters implement bounded parts of the contract and fail closed; interchange is one-way. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/protocol/storage-portability/v1/README.md); [postgres-runtime.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/postgres-runtime.md); [turso-local-runtime.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/turso-local-runtime.md). *Limit: Not interchangeable backends.*

[^a34]: **A34 — directional.** Meaningful self-hosting is an intended later stage with no promised date. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md) "Publication path". *Limit: Not current.*

A SQLite file does not prove layer 4. The public documentation says so: “a portable SQLite database is not proof of portable hosted composition”. The file does not carry hosted accounts, notifications, federation private keys or the Workbench. Still, possession of layer 1 is the foundation for every other layer, and it preserves the strongest property a folder of files has always offered. Distributed Context keeps it.

### 7.2 One world is not one database

One central database is the easiest way to build one connected world. It is also the wrong answer to R7, because it makes the operator the universal custodian. What follows describes Native's hosted composition only at the approved architectural level. [^a35]

[^a35]: **A35 — held current / architectural.** The host keeps a content-free catalog (identity, membership, routing) and routes to per-workspace databases served by the tenancy-unaware engine. Evidence: none public; Native decision `0caea47` (private). *Limit: Architectural description only.*

The host keeps a *content-free catalog* that answers three questions: who is calling, which workspaces they belong to, and which database serves the selected workspace. The host authenticates a request against the catalog, checks membership, routes it to that workspace's database, and hands it to the same tenancy-unaware engine that serves the public stdio node. The catalog holds credentials, routing and tenancy policy but no user content. Each workspace database forms its own content and custody boundary. It carries its records, history, attribution and person bindings, so an operator can export the file and another can adopt it without the catalog. An account may own several workspaces, each backed by its own database; “personal” and “shared” describe a workspace's provenance, not different kinds of workspace. [^a35]

The unit of custody in Native is therefore the workspace database, not the account or the host. The host evaluates membership from the catalog at request time, so membership can change without rewriting the file. But the *content* of the world, with properties R1 to R6, lives in a file the operator can hand back. The host routes and authenticates; it is not the ledger.

Hosted MCP exposes each workspace at its own authenticated endpoint and dispatches through the same tool registry as the public stdio binary, so the agent-facing contract of Section 5 is transport-neutral. [^a21]

### 7.3 Federation as a consequence

Now give two organisations different custodians. A person in one sends a message to the other asking for a decision. The message should arrive with its sealed sender, addressed audience, expectation and supersession trail intact. Yet neither organisation should have to move its workspace into the other's database or accept the other's policy.

Nothing in Sections 3 to 6 requires a shared database, and Section 7.2 argues against requiring a shared custodian. The chain of consequences is short:

```text
one connected context world
  -> must preserve authority and provenance across its units (R4, R5, R6)
  -> cannot require universal central custody (R7, Section 7.2)
  -> therefore consists of independently governed context domains
  -> which must cooperate by protocol: federation
```

This kind of federation is not replication. The two domains do not need to hold the same state. A unit authored in one must be delivered to and governed by the other under the receiver's policy, while keeping its origin and attribution. Nor is it multi-tenancy. Tenants of one operator share a custodian and trust root; federated domains share neither and must establish trust explicitly. Helland distinguishes data inside a service, where it can be transactional and trusted, from data outside, where it must be immutable, self-describing and treated as a message [10]. A federated Message is outside data in exactly that sense.

Native's federation work separates four roles, and the separation carries the argument. [^a37]

[^a37]: **A37 — public experimental.** Federation separates principal node, directory, relay and installation with stated must-nots. Evidence: [federation-transport-v1.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/federation-transport-v1.md) §1. *Limit: Wire profile unstable.*

- A **principal node** holds a principal's private keys, resolves fresh recipient documents, signs and decrypts envelopes and verifies receipts. It must not trust plaintext merely because transport authenticated it.
- A **network authority and directory** anchors a network identifier and attests current associations between principals, keys, aliases and endpoints, preserving public history. It must not author user content or hold principal private keys.
- A **relay** authenticates submitters and collectors, stores opaque encrypted envelopes, maintains per-recipient delivery state and signs scoped receipts. It must not decrypt content, decide content authorization, or act as a canonical content ledger.
- An **installation** holds a scoped key, registers an endpoint, and collects and acknowledges one principal's mailbox. It must not act as the durable principal or author envelopes.

![Figure 4. Federation as a consequence of plural custody](/figures/distributed-context/fig4-federation-roles.svg)

*Figure 4. Federation as a consequence of plural custody. Two independently governed domains exchange a message. Domain A's principal node signs and encrypts an envelope and submits it to a relay, which stores only opaque bytes and per-recipient delivery state and returns a signed receipt. Domain B's node collects the envelope, verifies the sender against the directory's attested key history, decrypts it, and decides under its own policy whether and how to ingest the message into its own database. Neither domain surrenders custody of its content; the relay is not a content ledger; the directory attests keys and never authors content. In the public snapshot the directory is an interface with a preverified development adapter, not an operated service. Solid arrows carry content or authority; dashed arrows carry public attestations or receipts.*

Three properties connect this design back to the definition.

*Transport authentication is not content authorization.* A courier showing valid identification does not decide whether the recipient should file the parcel. Likewise, the specification says that a principal node must not trust plaintext merely because transport authenticated it. Host login credentials sit outside the protocol and cannot substitute for protocol proofs. Authorities do not inherit global trust: operators choose which network descriptors they trust, and an authority must not assert a principal in another network's namespace. [^a38] The receiving domain's own policy (R4) governs what it ingests. Federation extends the world without extending anyone's authority over it.

[^a38]: **A38 — public experimental.** Transport authentication is not content authorization; no implicit global trust between authorities. Evidence: [federation-transport-v1.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/federation-transport-v1.md) §1, §3.3. *Limit: Same.*

*The relay is a temporary encrypted post office, not a conversation database.* The public relay documentation uses those words, adds that the relay never decrypts content or observes destination ingest, that acknowledgement removes ciphertext, and that it refuses to open a Native content database. [^a39] This is the end-to-end argument [5] applied to context: the function that matters (a governed Message arriving in a governed world with its meaning intact) can only be implemented at the endpoints, so the network between them should carry opaque bytes and receipts and nothing more.

[^a39]: **A39 — public experimental.** The relay stores opaque envelopes and delivery state, signs receipts, never decrypts, and refuses to open a content database. Evidence: [federation-relay.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/federation-relay.md). *Limit: Reference implementation, not operated.*

*Content custody and identity custody are separate.* An ordinary export of a shared workspace carries every member's content and attribution and no federation private keys. A person's federation principal (the keys that let a node act as them across domains) lives in an account-scoped custody store outside every content database. Moving a workspace therefore never silently moves anyone else's identity. A separate, principal-authorised *eject* package can carry the exporting person's own encrypted identity bundle alongside the database; on adoption at a new host, a guarded root transition is committed against the directory's monotonic version so that exactly one adoption of a given package can succeed and a stale copy is fenced. The public snapshot contains the identity, custody and adoption kernel with tests for principal-authorised eject, directory-outage retry, and first-adoption-wins fencing; the hosted integration and the operational custody procedures are held. [^a40][^a41]

[^a40]: **A40 — architectural (public statement); held current (hosted custody).** Ordinary export carries no federation private keys; principal identity lives in account-scoped custody outside content databases. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md) limits; [identity.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/crates/native-federation/src/identity.rs). *Limit: Ceremonies not described.*

[^a41]: **A41 — public experimental.** Principal-authorised eject and first-adoption-wins guarded root transition have public tests. Evidence: [principal_lifecycle.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/crates/native-federation/tests/principal_lifecycle.rs). *Limit: Hosted integration held (Native decision `1806141`, private).*

What the public snapshot does *not* establish must be stated with equal care, and the documentation states it. The wire profile is experimental because its key-encryption construction depends on an Internet-Draft, and it must not be advertised as stable. The directory is an interface; the included adapter is a preverified development seam that does not authenticate the documents it loads, and an operated deployment must inject a real implementation. No Native-operated directory, trust, custody or conduct service is implemented in the snapshot, and its presence would not follow from the relay's. The decrypted-content ingest seam is sealed: the public code compares and persists verified values but "does not pretend to authenticate transport input", and the end-to-end federation client has not shipped. Expectation cardinality across several recipients is deferred because sovereign recipient databases cannot reconcile cross-recipient completion without a further protocol. [^a42] Cross-workspace delivery of a Native Message is, at this snapshot, an architectural claim with experimental protocol evidence, not an operational one.

[^a42]: **A42 — public experimental (stated absences).** No Native-operated directory, trust, custody or conduct service is implemented; the directory adapter is a development seam; ingest seam sealed; end-to-end client not shipped. Evidence: [federation-transport-v1.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/federation-transport-v1.md); [federation-relay.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/federation-relay.md); [replication.rs](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/replication.rs); [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md). *Limit: Cross-domain delivery is architectural.*

### 7.4 Optional global services

Global discovery, verification, trust, routing and conduct services can make a federated system easier to use. The public README allows for them while saying they should not be prerequisites for using and governing one's own workspace. [^a43] The four-role separation leaves room for a useful directory without making it mandatory, because domains configure trust rather than inherit it. Whether anyone operates such services, and on what terms, lies outside the present scope.

[^a43]: **A43 — directional.** Optional global services may be operated and are not prerequisites. Evidence: [README.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/README.md). *Limit: Outside the paper.*

---

## 8. Implementation status and evidence

A paper that uses a real system as its case owes the reader a precise account of what that system is, what evidence exists for each claim about it, and what the evidence does not show. This section supplies that account for the whole paper; Appendix A lists every material claim with its class, evidence and limit.

### 8.1 Epistemic classes

Every present-tense statement about Native in Sections 3 to 7 carries one of the classes below, in brackets beside the claim, and the operating figures of Section 8.4 carry the measured class. The classes keep two boundaries apart that are usually conflated. The *truth boundary* is what the author knows and on what basis. The *disclosure boundary* is which known details Native is willing to publish. A held claim may be entirely true and still not be inspectable by the reader; a public claim may be inspectable and still narrow.

| Class | Meaning | Expected phrasing |
|---|---|---|
| `PUBLIC_CURRENT` | Implemented in the named public snapshot, with inspectable source and, where stated, an executable witness | Direct present tense, with a source citation and a material limit |
| `PUBLIC_PARTIAL` | A bounded public implementation exists; a broad reading would overstate it | Qualified present tense naming the implemented subset and the absent remainder |
| `PUBLIC_EXPERIMENTAL` | Public implementation or protocol work exists under an unstable or gated contract | "Experimental", with the unstable boundary named |
| `HELD_CURRENT` | The author attests that it exists; implementation or operational evidence is not public | High-level present tense only, with an explicit statement that the surface is held |
| `HELD_MEASURED` | Measured on Native instances available to the author, with the method and its integrity caveats stated; the underlying data are not in the public snapshot and cannot be reproduced from it | Dated past tense, with the period, population and known hazards stated beside the figure |
| `ARCHITECTURAL` | A committed design or intended system shape, not necessarily completely implemented | "The architecture provides for", "is designed to" |
| `DIRECTIONAL` | A desired path, hypothesis or unresolved design | Future, conditional or research language |
| `CONCEPTUAL` | An argument advanced here | A direct claim, supported by reasoning, examples and literature |

A reader, human or agent, who quotes one of these claims should carry its class with it. The classes principally guard against promoting a `HELD_CURRENT` or `ARCHITECTURAL` statement about hosting, custody or federation into a claim about an operated, inspectable service.

### 8.2 What the public snapshot is, and what its evidence proves

The public evidence base is one curated source inspection snapshot of Native, `withnative/native` at commit `a73fb4d0f6e5e02f3640c5390055479d1b7389bf`, published as open source under the AGPL. It is a deny-by-default projection of a private upstream repository: a machine-readable boundary manifest selects every file that appears, a validator refuses any undeclared file, and the snapshot's parentless root commit records the exact upstream source commit and the digests of the boundary and selected-source manifests in its trailers. Its release notes state that it is "published for inspection, not as a supported build, deployment, or self-hosting distribution", and that runtime, container, export/restore and cold-start qualification belong to a later stage. [^a44]

[^a44]: **A44 — public current.** The public snapshot is a deny-by-default projection with manifest, validator and root-commit trailers. Evidence: [RELEASE_NOTES.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/RELEASE_NOTES.md); [source-boundary.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/source-boundary.md); [native-boundary.json](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/native-boundary.json). *Limit: Inspection snapshot, not supported build.*

The snapshot contains the portable SQLite reference node, the local `mcp-stdio` server and the public tool implementation, the event-authoritative store and projectors, the query and history surfaces, the conformance runner, the federation crate and protocol documents, bounded Postgres and Turso adapters, two bounded MCP App views, tests, and public documentation. It does not contain the hosted control plane, the Workbench, operated release evidence or private product history. [^a44]

Three kinds of executable evidence are available from that root, and each proves something specific.

- **The conformance runner** (`cargo run --locked --bin conformance`) checks a fresh or supplied database against the frozen spine contract, enforces properties such as type immutability as invariants of the event fold, and rebuilds every projection from the logs and compares the result with the live tables. A pass proves that the projections are a deterministic function of the authoritative history and that the spine contract holds. It does not prove that the history records the truth, that anyone wrote sensible policy, or that the node resists a hostile holder of the file. [^a8]
- **Focused tests** named beside each claim in the public capability map exercise one mechanism each: temporal reads, change traversal, write receipts, message expectation, attribution and interpretive claims, coordination, interventions, export, and the federation identity kernel. Each is cited beside the claim it supports.[^public-capability-map]
- **The authorization census** enumerates every registered tool and operation with its disposition and negative evidence, and fails continuous integration when a production operation is missing from the census or a sensitive operation loses its non-disclosure obligation. At the snapshot it lists 72 tools and 179 operations, 174 of them carrying a non-disclosure obligation. [^a15]

[^public-capability-map]: **Public, current evidence.** The [capability map](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/capability-map.md) names focused tests beside the mechanisms they exercise. *Limit: each test supports its stated mechanism, not the system as a whole.*

I consulted the private upstream repository at commit `6e476c92a74e04f5c39f85d434207b08b89d00bf` to understand the architecture as a whole. Nothing derived only from that repository is presented as inspectable. Where a held component is needed to make the architecture coherent—the hosted catalog, the Workbench or identity custody at the host—I identify it and remain at the approved architectural level.

### 8.3 Implementation status at the snapshot

Table 2 summarises the status of every capability used in the argument. The “status” column uses the public capability map's own maturity vocabulary where a public path exists, and the classes of Section 8.1 otherwise.

*Table 2. Implementation status of the capabilities used here, at public snapshot `a73fb4d`.*

| Capability | Where used | Status | Principal public evidence | Material limit |
|---|---|---|---|---|
| Ten spine types with shared placement, facets, links, relationships, history, query and policy; open kinds | §3 | Current | `src/schema/contract.rs`; `src/mcp/guides/record-types.md`; conformance | Contains only what was deliberately recorded or imported |
| Event-authoritative write path; rebuildable projections; deterministic replay | §4.1 | Current | `src/store.rs`; `src/conformance/rebuild.rs`; `tests/kernel/invariants.rs` | Rebuild equality is not a truth or security proof |
| Temporal reads by content sequence or timestamp | §4.1 | Current | `docs/temporal-reads.md`; `tests/kernel/as_of.rs` | Schema, vocabulary and authorization are live; search and SQL are not historical |
| Authorization-filtered change traversal | §4.1 | Current | `docs/whats-changed.md`; `tests/kernel/whats_changed.rs` | Caller-visible only |
| Guaranteed `supersedes` relationship; soft tombstones; lifecycle facets | §4.2 | Current | `src/mcp/guides/links.md`; `src/mcp/guides/lifecycle.md` | Someone must record the supersession |
| Caller-relative View/Edit/Manage policy; no inheritance; separate policy log; per-operation census | §4.3 | Current | `docs/authorization-contract.md`; `crates/policy-kernel` | Local stdio authorization is advisory at the process boundary |
| Attribution, stance, confidence, evidence and endorsement kept distinct; withheld markers without cardinality | §4.4 | Current | `docs/interpretive-claims-conformance.md`; `tests/records/attribution.rs` | Attribution does not certify truth or consensus |
| Message with sealed sender, audience and expectation; expectation satisfied by recipient evidence | §3.3 | Current (local) | `docs/federated-message-content-v1.md`; `tests/records/message_expectation.rs` | Native messaging only; not cross-workspace |
| Bounded bootstrap; retrieval doors; focused and complete tool discovery | §5 P1 | Current | `src/mcp/render.rs`; `docs/tool-surface.md` | Search is lexical, not semantic |
| Run intent, work claims, idempotent writes, interventions | §5 P3, P5, P7 | Current | `src/mcp/guides/coordination.md`; `tests/tools/intent.rs`; `tests/records/interventions.rs` | A claim is advisory; claims do not expire |
| Local MCP server over stdio | §5 | Current | `src/mcp/stdio.rs` | Not a hosted service |
| Hosted MCP endpoints dispatching the same registry | §7.2 | Held | none public | Attested, not inspectable |
| Durable artifacts with exact inputs and version-pinned modules | §6 | Current | `docs/artifact-runtimes.md`; `crates/artifact-runtime` | Renderer verification service is held |
| Bounded MCP App views (record diff, suggestion review) | §6 | Experimental | `web/mcp-apps` | Not the Workbench |
| Workbench as maintained human projection with no private write path | §6 | Held | none public | Architectural description only |
| Complete-database SQLite export with verified snapshot | §7.1 | Current | `src/export.rs`; `tests/tools/export_snapshot.rs` | A file is not hosted composition |
| Postgres and exact-local Turso adapters; storage profiles; canonical interchange | §7.1 | Partial | `protocol/storage-portability/v1/README.md` | One-way, bounded; not interchangeable backends |
| Local standby read continuity | §7.1 | Partial / Directional | `docs/local-standby.md`; `src/standby` | Producer and accept kernel only; no offline authoring |
| Content-free hosted catalog routing to per-workspace databases | §7.2 | Held / Architectural | none public | Architectural description only |
| Federation role separation; wire schemas; encrypted relay reference implementation | §7.3 | Experimental | `docs/federation-transport-v1.md`; `docs/federation-relay.md`; `crates/native-federation` | Wire profile unstable; directory is an interface; no operated services |
| Identity custody and guarded adoption kernel | §7.3 | Experimental (kernel); Held (hosted integration) | `crates/native-federation/src/identity.rs`; `crates/native-federation/tests/principal_lifecycle.rs` | Ceremonies and topology not described |
| End-to-end cross-workspace message delivery | §7.3 | Architectural | stated absences in the protocol documents | Not operational at the snapshot |
| Optional global discovery, trust and conduct services | §7.4 | Directional | `publication/root/README.md` | Not implemented; not prerequisites |
| Context-freshness kernel: units, exact dependencies, receipts | §9.2 | Experimental | `src/freshness/`; `docs/context-freshness-runtime-proof.md` | Deterministic proof only; live calibration not established |
| Meaningful independent self-hosting | §7.1 | Directional | `publication/root/README.md` "Publication path" | No date promised |

### 8.4 Early operating data

A reader of Sections 3 to 7 may reasonably ask whether any of this happens in practice. Native's internal use provides evidence from two systems: its first generation ran for about nine months and is now retired; the current engine replaced it in August 2026 with a new schema, store and event model. The measurements below use different methods on the two systems. Where a rate agrees across the rewrite, the agreement cannot be an artefact of one system's design. That replication is the strongest property of the data.

Everything in this subsection is still instrumentation from running Native on ourselves, not a study: there is no control, no external cohort, and the current engine has been in use for seventeen days by three people. Every figure carries the class `HELD_MEASURED` (Section 8.1): the method is stated, the data are ours, and none of it can be reproduced from the public snapshot. All figures were taken on 3 September 2026 and will be re-measured before any later edition.

The two generations are different products and are never summed. Two hazards apply throughout. First-generation figures were read from one account's authorised view of a multi-workspace deployment and are lower bounds, not a census. On the current engine, attribution of writes to a channel begins on 21 August, so figures that depend on it cover the thirteen days since.[^a48]

[^a48]: **A48 — held measured.** In Native's internal use, records are created almost entirely by agents (98.6% on the first generation; 1,572 of 1,573 attested creations on the current engine), while people edit about 3% of records. Evidence: Native record `dbc0d73` (private). *Limit: internal use by one team; first-generation figures are lower bounds from one account.*

*Table 3. Operating measures across two generations of Native, taken 3 September 2026. Where a measure does not exist for a generation the cell says so, and the text gives the reason.*

| Measure | First generation | Current engine |
|---|---|---|
| Period observed | 11 December 2025 to 1 September 2026 (about nine months) | 18 August to 3 September 2026 (17 days) |
| People in regular use | not separable from one account's view | 3 |
| Live records | 30,108 | 2,462 |
| Content events | 174,980 | 14,742 |
| Records created | 31,823 | 1,573 (attested channel, from 21 August) |
| — by an agent | 31,392 (98.6%) | 1,572 |
| — by a person directly | 100 (0.3%) | 1 |
| — by system processes or inbound forms | 331 (1.0%) | not separable |
| Records a person edited | 1,053 (3.5%) | 69 (2.8%) |
| Records revised after creation | 10,990 (36.5%) | 870 (35.3%) |
| Most revisions on one record, by agents | 152 | 120 |
| Records carrying at least one link | 13,624 (45.3%) | 2,202 (89.4%) |
| Largest connected component | not computed | 1,828 (74.2%) |
| Deliberate retrievals by agents | not instrumented | 1,920,599 |
| — of records older than 24 hours | not instrumented | 64.7% |
| — of records older than 7 days | not instrumented | 25.7% |

Three things in that table are worth drawing out.

**Recording is not, in practice, human work.** The usual objection to durable shared context is the cost of maintenance, with an implicit assumption that people do the maintaining. Native's internal use shows otherwise. Across nine months of the first generation, people created 100 of 31,823 records. On the current engine, one of the 1,573 records created since channel attribution began was created by a person in the web application; agents acting for a person over MCP created the rest. People edited about three per cent of the corpus in both generations, principally to correct, retitle, decide and review rather than enter data. The burden does not disappear, but it moves. The same shift that creates the need for durable context—agents doing consequential work—absorbs most of the cost of producing it; because every agent write is attributed (Section 4.4), that cost remains visible.

**The corpus is maintained, not merely accumulated.** A reasonable follow-up is that a system in which agents write nearly everything will fill with material nobody revisits. That is not what the data show. About a third of records are revised after creation: 36.5% on the first generation and 35.3% on the current engine, a rate that survives a complete engine rewrite to within about a percentage point. Individual records are revised repeatedly; the most-revised record in each generation carried 152 and 120 agent revisions. Revision is what in-band correction (Section 4.2) looks like from the event log.

**An unlinked record is, at the median, an unread one.** This was an unexpected finding. The current engine logs every record an agent deliberately opens, distinct from records that merely appear in a result set; over seventeen days it logged 1,920,599 such retrievals. Table 4 groups records by link count and gives the median deliberate retrievals in each band.

*Table 4. Links on a record against deliberate retrievals of it, current engine, 3 September 2026. Records loaded automatically at session bootstrap (standing instructions and onboarding guidance) are excluded, because they are retrieved without being chosen.*

| Links on the record | Records | Median deliberate retrievals |
|---|---:|---:|
| 0 | 249 | 0 |
| 1–2 | 1,183 | 5 |
| 3–5 | 579 | 129 |
| 6–10 | 323 | 283 |
| 11–25 | 95 | 594 |
| 26 or more | 9 | 1,689 |

The relationship is monotonic and steep. The first generation has no agent read log, so the same measure cannot be taken there; it holds only a marker per record of whether a person ever opened it. That coarser measure moves in the same direction across the same six bands, from 2.8% of unlinked records ever opened by a person to 12.2% of those with twenty-six or more links. Two systems and two definitions of “read”—one for agents, one for people—produce the same monotonic climb. This does not establish that linking causes retrieval; consequential records plausibly attract both. It does show that the two travel together closely enough to change the cost question. The expensive part of recording is not writing something down but placing it where it can be found and connecting it to what it bears on: R3 and the placement discipline of Section 3.2 in operational form. Agents perform that work too.

One further measure bears on the difference between shared state and a longer prompt. Of deliberate retrievals on the current engine, under a tenth were of records created in the previous hour, nearly two thirds reached back more than a day, and a quarter more than a week. The system was seventeen days old when measured, so the far end of that distribution is bounded by the age of the system rather than by behaviour, and the tail is understated. Most of what agents retrieve outlived the session that produced it.

**Repair happens where it is read.** Where supersession is recorded—as a link, lifecycle change or in-body note—the reader sees both versions at the point of reading, while a file shows only the stale one. Three current-engine measures bear on whether this happens in practice. First, of 1,470 edits to records that predated the run, 69.7% followed an opening of the same record in that run. An agent that read the record in an earlier run and edited it later counts as a miss, making this a floor. Second, of 1,971 distinct declared run intents, 9.3% use unambiguous repair language (`correct`, `reconcile`, `stale`, `supersede`), rising to 19.4% when `fix` and `update` are included. Third, provenance checking is routine: roughly one history call for every two deliberate record opens, uniformly across the corpus. Two counterweights qualify these figures. Content later revised had been read about 148 times per version before the change landed—an upper bound on exposure because most revisions are additive rather than corrective. The purpose-built change traversal is also narrowly adopted: `whats_changed` appeared in 71 of 1,717 runs (4%), against 431 uses of `get_history`. Supersession links are excluded as evidence: 52 records carry a typed supersession link, while 246 express supersession in body prose. Link counts therefore measure representation in the schema, not the frequency of repair. These figures use the current engine only, from the 3 September 14:27 UTC backup, and carry the same thirteen-day channel-attribution window as above.[^a51][^a52]

[^a51]: **A51 — held measured.** About seven in ten edits to pre-existing records follow an inspection of that record in the same run (69.7%, n=1,470, floor); about one in ten declared intents is repair work (9.3% floor, 19.4% broad, n=1,971); provenance-checking runs at roughly one history call per two opens. Evidence: Native records `dbc0d73`, `546b0ee8` (private). *Limit: Run-scoped floor; keyword matching crude; current engine 17 days old; 14:27 UTC backup.*

[^a52]: **A52 — held measured.** Content later revised was read about 148 times per version first; purpose-built change traversal used in 4% of runs; supersession link counts undercount repair ~5x and are not used as evidence. Evidence: Native records `dbc0d73`, `546b0ee8` (private). *Limit: 148 overstates error (most revisions additive); `whats_changed` narrow adoption is a real limit.*

**What these numbers do not show.** They do not show adoption: three people use the current engine, and first-generation deployments were internal or involved a small number of organisations working directly with Native. They do not show production scale or performance, nor federation operating across organisations—the least demonstrated part of the architecture (Section 9.6). One measure also fails to replicate: 45.3% of first-generation records carry a link, against 89.4% on the current engine. Composition explains part of the difference, since about 16% of the first-generation corpus was unlinked machine bookkeeping with empty bodies; the current tool surface may also make placement and linking a more ordinary path. The discrepancy is reported rather than discarded. The data further expose a cost of open vocabularies (Section 3.2): the current engine contains three spellings of the same relationship (`relates_to`, `relates-to` and `related_to`) and 33 distinct maturity values, mostly singletons. Free vocabularies drift measurably even when agents are the only writers. Finally, this essay is part of the data. Its drafting, review by eight independent reader agents, synthesis and the decision to add this subsection were coordinated in Native. That is concrete evidence of internal use and precisely why the figures are not a neutral sample.[^a48][^a50]

[^a50]: **A50 — held measured.** Deliberate retrievals rise monotonically with a record's link count, and unlinked records have a median of zero. Evidence: Native record `dbc0d73` (private). *Limit: Correlational; frequency data are one generation deep; truncated by system age.*

### 8.5 What the evidence does not establish

Implementation is not evidence of performance, scale, adoption or reliability. None should be inferred from the existence of the code, the confidence of the prose or a small team's internal use.[^a47] Nor does implementation establish novelty: Section 10 places most of Native's mechanisms in an older lineage. The case study establishes a narrower proposition: the requirements of Section 2 can coexist in one working system used daily within a single workspace, at a public commit that a reader can inspect, export, rebuild and run locally, subject to the trade-offs and residual costs in Section 9. Cross-workspace delivery is excluded from that verdict; it remains protocol and kernel rather than an operated capability.

[^a47]: **A47 — absence of evidence.** No performance, scale, customer or reliability evidence is presented; the only operating data come from Native's internal use. *Limit: none of those properties should be inferred.*

---

## 9. Limits and open problems

The architecture of Sections 3 to 7 relocates several failures rather than abolishing them, and leaves several problems open. This section states them in the order a builder is most likely to meet them.

### 9.1 The recording burden

Distributed Context contains only what was deliberately recorded or imported. Nothing in the architecture observes work outside it, and the product model refuses to convert ordinary conversation into durable state (Section 3.4). Every claimed property, from in-band correction to the accountable chain, is therefore conditional on someone or something recording the relevant work. Native's guidance shifts much of that burden to agents, while interventions and intent mechanisms make their recording inspectable. A norm of recording is still not a guarantee.[^a6][^a29]

The objection as usually raised assumes that people do the recording. Section 8.4 measures where the burden has in fact fallen in Native's own use: on both generations of the engine, more than 98% of records were created by agents, people touched about three per cent of the corpus, and what they did there was correct, retitle, decide and review. If agents do the consequential work, agents do the recording, and because every agent write is attributed the cost is visible where it falls.[^a48][^a50] That relocates the cost rather than removing it. I argue that this is the appropriate place for the residual cost because it is visible and attributable. It is most worth paying where work is consequential, long-lived and multi-party, and where reconstruction, duplication and stale decisions would otherwise exact the cost later; for a one-off task with one contributor and stable context, the structure may cost more than it returns. The same data suggest that the expensive part is not writing a record but placing and linking it: the median unlinked record is never retrieved, and agents also perform the work of placement.

It also matters which burden is at issue. The costly image—someone leaving the work to transcribe it into a system of record afterwards—describes the *acquisition of context from outside the world*: importing a document, capturing a page, restating what happened elsewhere. That cost is real and Native does not remove it. Work done inside the shared world is different in kind, because its history is a by-product of doing it: the record written, the revision, the read that preceded the edit, the claim, the declared intent, the message and the governed evidence that closed it are the work, not a report filed about it. What is not automatic is meaning. Placement, linking, supersession and the judgement that two units belong together are acts of interpretation, and Section 8.4's finding that the median unlinked record is never retrieved is the sharp form of the point: an unplaced, unlinked corpus is a cost already paid for a benefit not yet collected. The residual burden of Distributed Context is therefore chiefly semantic stewardship, and the architecture is fairly judged on how cheap it makes that rather than on whether it abolishes recording.[^a48][^a50][^a51]

### 9.2 Three kinds of staleness, and the freshness frontier

Section 4.2 distinguished three ways context goes stale. The first, *superseded and recorded*, is the one the architecture handles: the old record carries its supersessor and a reader sees it. The second, *live but wrong*, is not handled: a record nobody has corrected remains plausible, and no mechanism in the public snapshot detects that the world has moved away from it. The third, *true but the audience moved*, is subtler: a statement that was and remains correct about one environment misleads readers who have changed environment, and no record-level mechanism can see that, because nothing about the record changed.

Native's public snapshot contains an experimental kernel aimed at the second and third cases: exact expressions can be promoted into stable units, an output's selected sources and declared dependencies can be sealed into a receipt, later source revisions can be compared against that receipt, and uncertainty about materiality can be propagated to the reader rather than resolved silently. The deterministic proof for that kernel is public, and it is explicit about its own limit: the tests prove auditability, fail-closed behaviour and authorization non-leakage, but not that live agents declare dependencies or judge materiality reliably; that requires a calibration study the snapshot does not contain.[^a46] I regard this as the most important open research problem in the area. The kernel is not evidence for the ordinary history and supersession claims, which stand without it. Two questions remain unresolved: whether agents can declare the dependencies that matter without under-declaring, which hides staleness, or over-declaring, which drowns it; and whether materiality is decidable independently of the task at hand.

[^a46]: **A46 — public experimental.** The freshness kernel seals sources and dependencies into receipts and propagates uncertainty; its proof is deterministic and does not establish live calibration. Evidence: [src/freshness/](https://github.com/withnative/native/tree/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/src/freshness/); [context-freshness-kernel.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/context-freshness-kernel.md); [context-freshness-runtime-proof.md](https://github.com/withnative/native/blob/a73fb4d0f6e5e02f3640c5390055479d1b7389bf/docs/context-freshness-runtime-proof.md). *Limit: Not evidence for ordinary history claims.*

### 9.3 Retrieval is lexical

Search in the public snapshot is stemmed lexical full-text search over the caller's visible records; the embedding hook is a no-op seam. Structured query, relationship traversal, scan and historical reads compensate for many purposes, and the search guide teaches a discipline for the rest.[^a45] Governed state and good retrieval remain separate problems. A context system with excellent governance and poor recall may still send an agent to the wrong record, then faithfully attribute the resulting error. Semantic retrieval over governed units, with authorization and attribution preserved through retrieval, remains an open engineering problem.

### 9.4 Coordination is advisory

The work claim is a signal, not a lock. It is refused when occupied, it names the holder, and the guidance is to re-read and decide again; but ordinary record updates do not check claim occupancy, claims do not expire, and a disconnected client leaves its claim behind for an operator to recover.[^a22] This is deliberate: a lock that an agent could take and abandon would be worse than a claim an agent can inspect and reason about. Where mutual exclusion is required, it must instead be built from idempotency keys, preconditions and re-reads. The appropriate concurrency model for decisions and messages rather than characters remains unsettled. Section 5.3 rules out automatic merge as the default but offers no complete answer beyond *conflict as information*.[^c7]

[^c7]: **C7 — conceptual.** The architecture relocates failures to visible places rather than abolishing them. *Limit: the residual burden remains real.*

### 9.5 Authority stops at the file

Caller-relative policy is enforced at the semantic operation boundary. A holder of the SQLite file on a local node is below that boundary and can read or modify the database directly, so local authorization is advisory at the process boundary.[^a14] Within a hosted domain the operator holds the file and the service forms the boundary; within a self-hosted domain, whoever runs the node holds it. R4 is therefore satisfied *relative to a custody arrangement*. I make no claim about encryption at rest, confidentiality against the custodian, or any other property that would require more than application policy; conformance proves nothing about security. Possession, treated as a requirement in Section 7, and authority, treated as a requirement in Section 4, meet in a tension resolved by trust in the custodian rather than by mechanism.[^c7]

### 9.6 One domain, for now

Every `PUBLIC_CURRENT` claim concerns one workspace database. Cross-domain delivery of a Message with audience, expectation and supersession trail intact remains an architectural claim supported by experimental protocol evidence, not an operational instance. The relay and identity kernel exist; the directory is an interface with a development adapter; the decrypted-content ingest seam is sealed; and the protocol defers expectation cardinality across sovereign recipients because no further protocol reconciles their independent completion evidence.[^a42] Federation follows from the definition whether or not the implementation is complete. Even so, readers should weigh that the hardest part of R7—cooperation between custodians without a universal owner—is also the least demonstrated.

### 9.7 Open design questions

Four further questions remain open in Native's own design discussion.

1. **One canonical placement.** Every record has exactly one browse home. That coordinate makes export, navigation and policy anchoring simple; it also imposes a hierarchy on a world whose relationships are plural. Whether a single mandatory structural coordinate is a principle or a convenience is unsettled (Section 3.2).[^a3]
2. **The size of the semantic surface.** Semantic operations (P2) multiply, and 72 tools with 179 operations is a large vocabulary for an agent with bounded context (P1). Focused discovery profiles and byte ceilings manage the tension; they do not remove it. Whether the surface can be made smaller without collapsing back into generic reads and writes is an open question.[^c4]
3. **Durable agent identity.** A run key correlates activity and is explicitly not identity. The architecture separates principal, executor, channel and run, but does not yet offer an agent a durable cross-run identity distinct from the principal it serves; whether it should is itself unsettled. The consequences for attributing long-lived agents remain unexplored.[^a25]
4. **Scale.** The reference node is one SQLite file with a single writer, and no performance measurements are reported. Separating the tenancy-unaware engine from the host catalog is intended to make per-workspace scale a hosting concern rather than an engine concern, but this remains an architectural statement rather than a measured result.[^a47]

[^c4]: **C4 — conceptual.** Nine agent-facing principles are derived from seven constraints. *Limit: this is one derivation, offered for disagreement.*

### 9.8 Scope of the claims

Native does not solve “context”; its mechanisms are not individually novel; the principles of Section 5 are not asserted as universal; no operated cross-workspace service exists; and the snapshot is neither a supported build nor a self-hosting distribution. The local node does run: it serves MCP over stdio, exports verified snapshots and rebuilds deterministically under conformance. The narrower claim is that the definition in Section 2 is coherent and useful, that its requirements can coexist in one working, inspectable system used daily within a single workspace, and that doing so relocates specific failures to visible places. Federation across custodians is the exception: there the claim is architectural, with experimental protocol evidence, rather than operational.

---

## 10. Related work and implications

These ideas have a long lineage. The contribution lies in their combination and derivation, not in any single mechanism.

### 10.1 Augmentation and hypertext

The ambition to keep a person's working world as connected, addressable, versioned state is as old as computing's account of itself. Bush's memex organised knowledge by associative trails that a reader could record and share [18]; Engelbart's augmentation framework treated the structured, linked, jointly edited record as the substrate on which human capability would be extended [19]; Nelson's file structure was explicitly designed for the "complex, the changing and the indeterminate", with versions and links as first-class objects [20]; and Halasz's reflections on NoteCards named versioning, collaborative work and computation over the network as the unsolved issues of hypermedia twenty years later [21]. Distributed Context inherits the linked, versioned world from this tradition and adds two things it lacked: a governed, caller-relative authority model, and a second class of reader and writer, the agent, whose constraints (Section 5.1) differ from a person's. Typed spine records with an open kind vocabulary are a direct descendant of Halasz's call for typed nodes and composites.

### 10.2 Conversations for action and their critics

Winograd and Flores's language/action perspective, and the Coordinator system built on it, treated a request as a speech act that opens an obligation to be closed by declared completion [22, 23]. Native's Message expectation (Section 3.3) preserves the request-with-expected-completion structure but changes what closes it: governed evidence authored by the party who owes completion rather than a declaration by either party. Suchman argued that the Coordinator's fixed categories of intent impose a discipline inconsistent with how organisational work is actually negotiated [43]. Two features of the present design respond without settling the debate: the expectation vocabulary is small and sender-declared rather than system-imposed, and completion rests on evidence rather than category. Whether five expectation values are few enough to avoid the failure Suchman described is an empirical question left open here.

### 10.3 Provenance, time and immutability

The separation of entities, activities and agents in the W3C PROV model and the Open Provenance Model [15, 16], and the earlier characterisation of why- and where-provenance in databases [14], underlie Section 4.4's treatment of attribution and evidence; Native's addition is the stance layer between provenance and content. Its history mechanism belongs to the tradition of temporal databases [17], event sourcing [12], and the argument that immutability simplifies distributed systems [9], with derived state treated as a rebuildable view in the sense Kleppmann develops [13]. Lamport's ordering of events [1] is the ancestor of every "as of event position" read. Helland's distinction between data on the inside and data on the outside [10] is the framing under which a federated Message (Section 7.3) is data on the outside: immutable, self-describing and interpreted under the receiver's policy.

### 10.4 Authority and access

Native's authorization contract realises fail-safe defaults and complete mediation in Saltzer and Schroeder's sense [3] over an access-matrix model of the kind Lampson described [4]: dispositions are evaluated per operation and caller, with negative evidence adjacent to positive. It differs from role-based access control [24] by anchoring policy at records rather than roles, and from capability systems [25] because possessing a reference never grants access (R4). Its census discipline—every operation must declare its disposition and non-disclosure obligation or fail the build—is closer to conformance methodology than policy language. I regard that discipline as more transferable than any particular policy model.

### 10.5 Possession, local-first and federated protocols

The local-first programme [8] states the possession requirement more forcefully and makes conflict-free replicated data types [11] its default mechanism for multi-device collaboration. Distributed Context shares the possession goal but departs at the merge: Section 5.3 argues that automatic merge is the wrong default for decisions and messages. The same laboratory's malleable-software argument [46] states the half of possession that concerns interfaces: owning the data while depending on one vendor's fixed presentation of it leaves much of practical agency behind, and shared substrate rather than generated code is what makes composition possible; Section 6 takes that as the presentation-side requirement on a context world. Solid's personal data pods [28] pursue possession through per-person storage and standard protocols; Native's unit of custody is the workspace, and its boundary is a governed database rather than a set of resources. Among federated protocols, Matrix replicates room state across participating servers [27]—federation as replication—while ActivityPub delivers activities to actors' inboxes for local handling [26]—federation as delivery. Native's experimental design follows the second model, adding a typed expectation to the delivered unit and applying the receiver's own policy at ingest. Section 7.3 applies the end-to-end argument [5] in its original form: the relay carries opaque bytes because the relevant function can be completed only at the endpoints. Fielding's uniform interface [7] is the principled alternative to Section 5's semantic operations, and the choice is a real trade-off: uniform verbs are learnable and small; semantic operations are legible in the event log. Clark's account of the Internet's design [2] and the Dynamo paper [6] are methodological models rather than sources for the claims made here.

### 10.6 Agents, memory and tools

Retrieval-augmented generation [29], the measured limits of long context [30], and context-engineering practice [36, 37] belong to the prompt-centred tradition described in Section 1. Agent memory systems—from MemGPT's paging between context and storage [31], through generative-agent memory streams [34], to surveyed [41] and productised [42] long-term memory—give an agent continuity. With few exceptions, that memory remains private to the agent, unattributed to anyone else and governed only by the agent's operator. Tool-use methods [32, 33] and the Model Context Protocol [35], which Native uses as its transport, define how an agent acts on an external system but not what that system's state should be. Multi-agent frameworks such as MetaGPT [38] and AutoGen [39] share message pools and roles within one runtime, while the Agent2Agent protocol [40] standardises task hand-off across runtimes; neither supplies durable, governed, attributed state that outlives the agents and is equally readable by people. Distributed Context names the layer these systems presuppose and leave implicit: the shared state from which retrieval selects, memory summarises, tools act and agents coordinate. It complements rather than replaces them.

### 10.7 Implications

For builders of agents, the principal implication is that retrieval, memory and summarisation should be designed as downstream uses of governed state, with attribution and authority carried through them, rather than as the place where context lives. The constraints of Section 5.1 are the design inputs; the principles of Section 5.2 are one derivation from them and are offered for reuse and disagreement.

For organisations, the implication is that the unit of custody matters more than the choice of vendor. A workspace whose complete state can be exported as one file, with its history and attribution, and re-opened by a compatible node, is in a different position from one whose state is a vendor's database, whatever the two vendors' terms. Section 7.1 gave the four layers at which that claim must be tested; only the first is currently demonstrated for Native.

There is an economic implication in the same direction, and it is the reason the motivational argument of Section 1 is worth making in structural terms. Coordination between organisations is expensive partly because claims arrive stripped of the properties that made them checkable: who asserted this, on what evidence, under whose authority, and whether something later superseded it. Where those properties travel with the unit across a custody boundary under the receiver's own policy (Section 7.3), delegation and coordination need not presuppose a common owner—a shared platform, a dominant counterparty, or a marketplace that holds everyone's state as the price of interoperating. That is a claim about what the architecture makes possible rather than a measured effect, and the part of Native it depends on is the least demonstrated (Section 9.6).

For research, the open problems of Section 9 are the agenda: freshness that agents can be trusted to maintain; retrieval that preserves governance; concurrency control for decisions; durable agent identity; and reconciliation of completion evidence across sovereign domains.

The claim that this constitutes an infrastructure category is deliberately modest. If context for consequential human-agent work is shared state, something must hold that state with the properties in Section 2; it is unlikely to be the prompt, the model or any one application. Whether that role belongs to Native, a standard or several systems that agree on a spine remains open.

---

## 11. Conclusion

The opening failure was ordinary: an agent answered from a memo because the correction, the superseding decision and the author's departure lived elsewhere. Treating context as a transient input makes that failure structural. Treating it as durable, connected, governed state makes the missing properties definitional and moves residual failures to visible places. Recording becomes an explicit obligation; staleness becomes a visible supersession or an admitted gap; authority becomes a per-operation disposition with its negative evidence adjacent; movement across custodians becomes a protocol whose roles cannot be quietly merged.

Native demonstrates that these requirements can coexist in one working, inspectable system used daily within a single workspace: runnable locally, exportable as one file and rebuildable from its logs. Its public documentation is equally explicit about what remains undone. Cross-workspace delivery is the principal absence—protocol and kernel, not operation. I offer the definition, requirements, constraints and principles for testing against other systems, and for quotation without loss of their boundaries.

---

## Glossary

Terms are defined as used here. Where Native's public documentation uses the same term, the definitions agree.

- **Accountable chain.** A sequence of related units of work (for example message, task, document, decision, superseding decision, agent action) whose relationships and history a later reader can traverse to answer why something happened and whether the reason still holds.
- **Artifact.** A durable governed representation that is itself a record: in Native, a Document whose body is runtime-owned source with exact, authorised inputs.
- **Attribution.** A record of who asserted or assessed what, on what evidence. Distinct from visibility, authorship, stance, confidence, endorsement, consensus and permission.
- **Claim (work claim).** An advisory coordination signal that one holder is working on a record. Not a lock and not a permission.
- **Custody.** Who holds the state and can hand it back. In Native the unit of custody is the workspace database.
- **Directory (network authority).** In federation, the role that attests associations between principals, keys, aliases and endpoints, and never authors content.
- **Distributed Context.** Durable, connected, governed state shared by people and AI agents across applications, sessions, organisations and time, in which each unit has stable identity, recorded history, explicit relationships, defined authority and attribution, and in which corrections and movement between custodians are recorded within the state. (Section 2.1.)
- **Domain (context domain).** One independently governed body of Distributed Context with its own authority and custody; in Native, a workspace.
- **Eject.** A principal-authorised package that carries a person's own encrypted identity bundle alongside a workspace database so that both can be adopted at a new host. Described here at the architectural level.
- **Event authority.** A design in which an append-only event log is the source of truth and all queryable tables are projections rebuilt from it. Native's mechanism for history; not part of the definition of Distributed Context.
- **Expectation.** A Message's sender-declared statement of what would satisfy it (`none`, `ack`, `reply`, `action`, `decision`), satisfied only by governed recipient evidence.
- **Facet.** A typed or governed attribute attached to a record without widening the spine type.
- **Federation.** Cooperation between independently governed context domains by protocol, such that a unit authored in one can be delivered to, ingested by and governed in another under the receiver's policy. Distinct from replication and from multi-tenancy.
- **Held.** A component or evidence that exists outside the public snapshot. A held claim is an author attestation, not an inspectable fact.
- **Kind.** The open extension vocabulary beneath a closed spine type (for example, a Document of kind note, page, attachment or artifact).
- **Placement.** A record's single canonical browse home in a containment tree. Distinct from links, which are plural.
- **Principal.** The person or organisation on whose behalf an actor acts. An agent acts through a client for a principal and is not that principal.
- **Projection.** Any derived view of governed state: a queryable table rebuilt from events, a maintained product interface, or an ephemeral representation an agent constructs. A projection is not canonical unless deliberately recorded as a record.
- **Relay.** In federation, a temporary encrypted post office that stores opaque envelopes and delivery state and signs receipts; not a content ledger.
- **Run key.** A correlation handle grouping one activity's reads and writes across hand-offs. Not an identity.
- **Spine.** The closed set of record types (ten in Native) that share identity, placement, facets, links, history, query and policy.
- **Stance.** A recorded claim that a subject expresses or endorses a view over an exact content revision or passage.
- **Supersession.** A recorded relationship from a replacing unit to the replaced one that preserves the earlier unit and makes the correction discoverable from it.
- **Temporal read.** A structured read of records, links and facets as they stood at a given content sequence or time, with live schema and policy applied.
- **Withheld.** A response marker meaning that something the caller may not see exists or may exist, without disclosing how much.
- **Workspace.** In Native, one governed, portable content database and the world it holds; the unit of custody and of policy.

---

<!-- claim-evidence-notes -->
---

## Appendix A. Claim, mechanism, evidence and limit ledger

This ledger lists every material claim about Native, its epistemic class (Section 8.1), mechanism, principal public evidence at snapshot `a73fb4d0f6e5e02f3640c5390055479d1b7389bf`, and the limit that must travel with it. Conceptual claims are listed at the end. Paths are relative to the public repository root.

| # | Claim | Class | Mechanism | Evidence | Limit | § |
|---|---|---|---|---|---|---|
| A1 | Ten spine types share identity, placement, facets, links, relationships, history, query and policy; kinds extend them openly | PUBLIC_CURRENT | Frozen spine contract; core kinds; facets | `src/schema/contract.rs`; `src/mcp/guides/record-types.md`; `cargo run --bin conformance` | Only deliberately recorded content is in the world | 3.2 |
| A2 | Record type is immutable through ordinary update and changeable only by a governed correction | PUBLIC_CURRENT | Fold invariant checked by conformance | `src/conformance/mod.rs` (type-immutability) | Correction operation is itself governed and recorded | 3.2 |
| A3 | Placement is single and canonical; links are plural and never change placement | PUBLIC_CURRENT | Containment tree separate from link index | `src/mcp/guides/placement.md` | Whether single placement is a principle is open | 3.2, 9.7 |
| A4 | A Message seals sender, audience, reply/supersession links and expectation at creation | PUBLIC_CURRENT | Messaging operations; generic update cannot alter them | `docs/message-first-conversations.md`; `src/mcp/tools/messaging.rs` | Native messaging only | 3.3 |
| A5 | `action` and `decision` expectations are satisfied only by recipient-authored governed evidence derived from the message | PUBLIC_CURRENT | Live derivation from WorkItem lifecycle or decision record | `src/message_expectation.rs`; `tests/records/message_expectation.rs` | Cardinality across several recipients is deferred cross-domain | 3.3, 9.6 |
| A6 | Ordinary conversation is not silently converted into durable state; private agent context is a separate placement | PUBLIC_CURRENT | Product model; explicit acquisition boundary | `src/mcp/guides/product-model.md` | Recording is a deliberate act and a cost | 3.4, 9.1 |
| A7 | Every content mutation appends an event and projects in the same transaction; projections are never independent truth | PUBLIC_CURRENT | Domain transaction; projector | `src/store.rs`; `src/lib.rs`; `tests/kernel/invariants.rs` | Rebuild equality is not a truth or security proof | 4.1 |
| A8 | Replay rebuilds projections and conformance diffs them against live state | PUBLIC_CURRENT | Rebuild-and-diff | `src/conformance/rebuild.rs`; `cargo run --bin conformance` | Same as A7 | 4.1 |
| A9 | Structured reads accept `as_of` by sequence or timestamp and echo the resolved position beside the live head | PUBLIC_CURRENT | Prefix replay | `docs/temporal-reads.md`; `tests/kernel/as_of.rs` | Schema, vocabulary, authorization live; search and SQL not historical | 4.1 |
| A10 | Change traversal is stateless, authorization-filtered, pins a high-water mark and never shrinks a page for hidden events | PUBLIC_CURRENT | Pinned window; grouping by record, actor, run | `docs/whats-changed.md`; `tests/kernel/whats_changed.rs` | Caller-visible only | 4.1 |
| A11 | Direct writes return the pre-write highest sequence; twelve mutating tools require a stated reason stored in the event | PUBLIC_CURRENT | Write receipt; reason in payload | `src/mcp/guides/lifecycle.md`; `tests/kernel/write_path.rs` | Count is snapshot-specific | 4.1, 5.2 |
| A12 | `supersedes` is a guaranteed spine relationship indexed in both directions; deletion is a soft tombstone | PUBLIC_CURRENT | Relationship index; tombstones | `src/mcp/guides/links.md`; `src/mcp/guides/lifecycle.md` | Someone must record the supersession | 4.2 |
| A13 | Native does not abolish staleness; a live but wrong record remains misleading | PUBLIC_CURRENT (stated limit) | none | `README.md`; `docs/capability-map.md` row 1 | Adopted as the paper's standard | 4.2, 9.2 |
| A14 | View/Edit/Manage is evaluated per registered operation; policies are complete replacement boundaries with no inheritance; policy has its own log | PUBLIC_CURRENT | Policy kernel; separate authoritative log | `src/authorization.rs`; `crates/policy-kernel`; `docs/authorization-contract.md` | Local stdio authorization advisory at process boundary | 4.3, 9.5 |
| A15 | The authorization census lists 72 tools and 179 operations with negative evidence and fails CI on omission | PUBLIC_CURRENT | Generated census; CI test | `docs/authorization-contract.md`; `tests/tools/authorization_contract.rs` | Counts are snapshot-specific | 4.3, 8.2 |
| A16 | Conversation policy never widens message access; sharing history is an explicit bounded grant | PUBLIC_CURRENT | Conversation as classification, not roster | `docs/message-first-conversations.md` | Cannot recall bytes already delivered | 4.3 |
| A17 | Visibility, authorship, contribution, stance, confidence, evidence and endorsement are kept distinct; endorsement only by a person's own declaration | PUBLIC_CURRENT | Attribution and interpretive-claims subsystems; interpretation limits | `src/mcp/guides/interpretive-claims.md`; `docs/interpretive-claims-conformance.md`; `tests/records/attribution.rs` | Attribution does not certify truth or consensus | 4.4 |
| A18 | Withheld evidence is marked without cardinality; hidden and absent are indistinguishable | PUBLIC_CURRENT | Normalised errors; non-counted marker | `docs/interpretive-claims-conformance.md`; `docs/context-freshness-runtime-proof.md` | Per-operation contract, no general theorem | 4.4, 5.2 |
| A19 | `bootstrap` returns bounded orientation, standing instructions, a run handle and next operations, and says it is not proof of absence | PUBLIC_CURRENT | Bootstrap render | `src/mcp/render.rs` | Orientation cannot know the task | 5.2 |
| A20 | Tool discovery has focused and complete profiles with byte ceilings that change neither authorization nor dispatch | PUBLIC_CURRENT | Discovery profiles | `docs/tool-surface.md`; `docs/tool-surface.generated.md` | Lossy presentation control | 5.2 |
| A21 | Typed operations are registered once and dispatched through every transport | PUBLIC_CURRENT (stdio); HELD_CURRENT (hosted) | Registry | `src/mcp/registry.rs`; `src/mcp/stdio.rs` | Hosted composition not inspectable | 5.2, 7.2 |
| A22 | Work claims are checked in one transaction, refuse a second claimant by name, and are advisory | PUBLIC_CURRENT | Claim operation | `src/mcp/tools/work.rs`; `src/mcp/guides/coordination.md` | Not a lock; no expiry; updates ignore occupancy | 5.2, 9.4 |
| A23 | Consequential writes carry idempotency keys; identical retry returns the durable result; changed intent conflicts | PUBLIC_CURRENT | Idempotency | `src/mcp/guides/working-in-a-shared-world.md`; `docs/context-freshness-runtime-proof.md` | Per-operation | 5.2 |
| A24 | Interventions pause an agent action durably until a person decides; a later session in another client can continue | PUBLIC_CURRENT | Intervention records and projection | `docs/agent-interventions.md`; `tests/records/interventions.rs` | Recovery is of recorded state only | 5.2 |
| A25 | Run intent and lineage let a later session resume an activity | PUBLIC_CURRENT | `set_intent`; run key; parent run | `tests/tools/intent.rs`; `src/mcp/guides/coordination.md` | Run key is not identity | 5.2, 9.7 |
| A26 | The Workbench writes only through the registered tool handlers and has no private write path | HELD_CURRENT | Same registry | none public | Architectural description only | 6 |
| A27 | Two bounded MCP App views ship publicly and are not the Workbench | PUBLIC_EXPERIMENTAL | MCP Apps | `web/mcp-apps`; `docs/capability-map.md` | Bounded extensions | 6 |
| A28 | Artifacts are Documents with runtime-owned source, exact authorised inputs, inert render plans and version-pinned modules | PUBLIC_CURRENT | Artifact runtime | `docs/artifact-runtimes.md`; `src/mcp/tools/artifacts.rs`; `crates/artifact-runtime` | Browser verifier held | 6 |
| A29 | Ephemeral representations are not shared context until recorded or linked | PUBLIC_CURRENT | Bootstrap guidance | `src/mcp/render.rs`; `src/mcp/guides/working-in-a-shared-world.md` | Norm, not mechanism | 6 |
| A30 | "One coherent world, many projections" | DIRECTIONAL | none | Native record `1640e39` (private) | Conceptual thesis, not settled implementation | 6 |
| A31 | The complete reference database is one SQLite file and `export_snapshot` produces a verified copy | PUBLIC_CURRENT | Export | `src/export.rs`; `tests/tools/export_snapshot.rs` | A file is not hosted composition | 7.1 |
| A32 | Postgres and Turso adapters implement bounded parts of the contract and fail closed; interchange is one-way | PUBLIC_PARTIAL | Storage profiles; canonical interchange | `protocol/storage-portability/v1/README.md`; `docs/postgres-runtime.md`; `docs/turso-local-runtime.md` | Not interchangeable backends | 7.1 |
| A33 | Local standby consumes verified snapshots, promotes only on a closed frontier comparison, rejects writes, and rejects transparent failover | PUBLIC_PARTIAL / DIRECTIONAL | Standby kernel | `docs/local-standby.md`; `src/standby` | Refresh, activation, packaging absent | 7.1 |
| A34 | Meaningful self-hosting is an intended later stage with no promised date | DIRECTIONAL | none | `README.md` "Publication path" | Not current | 7.1 |
| A35 | The host keeps a content-free catalog (identity, membership, routing) and routes to per-workspace databases served by the tenancy-unaware engine | HELD_CURRENT / ARCHITECTURAL | Catalog and router | none public; Native decision `0caea47` (private) | Architectural description only | 7.2 |
| A36 | Membership is evaluated at request time and changes without rewriting the file | HELD_CURRENT | Host-supplied membership at evaluation | `docs/authorization-contract.md` (evaluation input, public); host composition (held) | Same | 7.2 |
| A37 | Federation separates principal node, directory, relay and installation with stated must-nots | PUBLIC_EXPERIMENTAL | Protocol specification | `docs/federation-transport-v1.md` §1 | Wire profile unstable | 7.3 |
| A38 | Transport authentication is not content authorization; no implicit global trust between authorities | PUBLIC_EXPERIMENTAL | Specification statements | `docs/federation-transport-v1.md` §1, §3.3 | Same | 7.3 |
| A39 | The relay stores opaque envelopes and delivery state, signs receipts, never decrypts, and refuses to open a content database | PUBLIC_EXPERIMENTAL | Relay reference implementation | `docs/federation-relay.md` | Reference implementation, not operated | 7.3 |
| A40 | Ordinary export carries no federation private keys; principal identity lives in account-scoped custody outside content databases | ARCHITECTURAL (public statement); HELD_CURRENT (hosted custody) | Custody separation | `README.md` limits; `crates/native-federation/src/identity.rs` | Ceremonies not described | 7.3 |
| A41 | Principal-authorised eject and first-adoption-wins guarded root transition have public tests | PUBLIC_EXPERIMENTAL | Identity kernel | `crates/native-federation/tests/principal_lifecycle.rs` | Hosted integration held (Native decision `1806141`, private) | 7.3 |
| A42 | No Native-operated directory, trust, custody or conduct service is implemented; the directory adapter is a development seam; ingest seam sealed; end-to-end client not shipped | PUBLIC_EXPERIMENTAL (stated absences) | none | `docs/federation-transport-v1.md`; `docs/federation-relay.md`; `src/replication.rs`; `README.md` | Cross-domain delivery is architectural | 7.3, 9.6 |
| A43 | Optional global services may be operated and are not prerequisites | DIRECTIONAL | none | `README.md` | Outside the paper | 7.4 |
| A44 | The public snapshot is a deny-by-default projection with manifest, validator and root-commit trailers | PUBLIC_CURRENT | Source boundary | `RELEASE_NOTES.md`; `docs/source-boundary.md`; `native-boundary.json` | Inspection snapshot, not supported build | 8.2 |
| A45 | Search is stemmed lexical; the embedding hook is a no-op seam | PUBLIC_CURRENT (stated limit) | FTS | `README.md`; `src/mcp/guides/effective-searching.md` | Semantic retrieval over governed units is open | 9.3 |
| A46 | The freshness kernel seals sources and dependencies into receipts and propagates uncertainty; its proof is deterministic and does not establish live calibration | PUBLIC_EXPERIMENTAL | Freshness kernel | `src/freshness/`; `docs/context-freshness-kernel.md`; `docs/context-freshness-runtime-proof.md` | Not evidence for ordinary history claims | 9.2 |
| A47 | No performance, scale, customer or reliability evidence is presented; the only operating data come from Native's internal use | (absence) | none | none | None should be inferred | 8.5, 9.7 |
| A48 | In Native's internal use, records are created almost entirely by agents (98.6% on the first generation; 1,572 of 1,573 attested creations on the current engine) and people edit about 3% of records | HELD_MEASURED | Event log and write attestations | Native record `dbc0d73` (private) | Internal use by one team; first-generation figures are lower bounds from one account | 8.4, 9.1 |
| A49 | About 36% of records are revised after creation on both generations of the engine | HELD_MEASURED | Event log | Native record `dbc0d73` (private) | Same; the current engine is 17 days old | 8.4 |
| A50 | Deliberate retrievals rise monotonically with a record's link count, and unlinked records have a median of zero | HELD_MEASURED | Agent read log (current engine); person-view marker (first generation) | Native record `dbc0d73` (private) | Correlational; frequency data are one generation deep; truncated by system age | 8.4, 9.1 |
| A51 | About seven in ten edits to pre-existing records follow an inspection of that record in the same run (69.7%, n=1,470, floor); about one in ten declared intents is repair work (9.3% floor, 19.4% broad, n=1,971); provenance-checking runs at roughly one history call per two opens | HELD_MEASURED | Agent read log, intent declarations, history counts (current engine only) | Native records `dbc0d73`, `546b0ee8` (private) | Run-scoped floor; keyword matching crude; current engine 17 days old; 14:27 UTC backup | 4.2, 8.4 |
| A52 | Content later revised was read about 148 times per version first; purpose-built change traversal used in 4% of runs; supersession link counts undercount repair ~5x and are not used as evidence | HELD_MEASURED | Same as A51 | Native records `dbc0d73`, `546b0ee8` (private) | 148 overstates error (most revisions additive); `whats_changed` narrow adoption is a real limit | 4.2, 8.4, 9.2 |
| A53 | MDX artifacts bind named ports to governed Collections, selections or folders; authored source has no network, database or tool authority and returns an inert safe tree; interactions are declared, port-bound and reauthorised in the write transaction | PUBLIC_CURRENT (MDX); HELD_CURRENT (HTML) | Artifact runtimes; artifact input bindings | `docs/artifact-runtimes.md`; `docs/tool-surface.generated.md` | HTML runtime contract and hosted authoring held; no usability evidence | 6 |
| C1 | Distributed Context as defined in §2.1, with requirements R1 to R7 | CONCEPTUAL | argument | §2 | Definition, not a measurement | 2 |
| C2 | Heterogeneous work must remain typed and inhabit one traversable world | CONCEPTUAL | argument; Native as case | §3 | Costs and exclusions in §3.4 | 3 |
| C3 | History, authority, attribution and correction are context, not metadata beside it | CONCEPTUAL | argument | §4.5 | Depends on read surfaces carrying them by default | 4 |
| C4 | Nine agent-facing principles derive from seven constraints | CONCEPTUAL | derivation | §5 | One derivation; offered for disagreement | 5 |
| C5 | Governed state, maintained views, durable artifacts and ephemeral representations must be distinguished | CONCEPTUAL | argument | §6 | Norms enforce part of it | 6 |
| C6 | Federation follows from the definition once universal custody is rejected | CONCEPTUAL | derivation | §7.3 | Least demonstrated in implementation | 7, 9.6 |
| C7 | The architecture relocates failures to visible places rather than abolishing them | CONCEPTUAL | argument | §4.2, §9 | The residual burden is real | 9 |
| C8 | Durable, governed context is a candidate complementary infrastructure for agentic AI | CONCEPTUAL | argument; general-purpose-technology literature | §1; [44, 45] | Motivational claim only; no productivity effect is estimated and the cited literature does not validate this architecture | 1 |

---

## References

1. L. Lamport. "Time, Clocks, and the Ordering of Events in a Distributed System." *Communications of the ACM* 21(7):558–565, 1978. https://doi.org/10.1145/359545.359563
2. D. D. Clark. "The Design Philosophy of the DARPA Internet Protocols." *Proceedings of ACM SIGCOMM '88*, pp. 106–114, 1988. https://doi.org/10.1145/52324.52336
3. J. H. Saltzer and M. D. Schroeder. "The Protection of Information in Computer Systems." *Proceedings of the IEEE* 63(9):1278–1308, 1975. https://doi.org/10.1109/PROC.1975.9939
4. B. W. Lampson. "Protection." *ACM SIGOPS Operating Systems Review* 8(1):18–24, 1974. https://doi.org/10.1145/775265.775268
5. J. H. Saltzer, D. P. Reed and D. D. Clark. "End-to-End Arguments in System Design." *ACM Transactions on Computer Systems* 2(4):277–288, 1984. https://doi.org/10.1145/357401.357402
6. G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall and W. Vogels. "Dynamo: Amazon's Highly Available Key-value Store." *Proceedings of SOSP '07*, pp. 205–220, 2007. https://doi.org/10.1145/1294261.1294281
7. R. T. Fielding. *Architectural Styles and the Design of Network-based Software Architectures.* PhD dissertation, University of California, Irvine, 2000. https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
8. M. Kleppmann, A. Wiggins, P. van Hardenberg and M. McGranaghan. "Local-first software: You own your data, in spite of the cloud." *Proceedings of Onward! 2019*, pp. 154–178, 2019. https://doi.org/10.1145/3359591.3359737
9. P. Helland. "Immutability Changes Everything." *Proceedings of CIDR 2015*, 2015 (https://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf); reprinted in *Communications of the ACM* 59(1):64–70, January 2016. https://doi.org/10.1145/2844112
10. P. Helland. "Data on the Outside versus Data on the Inside." *Proceedings of CIDR 2005*, 2005 (https://www.cidrdb.org/cidr2005/papers/P12.pdf); reprinted as "Data on the Outside vs. Data on the Inside", *ACM Queue* 18(3):43–60, 2020. https://doi.org/10.1145/3411757.3415014
11. M. Shapiro, N. Preguiça, C. Baquero and M. Zawirski. "Conflict-free Replicated Data Types." *Stabilization, Safety, and Security of Distributed Systems (SSS 2011)*, LNCS 6976, pp. 386–400, 2011. https://doi.org/10.1007/978-3-642-24550-3_29
12. M. Fowler. "Event Sourcing." martinfowler.com, 2005. https://martinfowler.com/eaaDev/EventSourcing.html
13. M. Kleppmann. *Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems.* O'Reilly Media, 2017. ISBN 978-1-4493-7332-0.
14. P. Buneman, S. Khanna and W.-C. Tan. "Why and Where: A Characterization of Data Provenance." *Database Theory — ICDT 2001*, LNCS 1973, pp. 316–330, 2001. https://doi.org/10.1007/3-540-44503-X_20
15. L. Moreau and P. Missier (eds.). "PROV-DM: The PROV Data Model." W3C Recommendation, 30 April 2013. https://www.w3.org/TR/2013/REC-prov-dm-20130430/
16. L. Moreau, B. Clifford, J. Freire, J. Futrelle, Y. Gil, P. Groth et al. "The Open Provenance Model core specification (v1.1)." *Future Generation Computer Systems* 27(6):743–756, 2011. https://doi.org/10.1016/j.future.2010.07.005
17. C. S. Jensen and R. T. Snodgrass. "Temporal Data Management." *IEEE Transactions on Knowledge and Data Engineering* 11(1):36–44, 1999. https://doi.org/10.1109/69.755613
18. V. Bush. "As We May Think." *The Atlantic Monthly* 176(1):101–108, July 1945. https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/
19. D. C. Engelbart. *Augmenting Human Intellect: A Conceptual Framework.* SRI Summary Report AFOSR-3223, Stanford Research Institute, October 1962. https://www.dougengelbart.org/content/view/138
20. T. H. Nelson. "Complex information processing: a file structure for the complex, the changing and the indeterminate." *Proceedings of the 1965 ACM National Conference*, pp. 84–100, 1965. https://doi.org/10.1145/800197.806036
21. F. G. Halasz. "Reflections on NoteCards: seven issues for the next generation of hypermedia systems." *Communications of the ACM* 31(7):836–852, 1988. https://doi.org/10.1145/48511.48514
22. T. Winograd and F. Flores. *Understanding Computers and Cognition: A New Foundation for Design.* Ablex, Norwood NJ, 1986 (paperback Addison-Wesley, 1987). ISBN 0-89391-050-3.
23. F. Flores, M. Graves, B. Hartfield and T. Winograd. "Computer Systems and the Design of Organizational Interaction." *ACM Transactions on Office Information Systems* 6(2):153–172, 1988. https://doi.org/10.1145/45941.45943
24. R. S. Sandhu, E. J. Coyne, H. L. Feinstein and C. E. Youman. "Role-Based Access Control Models." *IEEE Computer* 29(2):38–47, 1996. https://doi.org/10.1109/2.485845
25. M. S. Miller, K.-P. Yee and J. S. Shapiro. "Capability Myths Demolished." Technical Report SRL2003-02, Systems Research Laboratory, Johns Hopkins University, 2003. https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
26. C. Lemmer-Webber and J. Tallon (eds.). "ActivityPub." W3C Recommendation, 23 January 2018. https://www.w3.org/TR/2018/REC-activitypub-20180123/
27. The Matrix.org Foundation. "Matrix Specification v1.19: Server-Server API." July 2026. https://spec.matrix.org/v1.19/server-server-api/
28. S. Capadisli, T. Berners-Lee and K. Kjernsmo (eds.). "Solid Protocol." Version 0.11.0, Draft Community Group Report, W3C Solid Community Group, 12 May 2024. https://solidproject.org/TR/2024/protocol-20240512
29. P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W. Yih, T. Rocktäschel, S. Riedel and D. Kiela. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." *Advances in Neural Information Processing Systems 33 (NeurIPS 2020)*, 2020. https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html (arXiv:2005.11401)
30. N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni and P. Liang. "Lost in the Middle: How Language Models Use Long Contexts." *Transactions of the Association for Computational Linguistics* 12:157–173, 2024. https://doi.org/10.1162/tacl_a_00638
31. C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica and J. E. Gonzalez. "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560, 2023. https://arxiv.org/abs/2310.08560
32. S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan and Y. Cao. "ReAct: Synergizing Reasoning and Acting in Language Models." *ICLR 2023*. https://openreview.net/forum?id=WE_vluYUL-X (arXiv:2210.03629)
33. T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, E. Hambro et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." *Advances in Neural Information Processing Systems 36 (NeurIPS 2023)*, 2023. https://proceedings.neurips.cc/paper_files/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html (arXiv:2302.04761)
34. J. S. Park, J. O'Brien, C. J. Cai, M. R. Morris, P. Liang and M. S. Bernstein. "Generative Agents: Interactive Simulacra of Human Behavior." *Proceedings of UIST '23*, 2023. https://doi.org/10.1145/3586183.3606763
35. Model Context Protocol contributors. "Model Context Protocol Specification," revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28
36. E. Schluntz and B. Zhang. "Building effective agents." Anthropic engineering blog, 19 December 2024. https://www.anthropic.com/engineering/building-effective-agents
37. P. Rajasekaran, E. Dixon, C. Ryan and J. Hadfield. "Effective context engineering for AI agents." Anthropic engineering blog, 29 September 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
38. S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang et al. "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework." *ICLR 2024*. https://openreview.net/forum?id=VtmBAGCN7o (arXiv:2308.00352)
39. Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu et al. "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation." *First Conference on Language Modeling (COLM 2024)*, 2024. https://openreview.net/forum?id=uAjxFFing2 (arXiv:2308.08155)
40. R. Surapaneni, M. Jha, M. Vakoc and T. Segal. "Announcing the Agent2Agent Protocol (A2A)." Google Developers Blog, 9 April 2025, https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/; specification: "Agent2Agent (A2A) Protocol Specification", v1.0, Linux Foundation / Agentic AI Foundation, https://a2a-protocol.org/latest/specification/
41. Z. Zhang, Q. Dai, X. Bo, C. Ma, R. Li, X. Chen et al. "A Survey on the Memory Mechanism of Large Language Model-based Agents." *ACM Transactions on Information Systems* 43(6):1–47, 2025. https://doi.org/10.1145/3748302 (arXiv:2404.13501, 2024)
42. P. Chhikara, D. Khant, S. Aryan, T. Singh and D. Yadav. "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory." arXiv:2504.19413, 2025. https://arxiv.org/abs/2504.19413
43. L. Suchman. "Do categories have politics? The language/action perspective reconsidered." *Computer Supported Cooperative Work* 2(3):177–190, 1993 (issue often cited as 1994). https://doi.org/10.1007/BF00749015
44. T. F. Bresnahan and M. Trajtenberg. "General Purpose Technologies 'Engines of Growth'?" *Journal of Econometrics* 65(1):83–108, 1995. https://doi.org/10.1016/0304-4076(94)01598-T
45. E. Brynjolfsson, D. Rock and C. Syverson. "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies." *American Economic Journal: Macroeconomics* 13(1):333–372, 2021. https://doi.org/10.1257/mac.20180386
46. G. Litt, J. Horowitz, P. van Hardenberg and T. Matthews. "Malleable software: Restoring user agency in a world of locked-down apps." Ink & Switch essay, June 2025. https://www.inkandswitch.com/essay/malleable-software/

*Bibliographic metadata status: entries 1–43 were checked against a primary or index record (publisher DOI landing page or Crossref record, arXiv, W3C, or the publishing site) on 3 September 2026; entries 44–45 were checked against the NBER and American Economic Association records on 4 September 2026; entry 46 was checked against a captured copy of the published essay taken on 31 August 2026 rather than against the live page. One URL (entry 25) could not be resolved from the authoring environment and should be checked by hand before publication; see the verification report.*