# The Append Lane Is Already Shipped And Account-Less: Four Capability Tiers, Hashes On The Server, And Five Things Earlier Briefs Got Wrong

**version** v0.33.60
**date** 19 August 2026
**from** Human (project lead)
**to** Engineering, Architecture, and everyone whose briefs this corrects

**type** Architecture brief (correction)

*Third of 19 August. Records a capability surface that several briefs in this corpus treated as proposed or absent, and corrects the specific claims that were wrong. Sourced from a code-verified audit supplied by the team maintaining that codebase. The distinction between shipped and proposed is preserved exactly as that audit states it, because two halves of the mechanism are in different states.*

---

## What This Is

The vault-to-vault message transport as it actually exists, and the corrections it forces on work already written here: **the append endpoints are shipped and code-verified on the server side, and the property that matters most is that the write path is account-less, since posting to a lane requires only an append token carried in the body and no access token at all, returning a blind acknowledgement that tells the sender nothing, which is precisely the narrow account-less ingress the enrolment architecture written two days ago described as the thing that breaks the bootstrap loop, so that architecture is substantially closer to buildable than either document suggested; the capability model is four tiers rather than a single credential, with an append token granting write only, an enumeration key granting list, fetch and mark, a write key granting configure and purge, and a private key that decrypts and is never sent to the server, and the server stores only hashes of the first three, which is the catastrophic failure principle implemented rather than asserted; sender authorisation already exists as registered anchors, meaning hashes of accepted senders configured with the write key, which answers a question left open on 16 August about who may claim to be a participant; the addressing scheme is that a lane is identified by the hash of the recipient's public key, so an agent's own key is its address and no directory lookup is required, though this derivation is the part the audit marks as client-side and proposed rather than shipped, and that boundary must not be blurred; five claims in earlier briefs are now wrong or understated and are corrected here, including that server-enforced granular permissions are absent from the forge, that per-agent keys exist nowhere, and that the append lane was a design proposal; and the audit's own accuracy warnings are carried forward unchanged, since one route is registered but marked proposed, another is documented as live but not registered at all, and the client sealing layer may not be wired end to end.** It is the third document of 19 August (cross-ref: the v0.33.60 enrolment architecture, the v0.33.60 bootstrap trap, the v0.33.59 relay pattern brief, the v0.33.59 shared drives research, and the v0.33.58 hub forge brief). New contributions: **the shipped surface recorded, the account-less write identified as the enrolment channel, the four-tier model related to the capability discipline, five corrections to earlier briefs, and the shipped-versus-proposed boundary preserved.**

## What Is Shipped, Server Side

Code-verified at the version the audit was performed against.

**The append endpoints, which are the message transport:**

| Operation | Gated by | Notes |
|---|---|---|
| `configure` | Write key | Registers accepted sender anchors and the enumeration key hash |
| **`write`** | **An append token in the body** | **No access token. Blind acknowledgement** |
| `list` | Enumeration key | Paginated, optional inline content |
| `fetch` | Enumeration key | Batch, up to 100 identifiers |
| `mark-processed` | Enumeration key | Idempotent |
| `purge` | Write key | Takes a folder of pending or processed |

**And the wider vault surface**, which the site has never documented: write, read, base64 read, delete, batch, list, health, destroy, public info, and presigned operations for large objects. Public read requires **no authentication at all**, which is what makes the static and browser stories work.

**Limits worth knowing before building against it:** five megabytes per payload, one thousand files per token, one hundred identifiers per batch, three megabytes of inline content, and a maximum list page of two hundred.

**And a caching contract that matters for anything client-side:** immutable objects are served with a one-year immutable directive, while references and indexes are served no-store. That is the mechanism behind the browser caching behaviour described in the corpus on 14 August, and it should be documented wherever a client is being built.

## The Account-Less Write Is The Finding

Of everything in the audit, this is the item that changes the most.

**Posting to an append lane requires an append token in the request body and no access token.** The response is a blind acknowledgement: the sender learns that the write succeeded and nothing else.

Two days ago the enrolment architecture described the requirement as a **narrow, account-less ingress channel**, and the companion brief argued that the absence of one is the reason every workaround hands over a larger identity. Both treated it as the thing that had to exist.

**It exists.** Which means the bootstrap architecture is not proposing a new transport; it is proposing a use for one that is already deployed. That is a materially different position and it should be reflected in both documents.

The blind acknowledgement is worth noticing separately. The corpus has described write-only channels six times as a pattern where a component can write and cannot read. **Here the property is enforced in the response itself** rather than only in the permission model, so a sender cannot use the write path to probe what is already in the lane. That is a stronger form of the pattern than the corpus has been describing.

## Four Tiers, And The Server Holds Hashes

The capability model, which is the corpus's own discipline implemented rather than argued for.

