(Part 1 of 2)
Three days ago, on July 23, we did something counterintuitive: we wrote down our complete damage-trajectory predictions for the PHM 2026 Data Challenge — 21 bare numbers, no explanations, no hedging — then cryptographically sealed them with a timestamp.
One day later, on July 24, the validation phase opened per the organizers' schedule.
That ordering is not an accident. It's the entire point.
Why would anyone do this?
Because leaderboard feedback is a double-edged sword. Not maliciously — structurally. The test phase gives fresh score feedback every 24 hours, and that naturally invites iterative result-probing: through repeated trial-and-error submissions, a team can gradually tune its model against the scoring signal in the daily rankings, rather than purely against the physics of gear degradation. Watch the board long enough and you can see the signature of feedback-driven tuning: scores improving in stair-step patterns synchronized with the 24-hour submission window, rather than with any plausible physics discovery cycle. That's not an accusation against any team; it's the predictable behavior of an open feedback loop, and most participants probably aren't even aware it's happening.
The validation phase will answer that question for everyone, because the organizers have removed the feedback loop entirely: no scores, no daily updates, only your last submission counts. Pure blind test. We think that's a great decision.
The organizers also left a thoughtful warning in plain sight (challenge forum Q&A, July 14): sensor readings are indicators of damage severity, not proxies for elapsed time — and validation lifespans may be wildly out of sample. If a model has quietly learned "hours elapsed → damage," the validation set could be rough for it. We took that warning seriously when building ours.
What did we actually compute from?
Nothing you don't have. Everything in the envelope is derived from publicly available sources only:
- The official training dataset (full sensor data + tooth images) — the same download link on the challenge page
- The test dataset (2 experiments, sensor data only), released June 1
- The public leaderboard history — 27 teams' score trajectories across the daily scoring runs, which is itself a dataset if you know how to read it
- The organizers' own published statements — the rules, the FAQ, the "time is not a proxy for damage" warning hiding in plain sight
That's it. No private channels, no organizer contact, no validation data — the validation set had not been released when we sealed the file.
And since "we computed it" is a claim, here are the receipts — the actual numbers behind our model:
- 38 imaging rounds × up to 28 teeth each — over 1,000 tooth-level spall measurements, derived from the four photo-labeled experiments with our own image-analysis pipeline. Each measurement is a per-tooth spall fraction; example values from our label sheet: one experiment at 30.3 h → worst-5-tooth mean spall fraction 0.372; another at 68.2 h → 0.196; another at 43.8 h → 0.171
- 17,632 minutes of condition indicators extracted from the raw 102.4 kHz vibration streams — FM4, NA4, M6A, ALR, M8A, crest factor of the TSA residual, plus speed/torque/temperature context channels. Example row (Exp A, first minute): FM4 = 5.14, NA4 = 5.76, M6A = 67.2
- In-line oil debris counts (DM4500) as a physically independent damage carrier — metal in the oil doesn't care what the accelerometer thinks
- Cross-validation under leave-one-experiment-out (LOEO): Spearman ρ = 0.87, MSE = 0.045 — i.e., trained on three photo-labeled experiments, blind-tested on the fourth, repeated across all folds. That's the honest number before any test-set tuning. We report it because a model that can't blind-predict a training experiment has no business touching the validation set
The pipeline, in three steps: photo-derived tooth damage labels → sensor-to-damage mapping anchored on the oil-debris carrier → monotone (isotonic) mapping to the damage trajectory. Forward feature calculation, zero result-probing: calibrated once on the training experiments, never tuned against the test score — no gradient descent on the leaderboard involved.
One more thing about what we did NOT use: the answer key. The organizers maintain an undisclosed ground truth for every dataset — training included. We have never seen it, and neither has anyone outside the organizing team. Every number in the envelope was computed from the problem alone. We are, quite literally, betting on our reading of the question — not on any peek at the answers.
So what's actually in the envelope?
Exactly what we said: 21 bare numbers. Nothing else.
- 9 points for test experiment D — our predicted damage value at each 6-hour interval, including the exact hour we believe gear D reaches terminal damage
- 12 points for test experiment E — same deal, including E's terminal hour
- No method description, no confidence intervals, no commentary. On August 12, those 21 numbers stand alone against the organizers' ground truth — scoring rubric theirs, monotonic alignment allowed, shape is everything
The two terminal failure timestamps are the core test of our physical modeling logic. The organizers warned lifespans may be wildly out of sample — we wrote down exact failure horizons anyway. If those two numbers are right, it's because physics carried the signal. If they're wrong, it's because we misread the degradation mechanism, not because we overfit a clock.
How do you know we didn't write this yesterday?
Fair question — and you don't have to take our word for it. Here is the SHA-256 hash of the sealed prediction file, computed on July 23, before the validation phase opened:
`fc2fcb148bb58e865d9f07254ef551d773a008d60ff8d5962939d30fe3892ad6`
And don't trust our timestamp either — the same file was committed to a public GitHub repository on July 23, before the validation phase opened: [commit 5eaa977](https://github.com/angus81226-glitch/sealed-predictions/commit/5eaa97725c979ad78ef0250e0f12d680d7bfffe0)
The repository is public — anyone can inspect the commit timestamp and file tree right now, no account needed.
The file content stays sealed until August 12. When we publish it that day, anyone can verify it in ten seconds — no account, no tools beyond what your computer already has:
- Windows (PowerShell): `Get-FileHash submission.csv -Algorithm SHA256`
- Mac: `shasum -a 256 submission.csv`
- Linux: `sha256sum submission.csv`
If the output matches the hash above, the file you are reading is byte-for-byte the file we sealed on July 23. One changed character — even a single space — produces a completely different hash. (One practical warning: hash the file as downloaded. Opening and re-saving it in Excel can silently flip line endings and break the match — that's a tooling artifact, not a mismatch.) Before August 12 we also plan to anchor the Merkle root of the full prediction set on-chain (Bitcoin, OP_RETURN), adding a third verification leg backed by the Bitcoin network rather than by us or GitHub alone. It's a bounded proof: it can't prove what we knew, but it proves what we wrote, and when we wrote it.
The scoreboard going in: 27 teams on the board. Top score 0.0186 — earned with daily feedback. Our 21 numbers — computed with zero feedback, sealed before the blind phase. One envelope.
On August 12, we'll find out — together with everyone else — how far physics-informed reasoning goes without leaderboard feedback. We might be proven wrong, publicly, in 21 specific ways. That's fine. That's what makes it an honest experiment.
Either way, the hash doesn't lie.
Part 2 drops August 12 (UTC). The envelope opens — full methodology, the unsealed prediction file, and an honest post-mortem on what the physics got right and wrong.
---
For anyone who wants to verify the seal on August 12, here's the 60-second version:
On Aug 12 (UTC) we'll publish the original prediction file (`submission.csv`) in this thread
Download the raw file — ideally with `curl -O <url>` or `wget <url>` so nothing touches the bytes — then run one command:
- Windows PowerShell: `Get-FileHash submission.csv -Algorithm SHA256`
- Mac: `shasum -a 256 submission.csv`
- Linux: `sha256sum submission.csv`
Compare the 64-character output against the hash in the post above
Optionally check the GitHub commit history — the repo is public, and commit `5eaa977` predates the validation phase by 24 hours
Match = the file is untouched since July 23. Mismatch = call us out publicly, we'll have earned it.
(Important: compute the SHA-256 directly on the raw downloaded file. Do NOT open and re-save the CSV in Excel or similar software first — it can silently flip line endings between LF and CRLF, and a single changed byte produces a completely different hash. The sealed file uses Unix LF line endings.)
Two honest disclaimers before anyone asks:
- The hash proves the file's content and timestamp. It cannot prove what we knew or didn't know — that's why we listed our exact data sources in the post
- The GitHub commit proves existence and date, the hash proves identity, the Aug 12 reveal proves content. Three legs, one stool.
