We can't rewrite our predictions: how every signal is sealed

A track record is only worth something if nobody — us included — can rewrite it after the fact. The problem is as old as prediction itself: it's trivial to say "we saw it coming" once the price has moved. A backtest can be quietly re-calibrated, a losing decision erased from the ledger, a threshold tuned retroactively. As long as nothing freezes the prediction before its outcome is known, a "we were right" proves nothing.

So we sealed every signal, at the moment it was born.

Publishing the fingerprint before knowing the result

At the exact moment the engine issues a decision, we compute the cryptographic fingerprint (a SHA-256 hash) of its emission-time content: the asset, the direction, the horizon, the confidence, the resolution thresholds, right down to the precise version of the engine — the code commit and the state of the weights — that produced it. Sixteen fields frozen into a canonical string (sorted keys, zero whitespace, frozen format), then hashed.

That hash is published immediately, on /api/proof/seals. The detailed content, however, is only revealed later — at T+24h, or at the signal's resolution. This is the commit-reveal principle: we publicly commit to a fingerprint before the outcome is known, and disclose the prediction afterward. A hash doesn't let you guess the content, but once the content is revealed, it's mathematically impossible to have altered it: change a single character and you get a completely different hash from the one already published.

Verifiable by anyone, not just by us

The crucial point: this proof does not rest on our word. On /api/proof/seals/:id, we serve the revealed content, the exact canonical string that was hashed, and the server-recomputed hash. You can copy that string, run it through any SHA-256 tool (your own, locally, without trusting us), and compare it to the hash published on the day of emission. We've validated this third-party re-verification in production: it matches. The full protocol is described on /api/proof/verification.

Anchored outside our servers

A seal that only we host would still be fragile: in theory, nothing would stop us from regenerating the whole database. So we anchor each day beyond our reach. Every day, we aggregate all the sealed hashes from the day before into a single digest, and timestamp it on the Bitcoin blockchain via OpenTimestamps — no account, no cost — and archive a copy on archive.org. Once the attestation is confirmed, the digest is proven to predate a given Bitcoin block. In other words: the date we committed to is no longer something we can falsify, even by rewriting our own servers.

What the seal does not prove

Staying honest means naming the limits too — otherwise it's just one more marketing argument.

First, the seal covers emission, not outcome. It proves we did predict this, on that day. It does not prove the prediction was right: that's what the Truth Table measures, resolution by resolution.

Second, transparency about the starting point. The roughly one thousand signals that predate the mechanism were sealed retroactively, in a single pass. We don't hide it: for those signals, the sealing date is visibly later than the emission date, so the seal only guarantees their integrity from that day forward, not before. The "we couldn't have known" proof only truly begins for signals issued after live sealing was in place.

That's the whole spirit of GeoPulse: the scope is fixed in advance, the numbers decide, and the mechanism that makes our predictions un-falsifiable is itself public and verifiable — including where it shows its seams.