Two mechanisms sit between a model's suggestion and your plan. The first is a review that a proposed change has to pass before it is written at all. The second is a bench of narrowly-scoped specialist reviewers the hard calls are routed to instead of one generalist model. Neither of them is a safety system, and neither of them decides anything for you — this page is about how the product reasons, and what stops it reasoning badly in private.
What starts it
AI advisor
Reads your computed numbers through a fixed set of read-only tools, drafts a change, and sends it as one typed request.
The only thing that crosses. There is no other channel.
Independent AI reviewer
A different model instance — the advisor has no way to approve its own work. It is walled off — it can't call out to check anything else, and it reads the request as data, never as instructions.
The verdict
A blocked change goes back to the AI advisor to be revised, and starts over as a new request. The same request can never be sent twice.
Only an approved change is written
One approval covers exactly one change, and can't be reused.
Every mutating tool call the AI advisor makes — a schedule change, a coach-state write, a memory write — is intercepted before it is committed and routed to a second, independent reviewer instance with no approve tool of its own. The proposal travels as one typed request, not a conversation, and the reviewer reads it as data, never as instructions — the advisor cannot approve its own change.
The reviewer's job is deliberately narrow: judge the proposed action and the advisor's own description of it — the change, the reasoning behind it, and whatever numbers are cited in that description — not a vague impression of the whole conversation. It has no tool access of its own, so it never independently re-reads your CTL, ATL and TSB, ACWR, or the plan you are already on. Those numbers themselves come from published formulas, computed in code before any model sees them; the metrics reference shows every one of them with a worked example.
A reject or needs-changes verdict structurally blocks the write from ever landing. It is not a warning printed next to a change that got applied anyway: the advisor gets the feedback and has to revise, and it cannot resubmit the same change without going back through review. That return path is the part worth understanding — it is the difference between a review and a disclaimer.
A single generalist model asked to weigh sleep, an injury history, a periodization block, fueling, a travel calendar and the completeness of the underlying data at once will do all of it shallowly. So the hard calls aren't asked that way. Each specialist reviewer below is scoped to one domain, reasons only from the evidence packet it is handed, and is advisory-only — none of them writes anything. What they produce goes back into the review above, which is still what decides whether a change is applied.
Whether today's body matches the session that was planned — accumulated load, sleep, travel, and heart-rate behavior.
Whether a proposed session fits the block you're actually in — and whether the last one was executed the way it was designed.
Whether the session is fueled for, in heat, on travel days, and after a long or hilly effort — inside your stated dietary preferences.
Whether the calendar the plan is written into still reflects reality — travel windows, firm days, and provisional ones.
Whether the evidence itself is trustworthy before anything reasons from it — missing sessions, stale state, a sync that failed quietly.
Both mechanisms are quality and reliability checks on how MyThreshold reasons about your training data. MyThreshold is a data-analysis tool, not a coaching or medical service. It doesn't know your full medical history, and it can't replace judgment from a doctor, physiotherapist, or certified coach.
Want to see it running against your own numbers?
Request access