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.
The line is drawn in the database, not in the code that reads it. Every table carrying conduct, the instruments, the actions, the cases, the rationale trail, the decisions, the disclosure requests, filters on the address a request has proved, so a query written without that condition returns nothing rather than everything. The service still refuses first, because sign in to read this is a better answer than a blank screen; it is no longer the only thing between a stranger and a case file. What this does not claim: the address is named to the database by the service that proved it, so this is protection from a filter somebody forgets to write, not from a service that has been taken over.
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.
Know Your Agent, without issuing anything
GET /api/agent/<address> answers who is acting, on whose authority, under
which mandate, and what that agent has already done.
It needs no session, because every field in it is a fact the chain already publishes: the signed instruments that name the agent, the bounds their owners put their names to, the delegation depth, the expiry and revocation, and how many actions were settled, held or resolved by a named human.
Where the chain answers in time it also carries what the agent holds and what it is approved to move through the guard: read from the token, not from our database. Zero and zero is this product’s central claim about an agent key, and a claim of that weight should not come from a database that could be out of date.
Nothing here is issued. There is no badge, no registry of AMW’s own, and no identity this system confers. An agent’s identity is the set of signed instruments that name it and the record of what it did under them, all of which a reader recomputes from the registry, the guard’s events and a public topic without asking us. A passport that had to be trusted would be worth less than the chain it was derived from.
What is absent is as much of the point. There is no score, no rating and no risk classification: those would be AMW’s opinion of an agent, and this product does not hold opinions about agents. There is no notional and no counterparty either — counts and bounds travel, detail stays in firm custody and is read through a disclosure that writes a row first.