Documentation

The Open Exercise Database is an open, structured, and professionally validated repository of physical exercises designed to serve researchers, developers, clinicians, educators, and exercise professionals.

The database provides machine readable, consistently structured exercise descriptions that can be used in:

• Research studies
• Digital health systems
• Behavior change interventions
• Rehabilitation platforms
• Fitness and wellness applications
• Educational materials

The platform combines open community contribution with professional validation to ensure both accessibility and scientific integrity.

Core Definition

Physical exercise is a type of physical activity that is planned, structured, repetitive, and performed with the specific purpose of improving or maintaining physical fitness and health.

In exercise science, exercise is defined as a subcategory of physical activity in which muscle contractions are organized in a planned, structured, and repetitive manner.

The goal of exercise is to improve or maintain one or more components of physical fitness, including:

• Cardiovascular endurance
• Muscular strength
• Muscular endurance
• Flexibility
• Balance and coordination
• Body composition

Difference Between Physical Activity and Physical Exercise

Physical activity refers to any bodily movement produced by skeletal muscles that requires energy expenditure. This includes:

• Occupational movement
• Transportation such as walking or cycling
• Household tasks
• Recreational movement

Physical exercise is narrower in scope. It is:

• Intentional
• Structured
• Repetitive
• Designed with a specific fitness goal

This distinction is important for research and digital systems, as the database focuses specifically on structured exercise rather than all forms of movement.

The Open Exercise Database aims to provide:

• A standardized representation of exercises
• A consistent schema for structured data
• Open access to exercise descriptions
• A transparent validation mechanism
• Traceable metadata and versioning

Unlike many proprietary exercise databases, this project prioritizes:

• Openness
• Scientific neutrality
• Community contribution
• Professional oversight
• Long term extensibility

The database is designed to be both human readable and machine actionable.

Each exercise in the database follows a structured schema to ensure consistency and interoperability.

4.1 Basic Information

Includes:

• Unique identifier
• Name
• Categories
• Targeted body parts
• Required equipment
• Location context

Categories include:

• Endurance
• Strength and resistance
• Flexibility and mobility
• Balance and coordination
• Relaxation and breathing

This structure enables filtering, searching, and integration into external systems. It is extensible to accommodate future classifications.

4.2 Instructions

Instructions are organized as a sequence of clearly defined steps.

Each step includes:

• Step number
• Description of the movement

Instructions must:

• Be sequential
• Be biomechanically clear
• Avoid ambiguity
• Avoid unsafe cues
• Avoid unsupported medical claims

4.3 Performance Metrics

Performance metrics describe how the exercise may be measured.

These do not prescribe values. Instead, they define measurable dimensions such as:

• Number of repetitions
• Duration
• Distance
• Load or resistance
• Heart rate targets
• Physiological parameters

This enables integration into tracking systems, research protocols, and digital monitoring platforms.

4.4 Variations and Relationships

Exercises may reference other exercises through structured relationships.

These relationships may represent variations, progressions, regressions, or closely related movements.

This supports structured linking between related exercises and enables interoperability across systems.

4.5 Media Content

Exercises may include:

• One or more instructional images
• Files stored using a standardized folder structure
• Image references linked within the JSON representation

Images are intended to be:

• Educational
• Neutral
• Biomechanically accurate
• Free of branding or promotional elements

4.6 Metadata and Review Tracking

Each exercise includes metadata for transparency and traceability.

Metadata includes:

• Created by
• Review status
• Reviewed by
• Date reviewed
• Review notes
• Date created
• Last updated
• Last edited by
• Deduplication status

Review statuses include:

• Community
• Validated
• Edited and validated
• Rejected

This structure ensures accountability, reproducibility, and auditability.

The database operates under an open contribution model.

Anyone can:

• Submit new exercises
• Suggest edits or improvements
• Contribute variations

Submissions are stored in the community branch and undergo professional review before validation.

Validated exercises are reviewed by verified professionals.

Reviewers assess:

• Safety and biomechanical soundness
• Clarity of instructions
• Structural consistency
• Scientific neutrality
• Duplication and overlap

Validation indicates that a qualified professional has reviewed the exercise for clarity and safety.

Validation does not constitute medical advice, individualized prescription, or clinical recommendation.

The Open Exercise Database can be used for:

Research

• Standardized exercise representation in studies
• Structured datasets for physical activity research
• Machine learning applications
• Behavior change intervention modeling

Digital Health Applications

• Exercise recommendation engines
• Rehabilitation platforms
• Remote monitoring systems
• Personalized coaching systems

The platform supports AI assisted drafting of exercises.

AI may be used to:

• Generate structured exercise descriptions
• Draft instructional text
• Generate neutral instructional images

All AI generated exercises remain clearly labeled and require professional validation before being marked as validated.

AI supports the workflow but does not replace human oversight.

The database provides structured exercise descriptions for educational and research purposes.

It does not:

• Provide individualized medical prescriptions
• Replace professional clinical judgment
• Guarantee specific health outcomes
• Serve as medical advice

Users are responsible for applying exercises appropriately within their professional or personal context.

All exercises are version controlled via GitHub.

Changes are traceable. Review actions are recorded. Metadata provides historical context for every modification.

This ensures:

• Transparency
• Accountability
• Scientific reproducibility

This appendix defines the structured representation used in the Open Exercise Database. The schema is designed to be machine readable, consistent across entries, and extensible over time.

All exercises are stored as individual JSON objects using a standardized structure.

A.1 Top Level Structure

Each exercise is represented as a JSON object with the following top level fields:

