The call ledger

Read this before you read the table

• The record is short, and its first two weeks are weaker than the rest. Rows before 23 July 2026 were migrated into the hash chain after the fact. Their timestamps are back-stamped to midnight UTC and their model version reads pre-ledger, because the code that produced them was not recorded at the time. Treat 23 July as the first day of genuine forward commitment.
• The model changed almost daily. Each row carries the git commit of the code that made that call, and through this window it changes most days. These rows are therefore not one strategy's live record — they are a sequence of calls by versions that no longer exist. We show the commit rather than hide it, and any future claim of a live track record will have to be dated from a version freeze, not from 10 July.
• 24 July – 1 August 2026 is visibly broken, and we know why. The call changes between Accumulate and Wait seven times in nine days while the underlying score sits flat and positive (0.211–0.25). A second, un-validated score path was feeding this log while the site itself ran on the validated one; its regime label flipped bull/bear daily and the phase followed. Fixed 2 August 2026. We are not deleting those rows.
• Every phase before 18 August 2026 was computed without stickiness. This log ran as a fresh process each day, so the "previous phase" that the validated model uses to hold a decision steady was always empty here. That is the one path the model's validation does not grade. Fixed 18 August 2026; rows from that date carry graded-replay as their source. The 17 August row is the last one produced the old way, and it disagrees with what the site showed that day.
• Two days are missing — 13 and 15 July 2026. The logging step failed and was configured not to fail the build. They appear below as "no call recorded" rather than being quietly closed up.
• What the hash chain proves, exactly. Each row is chained to the one before it, so no past row can be altered without breaking every link after it. That is a defence against a careless edit and against a third party. It is not proof that we could not rewrite the whole file — the chain is rebuilt from whatever bytes are on disk when it is checked, so a full rewrite would not trip it.
• The outside witness. This ledger's SHA-256 digest is anchored to Bitcoin via OpenTimestamps — free, anonymous, no account on either side. The proof is served raw at /api/calls/ots; download it and check it with any standard OTS client (ots verify state_history.json.ots) instead of taking our word for what it says. A freshly stamped proof reads pending until a Bitcoin block actually confirms it — that can take a few hours, not something either side can force — and once it does, it stands as proof this exact file, byte for byte, existed no later than that block. It re-anchors as the ledger grows.