AI Fitness App Development: Building a Workout Recommendation Pipeline

When creating a fitness app that suggests workouts, it's crucial to establish clear objectives for what a successful recommendation should achieve. In this example, the aim is to present up to three workouts that adhere to the user's essential criteria, arranged according to their personal preferences. To accomplish this, several key pieces of information are required:

The user's specific goals and training background provide essential context. The user's available workout equipment and preferred environment are also important factors. The duration of the workout session and any scheduling preferences should be taken into account. The user's preferred exercises and any exclusions they have should also be considered. Additionally, the user's past workout history, explicit feedback, and profile updates can offer valuable insights.

It is important to differentiate between mandatory requirements and optional preferences. A user might only have 20 minutes available for exercise today, but typically prefers longer sessions of around 30 minutes. The actual time limit should not be permanently recorded in the user's profile. Furthermore, it is essential to distinguish between explicit information provided by the user and inferred behavior, such as explicitly stating a preference to exclude certain types of exercises.

To simplify the process of selecting workouts, it is beneficial to model the data in a structured manner. Exercises, workouts, user preferences, and recommendation decisions should be kept separate. An exercise record should include details such as the exercise's ID, name, category, movement pattern, required equipment, skill level, muscle group tags, estimated duration in seconds, selection tags, alternative exercise IDs, metadata version, and publication status. Note that these values are illustrative examples and not a universally accepted fitness standard.

The workout metadata should contain information about the included exercise versions, required equipment, estimated total duration, supported experience categories, goal and style tags, publication status, and any relevant contraindications or review information. By keeping this data separate, it becomes easier to explain recommendations, even if the catalogue changes over time.

To collect inputs, the app can gather information from various sources, such as onboarding, workout logs, feedback, and authorized integrations. It is crucial to validate the structure and meaning of the data before processing it further. For instance, a duration value should be an integer between 5 and 120 minutes. Normalising units and vocabulary is also important to avoid confusion between similar equipment types, such as "band" and "resistance-band."

When generating eligible workout candidates, mandatory checks should be performed first. These checks may include verifying that the workout is published and reviewed, that the required equipment is available, that the session duration matches the user's preferences, and that the user's experience level matches the workout's requirements. Declared exclusions, such as avoiding certain exercises, should also be taken into account.

In addition to hard constraints, the app should also consider soft preferences. For example, if a user has no barbell available, the app can exclude workouts that require a barbell, treating this as a hard equipment constraint. Similarly, the app can prefer workouts that involve band exercises, treating this as a soft preference.

Finally, the app should ensure that a high score is not awarded for a workout that fails to meet any eligibility criteria. It is essential to preserve internal rejection reason codes to investigate empty candidate sets and avoid logging sensitive profile details.