The interesting part of this project was not asking a model to produce a list of exercises. It was deciding what the available records actually allowed the system to conclude.
The starting point was a payload from a rehabilitation workflow: one comprehensive assessment, 53 historical training plans, and one fitness-test event whose result list was empty. The earlier case analysis reported roughly 424 KB of data before adding the exercise library. That was plenty of material to put into a prompt, but it was not yet a trustworthy description of the person’s current condition.
This article develops a software design from that case. The record counts describe the source material; the architecture and validation examples describe the proposed workflow, not a clinically validated deployment or measured improvement in outcomes. The examples omit direct identifiers and generalize individual details. They illustrate professional decision support, not individualized exercise or rehabilitation advice.
What the Historical Records Can—and Cannot—Tell Us
The 53 plans covered approximately eleven months and were recorded with 60-minute planned durations. They contained 113 category entries, 647 exercise prescriptions, and 55 distinct exercise names. Those are counts of recorded prescriptions, not proof that every session or prescribed repetition was completed.
The difference matters. Earlier plans emphasized simpler movement patterns, while later plans included more complex variations and loading. That supports a statement about how the prescribed program changed. It does not, by itself, establish improved strength, movement control, symptom tolerance, or adherence.
I would keep three kinds of evidence separate:
| Evidence | What it can establish | What it cannot establish alone |
|---|---|---|
| Prescribed plan | Intended exercises, configuration, and planned volume | Actual completion or tolerance |
| Execution record | Recorded completion, substitutions, interruptions, and feedback | Objective improvement in function |
| Assessment or test | An observation under a documented protocol and date | The cause of a change or readiness for every exercise |
A field called progressing would hide these distinctions. If the only evidence is a change from an assisted exercise to a loaded variation, I would label it a change in prescription complexity and cite the relevant plans. Functional improvement requires separate supporting observations.
Even numeric trends need context. Values should only be compared after checking units, measurement protocols, dates, and missingness. Deterministic code can calculate a difference; it should not quietly turn that difference into a clinical conclusion.
The empty test result was another useful warning. A record saying that a test event exists does not establish that the test was completed or normal. In this case, there were no usable results in the returned record. Preserving that limitation is more informative than omitting the event.
Build Context That Preserves Evidence and Uncertainty
The payload mixed domain information with audit fields, image links, QR-code URLs, display labels, and internal identifiers. Some fields were irrelevant to generation; others needed interpretation before use.
An exercise’s enabled flag, for example, may be unnecessary in the prompt but essential to candidate filtering. An internal identifier may be unsuitable for publication while still being necessary for authorized traceability in the application. Removing information from model context should not mean discarding it from the system of record.
The context builder should resolve enum values using the actual application definitions, normalize units, and order events by their effective dates. A database insertion time is not automatically an assessment time. If only a month is known, the normalized record should preserve that precision rather than invent a day.
For missing results, a small explicit representation is sufficient:
{
"evidenceId": "test_example_01",
"recordType": "fitness_test",
"dataStatus": "record_present_results_unavailable",
"usableForOutcomeComparison": false,
"results": []
}This illustrative schema distinguishes an empty record from a normal finding. A failed query needs a different status again: the application does not know whether relevant records exist.
The next decision is whether the available evidence is sufficient for the requested task. That decision should use professionally defined requirements, not the model’s self-reported confidence.
Missing optional history may allow a restricted draft with an explicit limitation. Missing required current information, unresolved conflicting restrictions, or an assessment outside the permitted freshness window should pause automatic generation and request clarification. A single comprehensive assessment is not universally sufficient merely because it is comprehensive.
Figure 1. Readiness is checked before generation. Professional constraints remain independent inputs; historical prescriptions are not treated as observed outcomes.
The model-facing context should distinguish source observations, computed summaries, professional constraints, and unresolved questions. Each important claim should link to an opaque evidence reference that authorized reviewers can resolve. Summaries should remain traceable to the underlying record, rather than becoming a new unqualified source of truth.
Names, contact details, signatures, and unrelated account fields should not enter the model request. Replacing IDs alone does not make longitudinal health records anonymous: dates and distinctive histories may still identify someone. Publication examples need separate minimization, and operational access to source records needs user and tenant authorization. Prompts and tool logs deserve the same consideration as the underlying records.
Retrieve Eligible Exercises and Produce a Bounded Proposal
Sending the whole exercise library makes the model responsible for too many unrelated decisions. A more inspectable approach first limits the available choices using application rules, then ranks the eligible candidates for the planning task.
The first pass removes unavailable exercises and configurations, checks equipment and location constraints, and applies the restrictions maintained by qualified professionals. Relevance ranking happens afterward. A high similarity score must not override a known exclusion.
Unknown metadata deserves its own handling. An empty contraindications array could mean that a professional reviewed the entry and recorded no applicable restriction, or simply that nobody populated the field. Those states are not interchangeable. The library needs review status, provenance, and version information; candidates without required metadata should not silently pass an eligibility gate.
Retrieval here does not require a vector database in every case. Structured filters and a relational catalog may be sufficient. Semantic retrieval can help find relevant descriptions, but the backend remains responsible for eligibility and valid configuration. Retrieved text is supporting material, not permission to change the rules.
The model receives a compact candidate set with stable references and the allowed configurations for this request. Names, availability, and parameter definitions remain authoritative in the catalog. A candidate being allowed by the software is still not a claim that it is appropriate for the individual.
I would use two generation stages when the additional latency is justified by better reviewability. The first produces a short planning brief: cited observations, relevant prescription changes, unresolved questions, and proposed priorities. It must distinguish a proposal from a professional finding. This is a review artifact, not a request for hidden reasoning.
The second stage produces a structured draft from that brief, the candidate set, and the original constraints. Constraints should reach this stage independently of the generated summary so that an omission in the brief cannot erase them. The output selects catalog references and configurations; the application resolves their display names and checks their validity.
Schema-constrained output is useful for parsing and required fields. It does not establish whether the proposed exercise sequence or volume is appropriate. Equally, an apparently reasonable narrative should not bypass machine-readable validation.
The two calls should be evaluated against a simpler single-stage baseline. If the planning brief adds cost without improving traceability or reviewer decisions, it is not automatically the better architecture.
Reject Invalid Drafts Without Creating an Endless Repair Loop
Validation should check catalog references, configuration compatibility, resource availability, required fields, duplicates, and encoded restrictions against a versioned snapshot of the relevant data. New plan identifiers should be assigned by the backend rather than invented by the model.
Time and workload checks also need explicit definitions. A field declaring a 60-minute session does not prove that the exercise list fits that duration. Estimates may require rest periods, transitions, and professional assumptions; unknown inputs should produce a warning or block, not false precision. Different exercise modalities also cannot necessarily be reduced to one universal workload sum.
Consider a deliberately simplified failure example. The selected candidate allows a bodyweight configuration, but the draft requests a resistance-band variation that was not in the eligible configuration set. The exercise reference exists, so a referential check alone would pass. A configuration check catches the mismatch:
{
"draftId": "draft_example_01",
"status": "validation_failed",
"errors": [
{
"code": "CONFIGURATION_NOT_ALLOWED",
"exerciseRef": "exercise_example_A",
"field": "configurationType",
"received": "resistance_band",
"allowed": ["bodyweight"]
}
],
"repairAttemptsRemaining": 1
}These are illustrative catalog labels, not an exercise recommendation. The error gives the generator a precise correction target without broadening its permissions.
A repairable draft may receive one constrained regeneration attempt using the same evidence and constraint versions. The entire revised draft must then be validated again, not only the field named in the original error. Missing critical evidence or an unresolved professional restriction should go to clarification rather than an attempt to repair the answer with different wording.
Figure 2. One repair is a bounded policy enforced in application state. Revalidation failure stops automatic generation; no validation branch publishes a plan directly.
If the second draft fails, the system retains the evidence and error details for manual handling. The repair budget belongs to the generation job, so a network retry must not accidentally reset it. Failed artifacts may be inspected for troubleshooting, but they must remain clearly marked and unavailable as executable plans.
Passing automated checks moves a draft to professional review. It does not establish clinical safety. The checks only cover the rules that have been encoded and the evidence available to them. WHO’s guidance on health AI discusses the risks of inaccurate output and automation bias; a review screen should make independent judgment possible rather than encourage routine acceptance. WHO guidance on large multi-modal models for health
The reviewer needs the proposal, its evidence, outstanding limitations, triggered checks, and differences from the previous prescription. Approval should apply to a specific version. If the plan is edited or its underlying assessment changes, the relevant checks and approval state must be revisited. Only an explicitly approved version should become available for use.
Evaluate the Workflow Before Training a More Specialized Model
The first evaluation should examine where the workflow fails, not just whether it produces JSON.
| Question | Evidence to collect |
|---|---|
| Does the context preserve uncertainty? | Cases with empty results, stale records, conflicting observations, and failed queries |
| Does retrieval respect restrictions? | Candidate exclusion errors, missing metadata, and version mismatches |
| Do checks enforce their contract? | Unknown references, invalid configurations, and violations reaching the review queue |
| Can professionals review effectively? | Corrections, rejection reasons, evidence inspection, and time spent reviewing |
| Does the service fail predictably? | Timeouts, repair exhaustion, interrupted jobs, and duplicate requests |
For checks designated as mandatory, zero known violations should pass the gate. That is an acceptance requirement for the validator, not proof of comprehensive safety. Rule coverage and the correctness of the rules require separate review.
Professional edits are particularly useful when captured with a reason. Replacing an exercise because it does not match current ability is different from changing it because the necessary equipment is unavailable. These signals point to different problems in evidence preparation, candidate selection, or generation.
A high acceptance rate alone is not enough. Reviewers may accept suggestions too readily, and two acceptable plans may differ substantially. Evaluation should include deliberate problematic cases and independent review where practical. This case provides architectural lessons; one person’s history cannot establish general performance across a rehabilitation population.
Later, a larger and appropriately governed collection of reviewed examples may support fine-tuning. It should follow a measured baseline rather than substitute for missing rules or weak data preparation. Reviewed records should not automatically become training data without the appropriate data-use controls.
Training examples must contain only information available at the original planning time. Future assessments or later outcomes cannot be included as if the planner already knew them. Evaluation should separate people and time according to the intended use: generalization to new members and forecasting later sessions for known members are different tests.
Observed adherence and functional outcomes may eventually inform evaluation, but improvement cannot automatically be attributed to generated plans. Professional decisions, actual execution, and other changes also affect outcomes. Those questions require a different level of evidence from a schema pass rate or a successful software test.
The most useful lesson from this payload was that a detailed history is not automatically a complete account of a person’s condition. A prescription records an intention. An execution record describes what happened. An assessment provides an observation under particular conditions.
An AI-assisted planning system becomes more useful when it preserves those distinctions through retrieval, generation, and review. Its job is to produce a traceable proposal and stop when the evidence is insufficient. Qualified professionals remain responsible for deciding whether that proposal is appropriate.
Related reading: Spring AI Alibaba tools and controlled execution | Reliable RAG with document quality and evidence