| Tier | Grants | Where it lives |
|---|---|---|
| **Append token** | Write to the lane, nothing else | With senders |
| **Enumeration key** | List, fetch, mark processed | With the recipient |
| **Write key** | Configure and purge the lane | With the vault owner |
| **Private key** | Decrypt the contents | **Client side only, never sent** |

**The server stores hashes of the first three.** So a total compromise of the server yields hashes rather than capabilities, which is the catastrophic failure principle from 16 August made concrete rather than asserted. The brief that formulated the principle can now cite an implementation.

It also answers something the plugins brief argued for on 6 August, that granularity should come from capability grants rather than from a single credential. **This is that model, in production**, with four grants that separate writing from reading from administering from decrypting.

## Sender Authorisation Was Already Designed

A question left open on 16 August has an answer in the code.

The relay pattern brief asked who may claim to be a given participant, noting that if anybody can register a name and publish a key for it, a message chain can be redirected. The answer is **registered anchors**: the lane's configuration holds hashes of accepted senders, and configuring it requires the write key.

So a lane is not open to everybody by default. **The recipient decides which senders are accepted, using a credential the senders do not have.** That closes the open question and it should be recorded as answered rather than carried forward.

## The Addressing Scheme, With Its Boundary

The elegant part, and the part where the audit is careful and this brief must be too.

**A lane is addressed by the hash of the recipient's public key.** So an agent's own key is its address, no directory is required to find where to send, and the same value that identifies a participant routes messages to it.

That is a very clean scheme and it has an immediate consequence for the enrolment work: an agent that has generated a keypair **already knows its own lane address**, without asking anybody, which is exactly the property the bootstrap trap requires.

**The boundary the audit draws must be preserved.** The server side of append lanes is code-verified and shipped. The **client-side sealing layer**, meaning generating the recipient key, sealing to it, and deriving the lane address from the public key, is listed as proposed vault-client work, while the command-line tool does ship recipient encryption.

So the honest statement is:

| Half | State |
|---|---|
| The lane, its gates, its storage and its limits | **Shipped and verified** |
| The client crypto that seals to a recipient and derives the address | **Proposed** |

**Both halves are needed for the worked example to run**, and documenting the second as though it were the first is the specific error the audit warns against. The corpus's own rule applies: if it is not code-verified, label it proposed, and a page that says not yet is better than one an agent trusts and acts on.

## Five Corrections To Earlier Briefs

Recorded plainly, because the corpus's value depends on wrong claims being retracted rather than left to age.

**One. The append lane was described as a proposal.** The enrolment architecture of 19 August and its companion both treat the narrow account-less channel as the thing that must be built. It is deployed. Both documents understate how close the architecture is.

**Two. Per-agent keys were said to exist nowhere.** The shared drives research of 16 August concluded that nothing surveyed supports per-agent public and private keys. That was a survey of external products and remains true of them. **It should have said so more precisely**, because the same document's requirements table has three empty rows that this surface fills, and the participant note attached to it does not fully cover the omission.

**Three. The forge brief listed server-enforced granular permissions as absent.** On 14 August the hub forge brief named four absences, one of which was that permissions cannot be enforced server-side because possession of a key is access. **That is true of content and false of operations.** The four-tier model is server-enforced granular permission: different capabilities gate different operations, checked by the server. The corrected claim is that **content-level permission is absent and operation-level permission exists.**

**Four. The relay pattern's open question on sender identity is answered.** Registered anchors, configured with the write key, decide which senders a lane accepts.

**Five. The caching behaviour was inferred rather than known.** The 14 August work described clients caching by filename convention. The actual mechanism is a server-set caching contract distinguishing immutable objects from references, which is more specific and should be cited rather than described.

## The Documentation Gap Is The Deeper Finding

The audit's own diagnosis is worth carrying into the corpus, because it is an instance of something already recorded here.

The capability exists and is documented. **The composition is not.** The transport is described in one place as a generic append mechanism that never uses the words message, send, recipient or inbox. The cryptography is described in another as file signing and encryption, with no link to the transport. **The page that joins them does not exist**, so nobody searching for messaging finds either half.

Worse, the security page is reported as stating that there is no asymmetric cryptography and no public-key infrastructure, which is wrong and is actively harmful, because **an agent reading it concludes the capability does not exist and stops looking.** The audit believes that is what happened.

This is the discoverability finding from 14 August in a sharper form. That report found the documentation excellent and unreachable because the site is not indexed. **This finds it reachable and uncomposed**, which is the same failure one layer up: every piece is present and nothing tells a reader they combine.

The audit's acceptance test is the right one and matches the discipline settled on 16 August: give a fresh agent only the machine-readable index and ask how to send an encrypted message from one vault to another. It should reach a working answer, including that the recipient's public key hash is the lane address, without reading source or asking a person. **That test fails today**, and passing it is what done means.

## Carry The Accuracy Warnings Forward

