Rack Radar: Scan before you lift
Every gym has the same unsolved problem, and it has nothing to do with fitness. You arrive at seven, walk to the bench press, and there are three people on it. So you wander, wait, or train something you didn't plan to train. Nobody in the building has data on this, because nobody has ever been asked to collect it.
Rack Radar collects exactly one thing. Before you use a machine, you scan the code taped to its frame. That single row is the whole data product.
The problem, and the opportunity behind it
The member-facing problem is scheduling. When is the squat rack actually free on a Wednesday? If the bench is packed right now, what else can I do for chest without abandoning the session?
The commercial problem sitting behind it is more interesting. Gym managers buy equipment essentially blind. They know what they own and what it cost, but not which machines are saturated at peak and which ones sit untouched for weeks. Should the next purchase be a second squat rack or a second bench? Nobody knows, so it gets decided by whoever asks loudest.
The same scan table answers both. What differs is who is asking.
Who it's for
Four people, each with a different question and a different right to the data:
- Members want timing and alternatives. Their own history, plus gym-wide patterns.
- Trainers want attendance. Their assigned clients only, nobody else's.
- Managers want utilization and purchasing evidence. Everything.
- Maintenance technicians want wear. Machine hours only, no member data at all.
That last one turned out to be the cleanest demonstration of the whole design, which I'll come back to.
Architecture and data flow
scan (member taps a machine code)
└─> scans (Delta, ~200k rows, 6 months)
└─> gold views (busyness, quiet windows, swaps, utilization, service)
└─> persona views (filtered per role)
└─> 4 Genie Spaces (one per persona, disjoint view sets)
└─> Databricks App (Stream lit)
A scan writes a row.. Persona views filter those by role. Each persona then has its own Genie Space, attached only to its own views.
The app holds a persona switcher and routes each question
Everything runs on Databricks Free Edition. Data is synthetic, generated to hold real shapes: morning and evening peaks, a dead mid-afternoon, chronic Monday chest congestion, a January surge that decays by March, two saturated machines and three nobody touches.
Deployment and governance
The app deploys as a Databricks App, with each Genie Space and the SQL warehouse attached as app resources rather than hardcoded ids.
Governance is the one place where the Free Edition build and a real deployment diverge, and it's worth being precise about it. Free Edition is effectively a single-user workspace, so the persona switch here is an application-level control: the app looks up a role and picks the matching Space. On a deployed workspace that control moves down into the platform. The same persona views become Unity Catalog row filters and column masks bound to account groups, so a trainer is restricted to their own clients by the catalog itself rather than by the app choosing which view to query. The identity comes from workspace SSO, and each Genie Space is granted to the corresponding group.
Nothing about the model changes when that happens. The views were shaped for it from the start — same filter predicates, same disjoint sets of columns per role — which is why the persona-per-Space structure was worth building even in an environment that can't enforce it yet.
What you can ask it
As a member
- When is the squat rack usually quiet on Wednesdays?
- The bench is packed. What else trains chest that's open right now?
- I have 45 minutes at 7pm — what will I actually get on?
- Which day of the week is the gym quietest?
As a trainer
- Which of my clients haven't been in for three weeks?
- What time of day do my clients mostly train?
As a manager
- Which machines run above 90% of capacity at evening peak?
- Should we buy a second bench or a second rack? Show utilization for both.
- What have members asked that returned no rows?
As a technician
- What's overdue for service based on hours used, not date?
How Genie powers it
Remove Genie and there is nothing left but a coloured table. There is no filter UI in this app, no muscle-group picker, no time-range selector. The question is the interface.
The part I'd point at first is machine substitution. "The bench is packed, what else can I do for chest" sounds like it needs a model with opinions about exercise science. It doesn't. It needs a hand-seeded machine alternatives table joined to live occupancy, so every suggestion is a real station that is genuinely free right now. Genie writes that join. It does not improvise the training advice, and the Space instructions say so explicitly.
The second thing is the persona split. Ask "which machines are busiest" as a member and as a manager and you get two correct, different answers, because the two spaces are pointed at different views. That is a data boundary, not a politely worded prompt.
What I learned
Curating the Space mattered more than building the app. The UI took an afternoon. Getting Genie to answer reliably took considerably longer, and almost all of that time went into column comments, synonyms, and certified example queries. The two hardest questions — the swap join and the quiet-window group-by — simply did not work until I gave each one a worked SQL example in the Space. Rewording the question never helped. Adding an example always did.
Vocabulary is the real integration work. People say bench, flat bench, and bench press. They say packed, busy, crowded and full. They say leg day. None of that is in a column name. The synonym list ended up being one of the highest-value things in the whole build.
Materialize anything you want asked about. Every time I let Genie derive a value on the fly, reliability dropped. Weekday, hour, and busyness band all became stored columns, and the error rate fell sharply.
Be honest about time windows. I originally labelled current occupancy "right now". It isn't. Members don't check out, and serverless queries take a moment. Calling it "the last 5 minutes" is both more accurate and, oddly, more trustworthy to the person reading it.
The best feature was an accident. Logging questions was meant to be instrumentation. Then I asked the log which questions returned zero rows, and the top answers were things like women-only hours, sauna availability and the class timetable. None of those exist in the data model. Failed questions turned out to be a demand signal the gym had no other way of hearing.
Future scope
- Prediction. Six months of scans is enough to move from "typically quiet at 2pm" to a genuine forecast, with weekday, season, weather and holiday features. Today the app deliberately refuses to predict, because the data behind it is honest patterns and nothing more. That's the next obvious step, not the current claim.
- Personal patterns. Once individual histories are long enough, suggest a session time that fits both your usual slot and low machine contention, and flag when your routine depends on the one machine that's always contested.
- Wait-time estimates and an opt-in queue for the two or three chronic bottlenecks.
- Real capacity planning. Simulate the effect of adding a station before buying it.
- Predictive maintenance, using hours and session intensity rather than the calendar.
- A front-desk nutrition shelf, where product label claims get checked against the actual numbers instead of the marketing.
