AI workout plans for clients with injuries: what safe should look like

Somewhere in your inbox right now there is probably an AI-generated plan that starts a client with a reconstructed knee on heavy back squats in week one, because the prompt said "goal: leg strength" and nobody asked about the knee.

This is the gap between knowing and programming. Language models have read everything ever written about contraindications. They will happily recite that ACL reconstruction rehab avoids deep flexion under load. Then they write the plan anyway, with a disclaimer stapled to the bottom. The disclaimer is the tell. Real screening is not advice appended to a programme; it is exercises that never appear in it.

We build an AI programme generator (Forge AI), so read this with that in mind. We are also the people who had to solve this problem properly before we dared ship, and the mechanics are worth understanding whichever tool you use.

Knowing an injury exists is not programming around it

Ask a general chatbot for a plan and mention the injury in the prompt, and one of two things happens. Either the injury is ignored, or it is acknowledged in prose while the exercise selection carries on as before. Both produce a document that looks finished.

The failure starts earlier than the model, in how the request is shaped. A paragraph of client notes is not a constraint; it is a suggestion the model weighs against everything else you asked for. Constraints have to be structural: injuries, medical conditions and allergies as first-class fields, sitting upstream of generation, so the system working on your client's plan cannot forget them halfway through.

The brief comes before the model

The approach we landed on inverts the usual order. Before the model writes anything, the client's stated problems are translated into exclusions. Contraindicated movement patterns are removed from the brief itself, so there is no slot waiting to be filled with something the client cannot do.

Food works the same way, and it is where careless systems fail most often. A peanut allergy is not a ban on the string "peanut"; it is a ban on satay and groundnut oil. Gluten rules out couscous, seitan and bulgur, not just bread. A dietary approach like vegan has to hold across the entire plan, not just the recipes that happen to be tagged. Expanding allergies to their derivatives and enforcing diets at ingredient level is unglamorous database work, and it is the difference between a plan that respects the client and one that merely avoided the obvious. We wrote more about the nutrition side in AI meal plans that actually add up.

What code catches that prompting can't

Once the plan exists, it gets checked by code rather than hope. Every stage of it: exercise screening against the stated injuries and conditions, schedule conformance (a Tuesday the client marked unavailable stays unavailable), sensible set, rep and rest ranges, and arithmetic that has to balance.

Then a second, independent review pass reads the finished plan against the client's profile, hunting for what rules cannot catch. In testing, that pass has caught things like a seven-minute continuous cardio block prescribed for an asthmatic client, and a deload week whose calorie drop was risky for a client with diabetes. Those are exactly the plans a tired human skim would wave through, because they look professional.

When either layer finds a problem, the plan arrives in your editor marked "needs review" with specific plain-English notes about what conflicted and why. And one behaviour matters more than any other here: a contraindicated exercise is removed, never silently swapped for a substitute the tool picked itself. Choosing the replacement is coaching judgement. A system that quietly makes that choice for you is not saving you time; it is spending your authority without asking.

Why the flag matters more than the fix

It would be easy to build a generator that papers over every conflict and hands you a clean-looking plan. Some almost certainly do. The reason we refuse to is partly ethical and partly commercial: a coach who sends a plan they cannot stand behind loses the client, and eventually the reputation the business runs on.

So the design escalates instead of guessing. Complex clients, the ones with two conditions and an old injury and a dietary knot, are precisely the plans that come back flagged. That is the system working, not failing. You read the notes, make the call, edit anything you disagree with, and put your name on it. The client only ever sees work from their coach.

What none of this can do

Be suspicious of any tool that skips this section, so here it is plainly. Software cannot examine your client. It does not see how a movement looks on rep eight, does not know pain behaviour, does not hold post-operative protocols beyond whatever you entered, and cannot decide when a problem needs referring out. If a client needs medical clearance before loading an injury, no generator replaces getting it.

What a properly built one does is take the drafting and the screening off your evening, catch the conflicts that slip past a skim, and hand the judgement back to you with its reasoning attached. That is the honest ceiling of the technology in 2026, and it is high enough to be worth using.

If you want a test for whatever generates your plans: tell it a client has an L4/L5 disc issue, then look at what week one loads. "It usually remembers not to" is not an answer. Excluded from the brief, screened at every stage, shown exactly what was removed and why, is. More on how we draw that line in Can AI write a real training programme?. The standard those checks are held to is published in full on our AI safety page.