Frequently asked questions.

Evidence about somebody else’s model. A record that states how well it is calibrated, whether it discriminates, whether an apparent edge survives a regime control, and whether it improves on the price you already have — computed against prices as they stood at the decision moment, on predictions committed before their events.

Their pipelines run on internal trust — you take their word that the data flow is clean. Ours is built on external proof: every prediction is anchored to Bitcoin via OpenTimestamps before kickoff, in a public repo nobody at our company controls. That's a structural difference, not a feature gap.

SHA-256 content hash per prediction, daily OpenTimestamps anchor, upgraded weekly to a Bitcoin Merkle-path attestation, mirrored to a public GitHub repo. The verifier is pure-stdlib Python — clone the repo and it self-hashes for tamper-evidence.

No. Database triggers reject UPDATE and DELETE on the predictions ledger at the engine level; the row is committed before kickoff and never moves. Once it's in, it's in.

Because we never hold a readable prediction while it still has value. Commitments arrive as hashes before the event and are revealed only after settlement. It is not a policy we ask you to trust — it is a property of the protocol you can check.

Nothing, for now. We are looking for a small number of desks and funds to build the standard against real evaluations. Name a vendor you are already considering and the report arrives either way.

Plainly: Integrity STRONG, Operations STRONG, Security STRONG, Quant rigor STRONG, Data compliance BASIC, Commercial BASIC. We disclose the BASICs in writing rather than dress them up. Full readiness scorecard available on request.

Single-operator today, disclosed in OPERATIONS.md in the public audit_trail repo — key custody, hosting, backups, RTO/RPO, and known gaps stated. Not hidden, not minimized.

One — the 2026-05-24 anchor incident, disclosed under a 7-day protocol in audit_trail/incidents/. The immutability guard at the database level was what made it catchable rather than coverable. Disclosure is the policy, not the exception.

The public audit_trail repo plus METHODOLOGY.md is the technical packet. OPERATIONS.md answers most security-questionnaire questions. verify.py is the proof. We don't ship a private packet that contradicts the public one — they're the same documents.

Tamper-evidence is unconditional from the ledger's first row. End-to-end byte-reproduction of historical predictions is scoped — capture infrastructure is deployed on the live path; the historical harness is pending the first rows under it. Disclosed in METHODOLOGY.md, not hidden.

Not pursued at this stage. The position is that verifiable provenance plus a public methodology is a higher-bar artifact for institutional buyers than a generic certification; a certification roadmap can be discussed under MSA terms.

A hash before each event and the settled prediction after it. Never the model, never the features, never the parameters. The record proves what you called and when; it says nothing about how.

Calibration, discrimination, regime controls, additivity against the market price, and provenance — in the same format as every other record. No feature names, no hyperparameters, no architecture. Receipts, never the recipe.

Versioned /v1/* surface, Bearer API key plus HMAC-signed requests, RFC 7807 problem+json errors, X-RateLimit-* headers, OpenAPI spec as the contract. The public verifier is part of the contract, not an extra.

Yes. Every prediction carries an audit_trail row id and a content hash. Clone github.com/SplitWinner/audit_trail_alpha (the sealed alpha record), run verify.py against the day in question, check the Bitcoin attestation. Three steps, no special tooling, no contact with us required.

The record publishes anyway, in the same format. A registry where everyone passes is a directory, not a standard — and the passing records are only worth something because the failing ones exist beside them.

Records get faked. We built the opposite.

The industry runs on unfalsifiable claims — screenshots, deleted losses, backdated winners. Ours are machine-checkable: every prediction is cryptographically committed at creation, anchored where we can't reach it, and publicly verifiable. We trade hype for receipts.

Yes, in three steps. Clone github.com/SplitWinner/audit_trail_alpha — the sealed alpha record. Run verify.py against any sample. Check the Bitcoin attestations against the dates we claim. Pure-stdlib Python — no special tooling, no contact with us required.

Losses are published next to wins. The ledger is append-only at the database level so we can't quietly delete them. Backtests and live runs are kept separate — never blended — by hard-coded labels in the writer.

We register 16 bootstrap models as recovered=true in the public audit_models ledger — they predate the live anchor history and are flagged as such. The first anchored row marks the start of unimpeachable live capture. We don't pretend models that predate the ledger are part of the live record.

No. No honest prediction service can. Sports outcomes carry real variance — anyone who guarantees is not being honest with you.