Custody, retention and publication
A system that holds conduct records has to answer three questions before it is allowed anywhere near a firm: who may read this, how long is it kept, and who decided to publish it. None of them are technical questions, and all three used to have the same answer here — nobody had written one down.
Who may read an instrument's detail
The commitment published to the topic carries existence, order, time, mandate, held-or-not and the class of clause. It withholds notional, counterparty and calldata. That division is the whole custody argument, and it is only worth making if the detail is actually held back.
Three ways to read it, in the order a firm would state them:
- You signed it. Proved by signature, not asserted by a query string — the server issues a challenge, your wallet signs a sentence you can read, and the token that comes back reads and never writes.
- Its owner named you an officer. The chain is the authority on who may decide; this is only who may look.
- Its owner published it. Below.
Everything else is closed by default. Aggregate and clause-level facts stay open, which is the disclosure model working as designed: being able to draw that line is the point of drawing it.
Publication is the firm's decision
We publish a commitment for every intent to a public topic, and it is the strongest argument this project makes. It is also, for any firm that adopts it, their decision and not ours — so publication is a property of an instrument rather than of the deployment, and the default is closed.
This deployment publishes exactly one instrument: its own recorded incident. That is why a judge with no wallet reaches a complete case file, and why nothing else on the same database is readable to them. It is the same choice a firm makes about its own disclosure, made by us about ours.
Either default is defensible and the wrong one is silent. A firm that publishes nothing keeps its conduct private and loses the ability to prove, later, that a record existed before the argument about it started. A firm that publishes everything can prove that and has told the world how often its agents are stopped. What is not defensible is having the choice made for them by a deployment's convenience.
What is kept, and for how long
| What | Where | Kept |
|---|---|---|
| Intents, actions, holds | Chain and the topic | Permanently, and not by us. A public ledger is not a store anyone can prune |
| The spine — mandates, actions, cases, findings, decisions | PostgreSQL, rebuildable from chain | For the life of the deployment. Append-only at the grant level: no UPDATE, no DELETE |
| Disclosure requests | The spine | With the case they concern. The request for evidence is itself evidence |
| Sign-in challenges | The spine | Five minutes to use, one hour before deletion. One attempt each |
| Sessions | The spine, as a hash | Twelve hours. The token itself is never stored, so a reader of the table cannot use what they find |
| Relayer caller counts | Operations schema, as a salted HMAC | One hour. A rate limiter needs to count, not to know |
Erasure, and where it stops
Everything in the operational schemas can be deleted, and the short-lived things delete themselves. The evidence spine cannot: it is append-only by grant, deliberately, because a conduct record a firm can quietly amend is not a record. What the spine holds is reproducible from the chain in any case — deleting a row there removes an index, not a fact.
Which means the honest answer to "can you erase this?" is: the index yes, the fact no. A firm that needs erasure of the fact needs to not publish it, and that decision is made once, at signing, and is above.