Tough questions
Honest answers about voice accuracy, gate G3, the fake PayPal, production readiness and the security review.
Each answer says what is known, what is not, and where the evidence is. Where this page and docs/GATES.md disagree, the gate record wins.
Gate G5 is PARTIAL. The first run failed: on 24 synthetic eSpeak clips, Deepgram nova-2 had a wrong-accept rate of 0.125 and Groq whisper-large-v3-turbo 0.083, and on a second set of 24 human-like synthetic clips 0.083 and 0.167 (limit 0.05). Nine of the eleven wrong accepts were a label defect in our own evaluation. After fixing that, the parser for the real errors and the provider options (Deepgram nova-3, Groq with a bid prompt), the rate is 0.000 on all four runs, but the fixes were chosen on the same clips, the clips are synthetic and noise-free, and there is no real-room or noisy-room test or live speech run.
The decision recorded in docs/GATES.md is that spoken bids always go through the confirm prompt. The parser never decides a winner and never moves money; typed entry and QR bids are the other input paths, so the auction works if speech fails. At the text level (transcripts through the parser, no audio) wrong accepts are 0.000 on 169 cases, but that measures the parser only and says nothing about speech-to-text accuracy.
G3 is a real probe in progress. Day 0 was 7 Nov 2026 03:06 UTC; checkpoints are at 3.5, 4 and 5 days and the final reading is about 12 Nov 06:17 UTC. Earlier attempts on 4 to 7 Nov never ran, so no earlier day is claimed. Until the readings exist the gate reads NOT RUN / IN PROGRESS.
PayPal's documentation disagrees with itself about the honor period (3 days) and the validity window (29 days, with one reauthorization), so GAVEL does not assume either. The plan if the window is short is to capture within the verified window and reauthorize before the hammer. That is a plan, not a result. Meanwhile holds older than two hours at settlement are flagged stale, and a stale hold is still captured.
The 30-day run is a simulation on a fake clock against a model of PayPal. It shows our code is consistent with that model; it does not show PayPal follows it.
See honor period and gate G3.
Both exist and they are labelled. Real on the PayPal sandbox: G0 (Actions run log only), G1 (authorize 500, capture 350 with final capture, two PayPal-account buyers, one funded by a card), G2 (wallet and guest card authorize), G4 (six real webhooks verified) and one lot of three holds plus one in-process crash in the nightly specs R7, R8 and R10.
Fake: whole-auction settlement with many holds, crash and resume, and rejection of a tampered webhook. The fake PayPal is a test double in packages/payments/src/fake/; it says nothing about the real PayPal.
Never real: money. Every PayPal call is against the sandbox.
Inferred, not observed. After the final capture the authorization reads CAPTURED and an explicit void answers 422 PREVIOUSLY_CAPTURED. No run read a buyer balance or available funds. Capture of a guest card authorization was not run (G1 used PayPal-account orders).
No. The list is on Roadmap and limits. In short:
- The hosted app (https://gavel-web.creharsh.workers.dev, sandbox mode) has not been walked end to end; the verified runnable path is local, on the fake PayPal.
- The file stores need a persistent disk and a single instance; the hosted API uses temporary storage until a disk is added.
- Latency is only partly inside budget: end to end on the sandbox (n=20, 6 holds), hammer to SETTLED has p95 5591.30 ms, inside 6 s, and hammer to CAPTURED has p95 3010.04 ms, above the 2.5 s target. The 5 Nov per-call numbers (n=10) are not committed as raw logs; the settlement run has a redacted copy.
- Whole-auction settlement was not driven through a deployed server, and no real process kill ran on the sandbox.
- Rejected bids are kept in the room log only, not in the ledger.
- The web console has no audio sender to the
/audiosocket yet. - Accessibility: automated checks run; the manual pass has not been done.
docs/SECURITY-REVIEW.md lists SEC-01 to SEC-18. All 18 are OPEN: nobody has signed an item off, and the reviewer of an item is never its author. No FAIL is recorded. Automated checks exist for many items (access control, webhook authenticity and SSRF, sandbox-only guard, abusive input, headers and denial of service tests live in packages/e2e/test/security), and CI runs a secret scan and a dependency audit. The document's own rule is that submission is allowed when no P0 item is FAIL or OPEN, so the eight P0 items (SEC-01 to SEC-07 and SEC-18) still need a sign-off.
See security review and the threat model.
Accepted bids go into a hash-chained ledger. A public export can be checked with verifyPublicExport or the verify-ledger command in packages/engine; an edited entry fails at its index and a cut chain fails with truncated when the expected head is passed. The limit: rejected bids are not in the ledger, so it cannot prove them.
You should not rely on them yet. The per-call numbers come from one Actions run (42047543821, 10 cycles, 0 failures) whose raw log is not committed. The end-to-end settlement numbers come from one run (42346811713, 20 settlements of 6 holds, 0 failed) with a redacted copy committed under docs/evidence/measure/. Both are sandbox numbers from single runs. See latency.
Last updated on