# why-not-trust-us.md > Source: > Published: 2026-09-13 06:49:38+00:00 *A reply to a fair question: if AxonOS bounds what an application can extract, what stops AxonOS — or whoever operates it — from extracting instead?* The honest answer is that nothing in the architecture stops us. An operator who holds the keys holds the data. That is true of AxonOS, of every neural device shipping today, and of every system that has ever had a privileged component. So the question is not "are they trustworthy." It is **"what can you check without trusting them."** Below is the complete list of what I believe is checkable in this project, and — more usefully — the list of what is not. RFC-0009 does not model a hostile third party stealing data. It models a **legitimate, authorised party** — an application with a valid grant, or the platform itself — extracting more than the subject intended, one lawful query at a time. That is the harder threat, because nothing is broken. Every access is permitted. The extraction is the sum of permitted things. This is why the mechanism is an *accounting* mechanism rather than an access control one. Access control answers "may you." Accounting answers "how much, in total, have you." The raw signal lives inside a container with **no public read path**. The normative text: **N1.** Raw samples MUST NOT be reachable through any public interface of the sealed container. An application does not receive samples. It submits a reducer — a question — and receives an answer. The answer has a cost in bits, and: **C1.** `cost(r)` MUST be computed by the enforcing component from the actual content of *r*, per (1). **C2.** An implementation MUST NOT accept a cost supplied by the requester, and MUST NOT allow a reducer to declare its own price. That second clause is the part worth dwelling on. If an application could declare its own cost, the budget would be theatre. The price is computed from what the answer actually contains, by the component enforcing the budget, not by the party being charged. When the budget is exhausted, further queries are refused, and: The conjuncts MUST be evaluated in the order given, and the refusal MUST name the first conjunct that failed. A refusal that does not say why is a refusal you cannot audit. **What this does buy, stated plainly.** It removes every party from the picture except one. A third-party application cannot exfiltrate the raw signal, not because a policy forbids it but because no type exists through which the samples could leave. What remains is the platform vendor. That is the same shape of guarantee a phone sandbox gives: it does nothing against the vendor, and it does a great deal against everybody else. Whether that is worth anything to you depends entirely on whether your threat is the vendor — and in the scenario you described, it is. The specification carries its own not-claimed section, as **L1–L4** in RFC-0009. I did not write it in response to criticism; it has been there since publication, and it is the part I would read first if I were you. **It does not choose which bits leave.** A bound of β bits is a bound on quantity, not on sensitivity. The β bits an adversary extracts may be the most informative β bits available. A bound is not anonymity. **It bounds a transcript, not an inference.** What an adversary concludes from *facts about* the transcript — timing, query patterns, the fact that a question was asked at all — is outside the model. **It assumes the enforcing component is honest.** An adversary with kernel privilege, physical memory access, or control of the enforcing component itself is out of scope entirely. If the platform is the attacker, this mechanism does not save you. **Including if the platform is us.** **N6 is normative and unimplemented.** The RFC requires accounting *across grants* for one subject, so that an application cannot reset its budget by requesting a fresh grant tomorrow. The clause is blunt about what its absence costs: **N6.** The issuer MUST maintain accounting across grants for a subject, per Theorem 2. An enforcing component that meets N1–N5 while its issuer grants without limit satisfies the letter of this RFC and defeats its purpose. There is no issuer layer in which to implement it, and none exists yet. Until there is, the bound holds per grant, not per subject — materially weaker than the theorem permits. Five things, none of which require believing me. **The specification is public and dated.** RFC-0009 is in a repository with full history. You can see what it claimed on any past day, and whether a claim appeared before or after somebody asked an uncomfortable question. A claim that appears the week after a critique is a different kind of claim. **The not-claimed section predates the criticism.** Check the commit history on that section. If a project only admits limits when cornered, the history shows it. **Every number carries a level, and the levels mean something specific.** From the standard, Section 22: **Level L1**, *formally proven*: the claim is a bound established by a machine-checked formal proof that covers the entire admissible input space. [...] A claimed worst-case bound that has not been proven over the entire input space is not L1. **Level L2**, *measured on reference hardware*: the claim is a value measured on the reference hardware, under stated conditions, with the measurement trace published. [...] A measurement on hardware other than the reference hardware is not L2. **Level L3**, *independently validated*: the claim is an L2 measurement that has additionally been reproduced by an independent third party, on a separate instance of the reference hardware, and witnessed by a signed report. No claim in this project holds L3. Several L2 figures are measured but their traces are marked publication-pending rather than published, and the catalogue says which. The validation repository holds the structure and the deterministic post-processor that turns a raw trace into a headline figure; what it does not yet hold is the traces, and its README says which are missing and why. **The corrections are in the history, with dates.** Four in the last fortnight, none of them flattering: - A clinical memorandum was listed as signed in the roadmap's closed deliverables. None had been signed. Corrected on every surface, 12 August. - Phase 1 did not close on its published calendar. The slip was published with its reason rather than the date quietly reprinted, 12 August. - A cycle bound was tagged **L1** when the harness backing it proves termination and contains no cycle assertion. Downgraded to analytical. The correction reached the owning repository on 16 August and the claims catalogue on 23 August, and**that seven-day propagation gap is itself recorded there** as an open process defect. - Section 19 of the standard specifies a 28-byte wire record. Every implementation uses a 32-byte record sharing no field at any offset. An erratum now stands at the head of that section warning that it must not be implemented from, 26 August, and the correction is filed as RFC-0011 through the amendment process rather than edited in, because the standard's own Sections 26–28 forbid editing it in. That record is the most useful evidence about this project available, and it is not flattering. It is also the reason the third item above is worth reading: a project that finds its own propagation gaps and writes them down is making a different claim than one that has never reported an error. **The conformance vectors are byte-exact.** An independent implementation can be checked against them without my involvement. That is the only form of verification that does not route through trusting me. Six implementations clear that bar today, all of them mine; no outside implementation has, and the challenge is deliberately left open. Not a specification. A specification enforces nothing, and I would distrust anyone who told you otherwise. What solves it is an **enforcing component the operator does not control** — which means either hardware the vendor cannot update unilaterally, or an issuer run by a party with no stake in the extraction. Both are unsolved. Neither is unsolved only for me: the whole field has this problem, and most of it has not yet stated the problem out loud. What a specification *can* do is make the quantity exist. Today a regulator cannot ask a neural device how much a given application extracted, because the quantity is undefined — there is no unit, no accounting, nothing to point at. With a bound, the question has an answer, and **a device that will not answer it is telling you something.** That is a smaller claim than "your data is safe with us." It is also the only one I can support. Everything above is checkable. None of it requires an account, a signup, or asking me. - **RFC-0009** — the sealed container, the accounting, and the L1–L4 not-claimed section:[https://github.com/AxonOS-org/axonos-rfcs/blob/main/rfcs/0009-bounded-disclosure-sealed-neural-data.md](https://github.com/AxonOS-org/axonos-rfcs/blob/main/rfcs/0009-bounded-disclosure-sealed-neural-data.md) - **The evidence taxonomy** — Section 22 of the standard, and the claims catalogue with its corrections:[https://github.com/AxonOS-org/axonos-standard/blob/main/CLAIMS.md](https://github.com/AxonOS-org/axonos-standard/blob/main/CLAIMS.md) - **Conformance vectors** — byte-exact, independently runnable:[https://github.com/AxonOS-org/axonos-conformance](https://github.com/AxonOS-org/axonos-conformance) - **The organisation** —[https://github.com/AxonOS-org](https://github.com/AxonOS-org) If you find a claim in any of them that the code does not support, an issue is more use to me than a polite silence. Several have been found that way already, and every one is in the history. *Revised 13 September 2026. The first version of this note said L1 meant "analytically derived." It does not: Section 22 defines L1 as a machine-checked formal proof, and analytical derivation is a separate and weaker tag. That distinction is exactly the one the 23 August correction above turns on, so getting it wrong here was worse than getting it wrong anywhere else. Two further fixes: a reference to a document that does not exist under that name has been removed, and the validation repository was described as empty when what it lacks is the traces rather than the structure.* Denis Yermakou · AxonOS · [connect@axonos.org](mailto:connect@axonos.org) · Written in reply to Peter Meijer, who asked the question that should be asked of every project in this field.