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 and how the last session actually went, all 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. They are consulted only when a fixed rule in code fires, such as a hard session, a load spike, a low readiness verdict or repeated heavy legs; on a routine day none of them runs. Their verdicts go to the AI advisor as evidence, and any change it then proposes still has to pass the review above.
Whether today's body matches the session that was planned: accumulated load, readiness, sleep, and how your legs have felt.
Whether a proposed session fits the block you're actually in, and whether the last one was executed the way it was designed.
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