OrderedStrength

The record

Every prediction he makes, graded. Including the ones he got wrong.

We have not found another app in this market that publishes how often it was right. If one exists, tell us and we will link it. This page is where the combined record of the athletes who choose to publish goes. Jerry already shows you in the app how often he has been right about your own body, once five of his predictions have been graded against what you actually did. Each month is graded on the 2nd of the next and posted here, and every graded prediction is on the public record on GitHub.

What has been published so far 42 days published
42days published
2026-09-05first day published
2026-10-19latest day published
Accuracy against the target, once whole months are graded
Target 80% 100% 75% 50% 25% 0 First graded month onwards

Each point is one month of predictions locked in before the result: the share whose result landed inside the range Jerry gave in advance. The line is 80 percent, what his ranges for a single workout promise: about four in five land inside, so a miss is expected and counted; his ranges for the month ahead count here too and state no percentage. The 80 percent is what his ranges aim for, not what he has achieved. The points show what he has achieved. They are drawn from the published record when this page loads; if none appear, every graded month is on the public record on GitHub.

Reading the published record.

If this does not fill in a moment, open the public record on GitHub and read it for yourself.

Source: github.com/jeremiah2060/orderedstrength-receipts. Copied into this page on 2026-10-20, so this page works even when GitHub does not. To see the newest days, check GitHub. A posted day is never changed, and three things make sure of this. First, the program that posts each day will not touch a date that already has a file. Second, GitHub is set to refuse any push that rewrites or deletes the record's history, so a posted day cannot be quietly erased. Third, GitHub shows every change in public with its date, so a changed day would be easy to see.

A day ends at midnight UTC, which is 8 pm in New York (7 pm in winter) and 9 pm in Buenos Aires, and we post it a few hours later. So a prediction sealed today is not on this page today. It appears in tomorrow's entry, and until then we hold it. That wait is part of how the proof works. It is not a delay.

Two questions you can answer yourself

What a receipt proves, and what only the nightly postmark can.

Was it changed afterwards?

You can check it now

When Jerry makes a prediction, the app turns it into a long code. We call this code the seal. It comes from every detail of the prediction, so if one detail changes, the seal changes too. You can copy a receipt from the app. It holds the prediction and its seal, so anyone can work out the seal again and see if anything changed. Try it on the verifier, or try to change a prediction yourself on the home page.

Was it made before the result was known?

It proves the day, not the hour

Every night, we join all of that day's seals into one code and post it on GitHub, a public website. It works like a postmark on a letter. If your seal is in a posted day, your prediction existed before that day ended. GitHub keeps the date, not us. So nobody can make up a prediction after the result and add it to a day that is already posted. The postmark does not show the hour. The prediction and your set usually happen on the same day, so it proves the day, not the minutes before your set. A seal posted on a later day than your set (for example, because it was sent again) cannot show it was made before the result. We tell you this limit because hiding it would make us look better than we are.

For the technically minded: each seal is a SHA-256 fingerprint of the prediction together with a random number, the nonce, that stays on the athlete's phone until they copy a receipt or publish their graded predictions. Each day's seals are combined in a Merkle tree, and the code posted for the day is its root hash. The full construction is on the specification page.

Why it starts empty

Filling in past days would destroy the only thing this is for.

We could take every prediction already sealed on a phone, make a code for each past day, and post them today. The page would look established. It would also be worthless, because a record assembled after the results were known proves nothing about when anything was decided.

So the record starts on the day it starts, and the gap before it is stated rather than hidden.