A platform concept for Burn Boot Camp
The measurement
never stops.
Turn every member's wearable into continuous progress, community, and insight. Without ever exposing who they are.
The insight
You already
measure them.
Body Scans. Focus Meetings. Burn Nation. Your members already opt into being measured and coached, and they love it. This is that, continuous, and fed back into the community they already show up for.
Today
Body Scan · Focus Meeting
Point-in-time. Every few weeks.
→
With wearables
Every day, automatically
Sleep, recovery, effort, streaks.
The concept
One connection. Any device. Two kinds of value.
Any wearable
Watch, ring, band, strap
→
One aggregator API
~Hundreds of devices, normalized
→
The platform
Identity walled off from data
→
Member + Business value
Engagement · analytics
No juggling fifteen device integrations. One aggregator normalizes them all, so a member connects whatever they already wear.
For the member
It's what you gain.
Progress you can see
Recovery, sleep, effort trends, tracked automatically.
Community, gamified
Streaks, consistency, and location team challenges. Effort, not weight.
Motivation that lands
Nudges timed to how they're actually recovering.
A quiet safety net
"We're not doctors, but this pattern is worth a check." No diagnosis, just a heads-up.
For the business
Every trainer walks in already knowing.
Sharper Focus Meetings
The trainer sees sleep, recovery, and last week's effort before the member sits down.
Right-sized challenge
Guide members to the classes that actually fit where they are.
Seasons and promotions
Competitions and offers keyed to real engagement.
Retention signals
Per-location and per-owner analytics that flag drift before a member churns.
The trust architecture
The data can't see who you are.
Identity vault
Who, which member, which location. Small, encrypted, locked down.
Analytics store
Physiological data keyed only by an opaque token. Zero PII.
Leaderboards, recommendations, franchisee analytics, and anything shared with an outside business all run against the token side. They physically cannot see identity. It's the same discipline we built into a regulated insurance platform, adapted to keep the data instead of shredding it.
How it deploys
Built to fit how you want to run it.
Recommended path
Companion app for the pilot → HQ-licensed platform system-wide
A companion app de-risks the pilot and sidesteps the Apple Watch native-app constraint cleanly. The HQ platform unlocks the analytics and data-product upside once it's proven.
Adapts to
Inside your existing app, deepest integration.
Adapts to
Corporate-led, one platform, all locations.
Adapts to
Franchisee opt-in, per-location tool.
Why 'corePHP'
We've already built the hard parts of this.
The closest match
A franchise-scale operational platform with a member app and scorecards
Built and maintained over years, not a one-off.
Scale + global
A platform serving 150+ countries with deep ERP work
Matches your 600+ locations and global expansion.
Sensitive data
Pipelines that handle sensitive personal data responsibly
The discipline behind the trust architecture.
The AI brain
An AI platform with a configurable agent panel, integrated to an external system's API
The same shape as AI on top of a wearable aggregator.
Development. AI. And the design you're looking at right now.
The ask
Start with a paid discovery.
A scoped, paid discovery engagement to lock the architecture, the aggregator, and a pilot plan for a handful of flagship locations. Small commitment now. Clear path to system-wide.
Step 1
Discovery
Architecture, aggregator, pilot plan.
Step 2
Pilot
A few flagship locations, real member data.
Step 3
Region
Prove the model, expand.
Step 4
System-wide
All locations, the data platform.
Appendix · for the CTO
Integration reality
One aggregator (Terra / Rook / Thryve / Spike class) normalizes a few hundred devices behind a single API, so we integrate once, not fifteen times.
The one real constraint
Apple Watch data lives on-device (HealthKit) and can only be read by a native app the member installs. This is exactly why the pilot is a companion app.
Appendix · A2
Identity-vault data model
vault (restricted)
member_id → name, email,
location_id, consent_state
analytics (open to the app)
token → hr, hrv, sleep,
steps, effort, ts (no PII)
The only mapping of token → member_id lives in the vault, behind its own access boundary. Every analytics query, every export, runs token-side.
Appendix · A3
Security & consent
How consent and access work
- Explicit opt-in per member.
- Consent state lives in the vault.
- Revoke stops ingestion and severs the token mapping.
- Encryption at rest and in transit; access to the vault is audited.
Appendix · A4
Built for this scale
Six-figure member base, multi-region from day one (US and global expansion, including the Canada rollout).
Appendix · A5
Build phasing
Step 1
Discovery
Aggregator integration and the identity vault.
Step 2
Pilot
Companion app, live at a handful of locations.
Step 3
Region
Analytics and franchisee dashboards.
Step 4
System-wide
HQ platform and the data-product layer.