F9.1 Phase 2 — Exercise Catalog Backfill Runbook

A step-by-step guide for the clinical lead who will tag the existing exercise catalog with the F9.1 Phase 2 taxonomy. This runbook covers only the tagging pass. It does not cover authoring pose-tracking configurations — that work is intentionally deferred until the pose-aggregation engine ships (see § When NOT to author pose configs).

Audience: clinical lead doing the legacy-platform import.
Tooling: Console at console.restartix.pro (or staging equivalent), the /exercises/* and /vocabulary/* admin surfaces.
Out of scope: writing code, running migrations, anything in a terminal.

What you're doing, in one sentence

For every exercise in the legacy catalog import, attach the right set of clinical tags — body region(s), movement pattern, recovery phase, conditions it helps, conditions it must not be used for, equipment needed, prerequisite skills, and a top-level category — so the new program builder, library filters, and per-patient body map work the way clinicians expect.

Before you start

1. Confirm the platform vocabulary is seeded

The platform ships with a starter vocabulary of about 80 rows across the seven tag axes — categories, body regions, equipment, movement patterns, recovery phases, conditions (with ICD-10 codes), and skill prerequisites. Open the Console and skim each list under **Vocabulary → ***:

• Categories (~8): Strength, Mobility, Stretching, Balance, Proprioception, Stabilization, Cardio, Post-Op Rehab.
• Body Regions (~17): cervical, thoracic, lumbar, pelvis, core/abdomen, shoulder, elbow, wrist/hand, upper back, chest, hip, thigh, hamstring, knee, calf, ankle, foot.
• Equipment (~14): bodyweight → mat → chair → wall → step → towel → resistance band → foam roller → swiss ball → yoga block → dumbbell → kettlebell → medicine ball → BOSU ball.
• Movement Patterns (9): push, pull, squat, hinge, lunge, rotation, carry, gait, hold.
• Recovery Phases (5): acute, subacute, strength, return to activity, maintenance.
• Conditions (~18): low back pain, cervical pain, sciatica, lumbar disc herniation, rotator cuff impingement, frozen shoulder, tennis/golfer's elbow, carpal tunnel, hip/knee osteoarthritis, meniscus, post-ACL, post-TKR, post-THR, ankle sprain, Achilles tendinopathy, etc. Each carries an ICD-10 code.
• Skill Prerequisites (~10): static/dynamic balance, single-leg stance, floor-to-stand, grip strength, bilateral coordination, weight-bearing tolerance, core endurance, trunk control, scapular control.

This seed is intentionally minimal — it covers the common rehab presentations and exercises the team sees today. It is not a finished clinical taxonomy. You will add more as the backfill proceeds.

2. Identify the gaps

Before tagging anything, do a quick read-through of your exercise list and flag rows that don't obviously fit. Typical gaps to expect:

• A rare body region (e.g. TMJ, sacrum) the seed doesn't include.
• A condition the seed didn't anticipate (e.g. patellofemoral pain syndrome, plantar fasciitis, post-rotator-cuff repair).
• A piece of equipment that's clinic-specific (e.g. vibration plate, TheraBand CLX, slant board).
• A skill prerequisite that's specific to your patient population.

Write the gaps down. You'll add them in the next step before you start tagging.

3. Add the missing tags via Console

For each gap, open the relevant Console vocabulary surface and create the missing row. The four locked axes (body regions, movement patterns, recovery phases, skill prerequisites) are platform-only — only a superadmin can add to them. Categories, equipment, and conditions are dual-scope — you can add platform-wide tags (visible to every clinic) or org-private ones (visible only to your clinic).

Rule of thumb: add platform-wide unless the tag is specific to your clinic's vocabulary or services. Platform-wide tags benefit every clinic that comes after you; org-private tags clutter their UI.

For Romanian launch, every new tag should follow the seed convention:

• Name = English canonical (e.g. Patellofemoral Pain Syndrome).
• Slug = English snake_case (e.g. patellofemoral_pain). This is the stable identifier — do not change it later.
• Romanian display name goes in the translations field as {"ro": "Sindrom femuro-patelar"}. Romanian is the launch market's UI language; the slug is the universal identifier behind the scenes.
• Description = a one-sentence clinical explanation. Romanian translation goes in translations.ro.
• For conditions: include an ICD-10 code if you know it. It can be added later if uncertain.
• For body-region-linked conditions: pick the primary body_region_id (the picker will offer the existing regions).

The "never modify in place" rule

This is the most important rule in the backfill. Read it before you start clicking edit.

Once a tag row is active (anything other than deprecated), you cannot rename its slug or its clinical meaning. The platform enforces this with a database trigger that blocks renames on active rows.

What this means in practice:

• Display-only edits (description, sort_order, translations, icon_url) are always allowed. Fix typos in the Romanian translation freely. Reorder the sort. Polish descriptions.
• Identity edits (slug, name) are only allowed on deprecated rows.
• If you realise a tag's meaning is wrong — e.g. you called something "Lumbar" but it actually means "Lumbosacral" — do not edit the existing row.

The correct workflow when a tag's meaning needs to change:

1. Deprecate the wrong row via the Console "Deprecate" action.
2. Create a new row with the right name + slug.
3. Re-tag the affected exercises onto the new row.
4. Optionally edit the deprecated row's name once it's no longer active (the trigger then permits it), but most teams leave deprecated rows alone for historical clarity.

Deprecated rows stay in the database — they're hidden from the default picker, but still resolvable when looking up historical session data. This is intentional. Historical session reports must continue to mean what they said at the time.

Bottom line: when in doubt about a tag's name, think before you save. Renaming after the fact is impossible.

The per-exercise tagging checklist

For each exercise in the catalog, work through this checklist in order. The Console "Edit Exercise" surface has one tab per axis; the order below is the order they appear in the UI.

a. Category

Pick exactly one category — the top-level program-builder grouping. If an exercise legitimately spans two categories (e.g. "Squat with band" is both Strength and Stabilization), pick the primary one. Categories drive program builder defaults; secondary intents land via movement_pattern + recovery_phase instead.

b. Body region(s)

Pick all body regions the exercise targets. A bird-dog targets core_abdomen + lumbar + hip simultaneously — tag all three. This is what makes the per-patient body-map filter work.

Body region tags are platform-only. If you discover a missing region, ask a superadmin to add it before you continue.

c. Movement pattern

Pick one movement pattern from the 9: push, pull, squat, hinge, lunge, rotation, carry, gait, hold. This is a biomechanical classification — it does not correspond to a body part. An overhead press is push. A deadlift is hinge. A plank is hold.

If an exercise is a composite (e.g. Turkish get-up), pick the dominant pattern, not the one with the longest range. When unsure, leave blank and consult a colleague — empty is better than wrong.

d. Recovery phase(s)

Pick all phases the exercise is appropriate for. Most exercises span more than one — a wall-sit fits acute, subacute, and early strength; barbell back-squat fits strength and return to activity, not earlier.

Recovery phase tags drive the program-builder safety gating: a patient flagged acute should not be prescribed an exercise tagged only strength.

e. Conditions indicated

Pick all conditions this exercise is appropriate for. This is the indication axis — "use this exercise when treating X." Be liberal here; an exercise that helps low-back pain and post-knee-replacement and Achilles tendinopathy can carry all three tags.

For unusual conditions, add them via Console Vocabulary first (see the gap-filling step above). Include the ICD-10 code when known.

f. Contraindications

Pick all conditions this exercise should NOT be used for. This is the contraindication axis — "do not use this exercise for X." For each contraindication, set the severity:

• contraindicated = absolute "do not use" (e.g. deep squat for someone post-TKR in the first 6 weeks).
• warning = relative "use with caution" (e.g. overhead pressing for someone with a recent rotator cuff repair — appropriate once cleared, not before).

Add a short clinical description: why is this contraindicated?

Important — Class I posture.
The platform currently presents contraindications as informational — the specialist sees the warning, the specialist makes the decision. There is no automated block preventing a specialist from prescribing a contraindicated exercise; that formal signoff workflow is part of a future regulatory upgrade and is intentionally not in this backfill scope.
Write the contraindications clearly enough that a specialist reading the warning knows why it's flagged.

g. Equipment needed

Pick all equipment the patient needs at home. Be honest — an exercise listed as "bodyweight" but actually requiring a chair will frustrate patients who don't have one.

Equipment is dual-scope — add clinic-specific equipment (e.g. a vibration plate you supply) as org-private. Equipment that any clinic could realistically have (bands, foam rollers, etc.) goes platform-wide.

h. Skill prerequisites

Pick all skills the patient must have before this exercise is appropriate. If an exercise requires single-leg stance and the patient hasn't demonstrated it yet, the program builder should not offer it.

Skill prerequisites are platform-only. Ask a superadmin if you need to add one.

i. Exercise-level prerequisites (other exercises)

If this exercise should only be prescribed after the patient has mastered another exercise (e.g. single-leg deadlift requires bilateral deadlift first), link them under the "Prerequisite exercises" section. The platform enforces a no-cycle rule: A→B and B→A cannot coexist.

j. Save and review

Save the exercise, then open the patient-facing preview to confirm the tag set reads correctly in Romanian. The translations.ro field on every tag is what the patient sees.

Decision matrix: add a new tag vs. reuse an existing one

This comes up constantly during a backfill. Default answer: reuse. Add a new tag only when:

Situation	Action
The existing tag's name fits "well enough" but not perfectly	Reuse. Don't fragment the vocabulary.
The existing tag's name is genuinely wrong for what you want to express	Deprecate the old one and add a new one. Never edit-in-place.
The existing tag is a superset of what you want (e.g. "Low Back Pain" when you want "Lumbar Disc Herniation")	Add a new, more specific tag. Both can be active simultaneously.
The existing tag is a subset of what you want	Reuse. Most clinical taxonomies handle subset relations via the body_region_id link on conditions and the multi-tag pattern on exercises.
You want to rename a tag because the Romanian translation is awkward	Edit translations.ro in place. It's display-only and the rename rule does not apply.
You want to rename a tag because the English name has a typo	Edit name in place IF the slug is still right. The rename trigger blocks slug changes, not name changes. (But: the slug is what shows up in URLs and exports; if the slug is wrong, treat it like a meaning change — deprecate and re-create.)

When NOT to author pose configs

The platform's pose-tracking configuration surface — what landmarks to track, what metrics to compute, what feedback rules to fire — is fully built and ready to accept configurations. Do not author pose configs during the initial backfill.

Reason: the pose-aggregation engine that consumes those configurations (the telemetry-side runtime that ingests video frames, computes the metrics, and surfaces them to specialists) is a separate piece of work that has not shipped yet. Authoring configs against a non-existent engine would mean:

• The configs are never validated against real telemetry data.
• Clinical-team time spent authoring them now would have to be re-spent once the engine ships and reveals what the data actually looks like.
• Any "tracking_enabled" flag on a config that's never consumed is misleading to specialists who toggle it.

When the engine ships, authoring pose configs becomes a separate clinical-content pass — likely a small set of high-value exercises first (squats, lunges, deadlifts) where the rep-counting heuristics produce stable signal. The backfill described here is the taxonomy pass only; pose config authoring is its own phase, later.

For now: leave every exercise's "Pose Configuration" tab empty.

Quality-control suggestions

A few patterns that catch the most common mistakes:

• Sample-check 10 exercises per session with a colleague. Cross-checking is faster than fixing errors after the fact.
• Spot-check the Romanian translations by switching the Console UI to Romanian (your profile dropdown). Confusing or stilted translations are easier to spot in context than in the edit form.
• Run the per-patient body-map filter after tagging the first 30–50 exercises. If the body map shows zero exercises for a region that should have lots (e.g. "Shoulder" returns nothing), there's a tagging gap.
• Run the condition picker after tagging your first batch. Type the Romanian name (e.g. "lombalgie") — if it doesn't match the seeded Low Back Pain (non-specific) row, the translations.ro is missing or wrong on that condition.
• For each newly-added tag, double-check the slug before saving. The rename rule applies the moment the row is active.

When to escalate

Talk to engineering before any of:

• A whole new tag axis (e.g. "Patient Population" — kids, geriatric, athlete) the platform doesn't have.
• A bulk-import need (hundreds of rows in one go). The Console handles per-row editing well; bulk operations are an engineering-driven script.
• A tagging requirement that doesn't map cleanly onto the seven existing axes.

Talk to a superadmin (engineering or platform admin) for any change to the four platform-only axes — body regions, movement patterns, recovery phases, skill prerequisites.

Quick reference

• Console URLs (substitute your environment):
  • Vocabulary: console.restartix.pro/vocabulary/{axis} — one page per axis.
  • Exercises: console.restartix.pro/exercises/{id} — per-exercise edit surface with one tab per tag axis.
• Slug convention: lowercase English snake_case, stable forever (rename = deprecate + recreate).
• Display name convention: English in name, Romanian in translations.ro.
• Deprecation is reversible-ish: deprecated rows are hidden from default pickers but still resolve historical data; re-activation is possible but rare.
• Pose configs: leave empty for now.

If anything in this runbook is unclear or contradicts what you see in the Console, flag it — the runbook should match the UI exactly.