AI fitness-program workflow (private client)
A paid client engagement: an AI fitness-programming workflow with a source corpus, an authority registry, and three verification layers before any program reaches an athlete.
forward-deployed · source corpus · adversarial verification · human-in-the-loop
Delivered forward-deployed through AI Workflow School — a workflow that generates personalised strength-training programs from a trusted source corpus, and refuses to ship one until three layers of verification pass.
The hard part isn’t generating a training program. Any model will write you one. The hard part is making sure it reflects a specific coaching methodology rather than the model’s averaged-out idea of fitness advice — and proving that before a human follows it.
The constraint
A generated program is a safety-relevant artifact. Someone loads a barbell based on it. Free-styled output that sounds authoritative is worse than no output, because it reads exactly like a program grounded in real methodology.
So the whole workflow is built around one rule: the generator cites trusted material, or it doesn’t ship.
How it works
Intake & Corpus
↓
Program Generation
↓
Three-Layer Verification ← human gate
↓
Two-View Output1. Intake and corpus
Smart intake captures the athlete’s constraints against intake.schema.yaml.
Separately — and this is the forward-deployed part — I sat with the client and ingested 14 hours of StrongFirst and Blueprint methodology transcripts into a source corpus, paired with an authority.registry.yaml recording what each source is allowed to speak to.
The registry is what turns “the model read some fitness content” into “the generator cites a trusted source for this claim.”
2. Program generation
program-generator.prompt.md runs over the corpus and the intake to produce a personalised program.
The prompt itself is the deliverable. The client keeps it and re-runs it — they aren’t buying one program, they’re buying the thing that makes programs.
3. Three-layer verification
Nothing reaches a human until it clears three layers:
- L1 — deterministic checks. Mechanical validation: structure, required fields, internal consistency.
- L2 — adversarial cross-model. Codex and Claude are pointed at each other’s output to catch errors the other missed. Two models checking each other, not one model grading itself.
- L3 — expert review. A human coach reviews. This gate is not automated and isn’t meant to be.
Only L3-passed programs proceed.
4. Two-view output
A passed program splits into two artifacts:
expert-view.md— full reasoning, source citations, the coach’s audit trailuser-view.md— what the athlete actually follows, plus daily delivery
Same program, two audiences. The coach can defend it; the athlete can use it.
The build verifies itself
The build is checked the same way its output is. Feature files encode machine-checkable CONDITION-MET probes — grep tokens, file existence, ARCHITECTURE.md consistency — so Claude Code verifies its own build steps through /loop instead of reporting done and hoping.
Status
Active client engagement. Client details anonymised.