What we keep
This page is the complete retention inventory of AlphaAssay — everything the service keeps, per path, and everything it never keeps. It exists because the strongest attack on any validator is „they can see your strategy — they could trade on it." The honest answer is not a promise of good behaviour; it is an inventory you can size yourself, an architecture with no trading arm, and proofs you can run. If you ever find this page contradicted by the live service, that finding is exactly what we ask you to hunt for.
The retention ledger, path by path
| path | kept | never kept |
|---|---|---|
| free demo | nothing — the demo runs on a throwaway store that is deleted when the call ends | everything |
| validation calls (signal · backtest · gauntlet · forensics · falsify · batch) | a one-way fingerprint, the verdict with its cause of death, summary statistics (Sharpe, sample length, period), a 32-number compressed sketch of the return profile (family accounting — retention is caller-chosen, see below), and the family's structural label with its parameter coordinates | raw candles, trade lists, return/equity series, rules, code |
| assay_pbo | nothing from the matrix — the trial matrix is processed in memory and not persisted | the matrix itself |
| assay_reproduce | no ledger entry at all — an arithmetic audit is not a new trial | trades, candles, claimed metrics |
| pre-registration | the sealed spec in full (canonical JSON) plus the sealed success criteria, included in the operator-published Merkle/JSONL chain; independent anchoring status is disclosed separately | — |
| x402 gauntlet payments | per settled POST /x402/v1/gauntlet payment: nonce, wallet, transaction id, input digest and cached response. The named receipt binds payment/input/verdict digests and declares signed:true with Ed25519 fields or signed:false when no deployment key is configured (no expiry — one payment buys one result) | raw inputs — responses never contain them |
| certificates | purchased certificates in full (signed, incl. trial disclosure), account-bound for re-delivery | — |
| operations | usage charges (tool + cents), per-minute tool statistics, sanitised error messages, rate-limit buckets, request logs (id, timestamp, endpoint, status) | raw payloads by contract; a release canary injects a marker through the covered logging, error, metric and alert sinks. That test is scoped regression evidence, not a universal proof of every possible sink |
The same inventory, with legal bases, is in the privacy policy. The 32-number sketch is bucket means of the return series — far too coarse to reconstruct trades or rules; its only job is proving two variants were near-duplicates so the family budget can count them as one.
And because the sketch is the only evidence of that
nearness, you may refuse it: pass sketch_opt_out on assay_gauntlet,
assay_backtest or assay_batch (REST: /v1/gauntlet) and the sketch
is never persisted — the response echoes sketch_retained: false. The price of that choice is
statistical, not monetary: without the evidence of near-duplication, the trial counts in full toward the
family budget — no evidence, no discount. By construction the opt-out can only make verdicts stricter,
never friendlier.
Could you front-run what you see during a trial?
Head-on: during a trial, the engine necessarily holds the submitted evidence in memory — a remote examiner that sees nothing can test nothing. The service has no exchange connectivity, order path, execution logic, broker connection or custody, so it cannot execute a trade through the product. That is a bounded system capability claim, not a universal guarantee against operator misuse. Ordinary working payloads are transient, while the retention ledger above lists every documented state class; notably, a pre-registered spec is stored in full. Verdicts remain demote-only, so no product-generated list of „verified winners" exists to raid.
What about the one path where we DO store your strategy?
Pre-registration stores the sealed spec — that is the product. Its canonical hash and service
acceptance time enter an operator-published Merkle/JSONL chain. If you retain the registration response
or chain head, later divergence becomes detectable against that copy. While external_anchor
is empty, this is not independent proof of priority or an independently trusted timestamp; the storage
risk remains part of the disclosed trade-off.
How do you check any of this, instead of trusting it?
Run the golden specimens (free, with documented stable semantic fields). Pull the
current persisted calibration population/status snapshot. Calibration data is returned only inside a
valid signed snapshot; otherwise the endpoint says signed:false with a stale/reason state and
omits the calibration payload.
Use the offline verification guide to distinguish
raw_signature_valid from full platform_valid, which needs independently rooted
key and revocation history. Apply the
falsification protocol to us before anyone else. And hold
this page against the privacy policy and the live service — one truth, or it is a
finding.