{
  "id": "string",
  "name": "string",
  "categories": ["string"],
  "exerciseEffects": ["string"],
  "bodyParts": ["string"],
  "equipment": ["string"],
  "location": ["string"],
  "instructions": [InstructionStep],
  "performanceMetrics": [PerformanceMetric],
  "variations": [VariationReference],
  "mediaContent": MediaContent,
  "metadata": Metadata,
  "commentsNotes": ["string"]
}

All fields must be present unless explicitly stated as optional.

A.2 Field Specifications

A.2.1 id

Type: string
Required: yes
Format: EX<slug><unique_string> or EX<number>

Unique identifier for the exercise. It must not collide with any existing exercise. The identifier is immutable once created.

Example:

EX_glute_bridge_01HZY3Q7Z3W8K2QFJ6V9B1T8M4

A.2.2 name

Type: string
Required: yes

Human readable name of the exercise.

Example: Glute Bridge

A.2.3 categories

Type: array of strings
Required: yes

Allowed values:

• Endurance
• Strength and resistance
• Flexibility and mobility
• Balance and coordination
• Relaxation and breathing

Defines the primary classification of the exercise. Multiple categories are allowed. This field is extensible.

A.2.4 exerciseEffects

Type: array of strings
Required: yes

Describes intended physiological or functional effects. Effects must remain neutral and avoid exaggerated or unsupported claims.

Examples:

• increased muscle strength
• improved body balance
• improved range of motion
• increased heart rate
• stretch muscle

This field is extensible.

A.2.5 bodyParts

Type: array of strings
Required: yes

Specifies primary targeted muscle groups or body regions. Multiple entries are allowed.

Examples: glutes, hamstrings, quadriceps, core, shoulders

This field is extensible.

A.2.6 equipment

Type: array of strings
Required: yes (may be an empty array)

Lists equipment required to perform the exercise. If no equipment is required, use an empty array.

Examples: exercise mat, resistance band, dumbbell, barbell

This field is extensible.

A.2.7 location

Type: array of strings
Required: yes

Allowed values: indoor, outdoor. Multiple values are allowed.

A.3 Instructions Structure

A.3.1 instructions

Type: array of InstructionStep
Required: yes

Structure:

{
  "stepNumber": number,
  "description": "string"
}

Requirements:

• stepNumber must be sequential starting from 1
• description must clearly describe movement execution
• Unsafe cues must be avoided
• Medical claims must not be included

Example:

{
  "stepNumber": 1,
  "description": "Lie on your back with knees bent and feet flat on the floor."
}

A.4 Performance Metrics

A.4.1 performanceMetrics

Type: array of PerformanceMetric
Required: yes

Structure:

{
  "type": "string",
  "unit": "string",
  "notes": "string"
}

Defines how the exercise may be measured. The schema specifies measurement dimensions rather than prescribed values.

Examples of types:

• Number of repetitions
• Duration
• Distance
• Weight or resistance
• Heart rate goal
• Physiological parameters

This field is extensible.

A.5 Variations and Relationships

A.5.1 variations

Type: array of VariationReference
Required: yes (may be empty)

Structure:

{
  "id": "string",
  "variationDescription": "string"
}

References related exercises by identifier. These relationships may represent:

• Variation
• Progression
• Regression
• Closely related movement

The referenced exercise must exist in the database.

Alternatively, variations may be recorded as a suggestion rather than a strict reference:

{
  "exerciseName": "string",
  "variationDescription": "string"
}

A.6 Media Content

A.6.1 mediaContent

Type: object
Required: yes

Structure:

{
  "imageURLs": ["string"]
}

Lists image filenames associated with the exercise.

Images must be stored under:

images/<exercise_id>/

Example:

"imageURLs": [
  "EX_00001_start.png",
  "EX_00001_top.png"
]

A.7 Metadata and Review Tracking

A.7.1 metadata

Type: object
Required: yes

Structure:

{
  "createdBy": "string",
  "reviewStatus": "string",
  "reviewedBy": ["string"],
  "dateReviewed": "string | null",
  "reviewNotes": "string",
  "dateCreated": "string",
  "lastUpdated": "string",
  "lastEditedBy": "string",
  "duplicateOf": "string | null"
}

A.7.1.1 createdBy

Allowed values:

• community author
• ai generated
• co generated with ai
• professional

A.7.1.2 reviewStatus

Allowed values:

• community
• validated
• edited and validated
• rejected

A.7.1.3 reviewedBy

Array of GitHub usernames who performed validation.

A.7.1.4 dateReviewed

Format: YYYY MM DD. Null if not yet reviewed.

A.7.1.5 reviewNotes

Free text summary of review decision.

A.7.1.6 dateCreated

Format: YYYY MM DD

A.7.1.7 lastUpdated

Format: YYYY MM DD

A.7.1.8 lastEditedBy

GitHub username of last editor.

A.7.1.10 duplicateOf

String ID of canonical exercise if marked duplicate. Null otherwise.

A.8 Comments and Notes

A.8.1 commentsNotes

Type: array of strings
Required: yes (may be empty)

Contains additional tips, warnings, or clarifications.

Examples:

• If wrist discomfort occurs, modify hand position.
• Warm up before starting to reduce injury risk.

Statements must remain neutral and avoid medical prescription.

A.10 Extensibility

The schema is designed to be extensible. Future extensions may include:

• Difficulty level
• Estimated metabolic intensity
• Contraindications
• Population tags
• Evidence references
• Video content
• Multilingual support

Backward compatibility must be preserved when extending the schema.