An editor for AI-generated endurance training plans. It doesn't rewrite your plan and it doesn't coach your body. It reads what an AI wrote for you, checks it against eight structural rules, and hands it back with findings and a question.
github.com/jmarielee/taper-editor arrow_outwardIn July 2025 I asked ChatGPT for a taper plan for a local sprint triathlon. I followed it. I felt fine at the start line, and found out how fried I was in the middle of the race, when there was nothing left to find. I finished in 1:44.
The year before, my bike shoe broke at the start of the bike leg. Any cyclist can tell you what that costs: the pull-up half of every pedal stroke, gone for the entire ride. That race, on broken equipment with half a pedal stroke, was four minutes faster than the race where I followed the plan.
The plan had also labeled race day "Fri, July 12." July 12, 2025 was a Saturday. I didn't catch it, and the plan didn't catch itself. That mistake didn't cost me the race, but it told me what I was dealing with: a plan that can't count days shouldn't be trusted to count load unchecked.
The worst part is that I knew better. I've raced enough to know what a taper looks like, and that final week didn't look like one. But the plan sounded so informed that I followed it over myself. That's the failure this editor exists for. A newer athlete doesn't know which claims to question. An experienced one can still be talked out of what she knows. Either way the plan's confidence goes unchecked, so this tool checks it.
Rewrite, redraft, or produce a corrected plan. Prescribe volume, intensity, weight, or pace. Comment on your body. Assess whether an injury accommodation is medically adequate — that's a clinician's call, and it says so when it declines. Perform arithmetic by guesswork when the checker can run instead. Praise.
The race-week rule and all calendar and total arithmetic run in checker.py, a deterministic engine — never by model diligence. A second gate, check_contract.py, verifies the shape of the report itself.
Editorial review layered on top of the machine state: which findings matter most, how to say what a violation costs, and what question to hand back.
Anything about the athlete's body. It reports plan structure and never predicts injury. A BLOCK means the math didn't clear, not that the plan is unsafe.
Two questions first: is this AI-generated, and is it an endurance plan? If either is false the editor declines and stops. Most tools evaluate and then caveat. This one decides whether it's entitled to an opinion before it forms one, because a partial answer on a training plan reads as a review.
| Rule | Severity | What it checks |
|---|---|---|
| 1 · Race-week load | Blocks | For a declared goal race, the final seven days must show declining load against the preceding trend, by machine count. |
| 2 · Missing ceiling | Flag | Every stated limit must define what happens when it's broken. A limit with no response is decoration. |
| 3 · Calendar & arithmetic | Flag | Every weekday label must match a real calendar and every total must recompute, by script. |
| 4 · Phantom athlete | Flag | Every number about the athlete must trace to something the athlete actually stated. |
| 5 · No bad-day rule | Flag | The plan must define behavior for both the missed session and the added one. |
| 6 · Self-certification | Flag | A plan's claims about its own safety are claims, not facts, and are treated that way. |
| 7 · Undeclared race role | Flag | Every race must state what it's for: the goal, or training for a named larger goal. |
| 8 · The solo plan | Flag | The plan must account for the athlete's total load, including standing activities outside it, or ask. |
Only the check closest to the body blocks. Everything else respects the athlete's authority to accept a flag and go anyway.
Every finding returns the same four parts in the same order, ranked by consequence and capped at five per report.
The exact line, quoted.
The rule it breaks, in plain English.
Stated plainly, no hedging.
A question. Never a rewritten line.
checker.py proves the arithmetic. check_contract.py proves the shape every report promises — it blocks any report where a finding drops one of its four parts, where "Your call" hands back anything but a question, or where a quote can't be found as a contiguous run of words in that specimen's committed evidence. The no-rewrite rule is a constraint the repo enforces on itself, not a promise in prose.
Six confirm a rule fires when it should. One is a control case that must not fire — without it, a checker that fires on everything scores identically to a checker that works. The eighth pins a known limitation in place, which is its own story further down.
Receipt: runs/2026-07-21-selftest-run.txt. The suite grew 6/6 → 7/7 → 8/8 as cases were found; the earlier receipts are committed too.
Run against the repo it clears all five reports and verifies 25 quotes against source. The NYC report ships no source text by the anonymous witness's terms, so it is reported SKIPPED — not silently passed.
Specimen 2 is a plan I built to violate the one hard rule, committed in full as trap-plan.md so anyone can re-spring it: python3 checker.py trap-plan.ledger. The biggest training day of the entire plan sits inside race week.
Specimen 5 is a real strength program submitted as the deliberate out-of-scope test. The editor declined on both grounds of the scope precondition — wrong sport, and not AI-generated — after verifying against all eight rules individually. Almost nobody ships a demo of their own system declining to answer.
"This is a strength program — squats, presses, hip thrusts, rows, on a Monday/Wednesday/Friday split. I review AI-generated endurance training plans… There's no race here, no taper, no endurance load for me to check. I'd be inventing problems to have something to say, and I won't do that."
"One more thing, separate from scope: this plan wasn't generated by an AI. It reads like real programming from a coach… A human coach's program isn't what I'm calibrated against, on top of not being the right sport."
| # | What | Editor verdict | Machine receipt |
|---|---|---|---|
| 1 | The original 2025 plan that started this | HOLD | HOLD |
| 2 | A constructed trap, built to violate the hard rule | BLOCK | BLOCK |
| 3 | A real Detroit half marathon plan | PASS, 5 flags | FINDINGS |
| 4 | A real NYC Marathon plan — external witness | PASS, 3 flags | CLEAN |
| 5 | A real strength program — the scope decline | DECLINE | — model-only |
| 6 | A real triathlon plan — second external witness | BLOCK, disputed | BLOCK |
Two columns on purpose. The machine receipt is the exact word checker.py prints. The editor verdict is the model-reviewed layer on top of it. A machine FINDINGS can carry non-blocking flags the athlete may accept; only a machine BLOCK forces an editor BLOCK. The words differ by design, and the README says so, so nobody has to discover it.
Specimen 6 is a real AI-generated triathlon plan from the second external witness. It states almost every session in yards and miles — swim sets in yards, long rides and runs in miles — with only race week itself stated in minutes. Run as written, the checker returned BLOCK: race week's daily average of 13.6 minutes came back higher than the preceding eleven weeks' 9.1.
That is the correct output for the input it was given, and it is also wrong in the way that matters. Those eleven weeks are full of real 60-to-90-minute sessions the checker had no way to convert, so it counted them as zero. Race week only looked heavy because it was the one stretch stated in a unit the checker could read.
I proved it rather than asserting it. Same ledger, same plan, same rules, one change: every distance session converted using the athlete's own stated race-day paces. The preceding average moved from 9.1 to 24.5 minutes a day. The verdict flipped from BLOCK to FINDINGS. Both runs are committed.
"Now that it's been pointed out to me I can't unsee that the original plan was written with both distances and times. That IS a huge red flag, especially if your true intention is to taper before race day."
"Overall, I think your math rules worked exactly as intended. That plan SHOULD have failed; it looks good at a cursory glance but a deeper dive shows the inconsistencies could absolutely lead to overtraining."
My own LIMITATIONS.md presents that block as a false positive. She read the same evidence and disagreed with me — she says the block was correct, because a plan that mixes distances and times that inconsistently is itself the hazard, not just a unit my tool can't count.
Tool says data gap. User says real flag. That disagreement is kept unresolved, on the record.
I didn't patch it, and the reason is in the repo: a proper fix needs athlete-stated pace directives, because assuming a default pace would be exactly the phantom-athlete failure Rule 4 exists to catch. That's real feature work. Two days before a deadline, with five other specimens' credibility riding on the checker's current tested behavior, that trade wasn't worth making. A claim a stranger can rerun is worth more than a fix nobody had time to verify.
Instead of only writing the mistake down, I turned it into a check the tool runs on itself — the eighth one in the selftest. It re-tests this exact case on every run and fails loudly if the behavior ever drifts. The test asserts the limitation, not its correctness. The limitation is locked into the code rather than noted in a file, so no future change to it can happen quietly, including by me.
While assembling evidence I found that an early AI-written summary of the 2025 plan had quietly corrected the weekday error the verbatim source actually contained. The summary was tidier than what happened. I logged the discrepancy and kept the flawed source — the same rule the tool enforces, applied to my own documentation. It's committed as evidence-recovered-summaries.md. A record that silently improves on the past is not a record.
An independent trainer reviewed Specimen 4's plan and report without seeing rules.md first. Two of her points converged with what the tool already found. One did not: a plan's intensity vocabulary — "easy," "hard," "medium" — can go entirely unanchored to any measurable target, and no rule here evaluates that. Rule 3 catches rows whose amounts can't be computed. It cannot catch a plan that computes perfectly and still never defines what "easy" means for the athlete holding it. Logged as a limitation rather than patched, because a ninth rule the day before submission would be untested against six specimens whose credibility rides on the current, tested eight.
Four of six specimens ship their full source plan text, so every quote in those reports can be checked by hand against a committed file. Specimens 4 and 5 do not — both for witness privacy. Quotes in those two are verifiable by the athletes who own the plans, not by a stranger with only this repo.
One evidence file carries a deliberate redaction: a single word replaced with the visible marker [joint]. Race name and injury history are kept as originally written. A documented choice, not an omission.
A tested prototype with committed, reproducible receipts — not a clinically or scientifically validated training assessment tool. A BLOCK from this editor means the math didn't clear, not that the plan is unsafe, and the report says so every time rather than letting a technical verdict masquerade as a training judgment.
The Taper Editor is one of three builds that split the same way: the model labels, the math decides, the human makes the call.
Read the method arrow_forward