Independent review of the public service, round one
An outside architect wrote a test plan, froze it, then sent three calls to the live public service and recorded every byte. He wrote the report. We publish it here in full and unchanged, as agreed with him, including its findings and its limitations.
Read the full report (PDF, 7 pages)
What he found, in his words
"The three completed R1 verification cases returned REVIEW / BLOCK / REVIEW, all with HTTP 200. An in-scope database read was held for review; a delete proposal under the same scope was blocked; and the same read without a capability envelope was held for review. No unjustified ALLOW was observed, and no execution credential was issued."
"Justified ALLOW was NOT ESTABLISHED in the frozen round because the declarations prerequisite was not configured at freeze time."
"This report makes no finding of an ALLOW-path engine failure and no finding of a security vulnerability. It does not establish production security, regulatory compliance, certification, or suitability for deployment."
The three calls
| Case | Proposed SQL | Scope | Observed |
|---|---|---|---|
| C1, read inside scope | SELECT COUNT(*) FROM events | envelope present, scope established | REVIEW |
| C2, delete inside the same scope | DELETE FROM events WHERE event_id = 1 | same session and envelope | BLOCK |
| C3, the same read, scope removed | SELECT COUNT(*) FROM events | fresh session, no envelope | REVIEW |
What changed since, from us
- The documentation mismatch he recorded was real and is fixed. The quickstart now says that a first call on a new account returns REVIEW, not ALLOW, says what would release it, and shows the two steps that turn the same read into an ALLOW: a contract stating what the tool never does (this replaced the declarations step he refers to), and a session envelope, signed with the account's own key, that names the table the job acts on.
- The token example he cited is corrected. The claims now match what the service accepts.
- The positive control he could not reach is reproducible with the steps that were missing from the docs. With a contract for the tool and a signed envelope naming the
eventstable, the same read returns ALLOW; if either is missing, it returns REVIEW. We state this as our claim, not his finding; his report does not test it.
Check it yourself
The three requests are in the report, byte for byte. With a free key you can send them to the same public service and compare. The developer docs show the contract and signed-scope steps that turn the held read into an ALLOW, and what still holds or blocks after it.
Questions about the report go to its author. Questions about the service go to [email protected].