Three items the audit flags, recorded here so they are not lost between documents.

**The client sealing layer may not be wired end to end.** Covered above; it is the one that would produce a confidently wrong worked example.

**One route is registered in code but marked proposed in the reality document.** Resolve before documenting it either way.

**And one route family is documented as live but is not registered in the application at all.** Do not document it until that is resolved.

The general rule the audit states is the corpus's own: **if it is not code-verified, label it proposed.**

## What This Changes Going Forward

Three things worth acting on rather than only recording.

**The enrolment architecture should be rewritten against the shipped surface.** Its milestones assume building a lane; most of that is configuring one. The remaining work is the client sealing layer, the canonical enrolment object, the trusted processor and the registry, which is a materially smaller project than the original seven milestones imply.

**The corpus should cite this surface rather than describing patterns abstractly.** Six briefs describe write-only channels as a pattern. There is now a concrete implementation with four tiers and hash-only server storage to point at, which is stronger than a pattern named repeatedly.

**And the composition gap should be treated as a class of problem rather than an incident.** Documenting capabilities separately and never documenting that they combine is how a working feature becomes invisible. That is worth a check in whatever process reviews documentation: for any two capabilities that compose into something a user would ask for, does a page exist that names the combination?

## What This Does Not Try To Be

- **Not a claim that messaging works end to end today.** The transport is shipped; the sealing layer is proposed.
- **Not a retraction of the external research.** No surveyed third-party product supports per-agent keys, which stands.
- **Not the documentation.** The audit supplies drafts; this records what the corpus got wrong.
- **Not an endorsement of unverified routes.** Two are flagged and should not be documented until resolved.
- **Not a new pattern.** The capability discipline already argued for, found already implemented.

## Honest Tensions

| Tension | Note |
|---------|------|
| Shipped transport, proposed sealing | The half that exists is the harder half, and the half that does not is what a worked example needs |
| An account-less write path | It is what breaks the bootstrap loop and it is an unauthenticated door needing spam and rate controls |
| Registered sender anchors | They close the redirection question and they require the recipient to know a sender's key in advance |
| Correcting five briefs at once | It keeps the corpus honest and it means several documents now carry a claim their readers may have already acted on |
| Hash-only server storage | It implements the breach principle and it means a lost enumeration key cannot be recovered from the server |
| The composition gap | It is a documentation failure and it made a shipped capability invisible for long enough that an agent gave up |

## Open Questions

| Question | Notes |
|----------|-------|
| Is the client sealing layer wired end to end? | It decides whether the messaging example can be published as working |
| Does the enrolment architecture need rewriting against this? | Almost certainly, and it becomes a smaller project |
| How is the append lane protected from flooding? | Account-less by design, so rate limiting is the only lever |
| How does a sender learn a recipient's public key? | The address derivation needs a key, and finding one is the registry question |
| What resolves the two flagged routes? | One registered but proposed, one documented but unregistered |
| Should the corpus cite implementations rather than patterns? | Six briefs describe a pattern that now has a concrete instance |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 19 Aug | `v0.33.60__arch-brief__agent-enrolment-without-borrowed-authority-append-lane-is-the-narrow-door.md` | The architecture whose central mechanism turns out to be deployed |
| 19 Aug | `v0.33.60__strategy-brief__bootstrap-trap-every-workaround-hands-over-a-larger-identity.md` | The argument for a narrow account-less channel, which exists |
| 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | The sender identity question, now answered by registered anchors |
| 16 Aug | `v0.33.59__research-brief__shared-drives-for-agents-everything-runs-on-your-identity-segregation-not-scoping.md` | The empty rows, which this fills and which should have been stated more precisely |
| 14 Aug | `v0.33.58__arch-brief__sgit-hub-forge-whose-application-layer-is-the-browser-permissions-are-key-topology.md` | The absence claim about server-enforced permissions, corrected to content rather than operations |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The append endpoints are shipped and code-verified on the server side |
| 2 | The write path is account-less: an append token in the body, no access token, and a blind acknowledgement |
| 3 | That is the narrow ingress the enrolment architecture treated as something to be built |
| 4 | The blind response enforces the write-only property in the response, not only in permissions |
| 5 | Four capability tiers separate write from read from administer from decrypt |
| 6 | The server stores hashes of the first three, which implements the catastrophic failure principle |
| 7 | Registered sender anchors answer the identity question left open on 16 August |
| 8 | A lane is addressed by the hash of the recipient's public key, so a key is its own address |
| 9 | That derivation and the client sealing layer are proposed rather than shipped, and the boundary must hold |
| 10 | Five earlier claims are corrected, including that per-agent keys exist nowhere and that server-enforced granular permission is absent |
| 11 | The deeper failure is composition: both halves are documented and nothing says they combine |
| 12 | A security page stating that no public-key infrastructure exists causes agents to stop looking |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).