Arc Katalyst

The problem

Most fitness and coaching software asks what did you do? and compares it to a plan. That works for people who are already performing. It fails everyone else. A person who hasn't logged a meal in two weeks doesn't need macros and periodization — they need to be moved from not doing the thing to doing it. Existing tools treat every user as if they're in the performance stage. The result is overwhelm, dropout, and coaches spending time on the wrong problem.

Arc Katalyst is built on a different thesis: performance is a position on a behavioral arc, not a plan-compliance score. Move people along the arc, and outcomes follow.

The product bet

Every user sits somewhere on a four-stage progression — Non-Action → Action → Consistency → Performance — for every dimension they train. The system's first job is classification: where is this person right now? Its second job is prescribing the right intervention for that stage.

A user in Non-Action gets a minimum viable action ("log one meal today"). A user in Consistency gets a coaching refinement ("your protein is trending 20g below target on rest days"). A user in Performance gets the periodization and progressive overload that most tools apply to everyone.

The classification and intervention selection are deterministic — a five-tier rules pipeline, not LLM generation. Every input combination produces exactly one classification, one decision path, one output. The system proposes; the user commits.

Product architecture

Arc's structure is a six-level taxonomy: Vertical → Segment → Arc → Goal → Path → Dimension. Three verticals (Individual, Athletic, Professional), 23 arcs across them, seven universal dimensions users actually log (Nutrition, Resistance Training, Cardio, Daily Activity, Other Activity, Rest, Sleep). Every arc is a time-bound behavioral structure with a four-phase progression: Baseline → Build → Push → Lock-in.

Scoring runs through a 25-block CARD pillar model (Consistency, Adherence, Results, Depth) with phase-aware weighting — what matters in Baseline isn't what matters in Push. Additional scoring layers cover Energy & Metabolism, Athletic Development Index, Physiology, Deficit Prediction, and Readiness.

Underneath sits a layered intelligence system: 38 registered layers across five modules (Governance, Data Intelligence, Diagnostic Intelligence, Coaching Intelligence, Behavior Intelligence). Each layer is a pure function with defined inputs and outputs. A CI gate enforces parity between the layer registry document and the actual code — you can't add a layer in code without registering it in canon, or vice versa.

The architectural discipline comes from the ARC Lineage Doctrine, a validation framework I established to prevent feature drift. Its core rule: every layer must support at least one behavioral transition. Layers that don't don't belong in the system. The doctrine also enforces one priority at a time, no silence, no punishment, behavior first, and user autonomy. Every new capability gets validated against it before it ships.

What shipped

A production-grade product across three surfaces, running on a single shared data model and decision engine:

• React Native mobile app (iOS and Android) — the athlete surface. Ten-step onboarding, daily logging across all seven dimensions (with barcode scanning, AI-powered food search, HR zone tracking, and biometric lock), Arc Score visualization, weekly plan and review cycles, plan builder, progress photos, exercise library, messaging, share cards. 66 screens, 52 components, 10 end-to-end test flows gating CI.
• React web application — the coach command center. Coach Pulse (a four-tab accountability worklist with duty decomposition and SLA windows), Plan Builder (workout, nutrition, and cardio authoring), roster management, dimension-level responsibility scoping, team aggregation dashboards. 1,566 source files.
• Supabase backend — Postgres with 413 migrations, Row-Level Security throughout for coach/athlete isolation and org-level multi-tenancy, 36 edge functions covering the coaching decision engine, adaptive plan evaluation, AI nutrition analysis, video analysis, badge and challenge evaluation, share card generation, and the coach notification pipeline.

How it was built

That scope, on a one-operator team in 16 weeks, came from a delivery model I designed: traditional agile ceremonies on top, an agent-governed execution harness underneath. My product judgment sat at two gates — card specification and PR review — not in the middle of implementation.

Ceremonies stayed traditional. Sprint planning, backlog refinement, retros, cards with story, acceptance criteria, and definition of done — the same shape as any well-run agile team. Cards moved through a Linear board: Backlog → In Progress → In Review → Demo → Done. Weekly cycles, one operator, one product.

What changed was execution capacity underneath.

Cards were executed by a harness of five Claude Code agent roles, each mapped to a specific surface with hard boundaries — with me as the sixth seat, the human Operator:

• Sys (Architect) — authors canon and drafts cards, never runs feature cards or merges feature PRs.
• Board (Engineering Manager) — dispatches cards to agents, vets PRs, merges to staging. Never merges to main. Never authors canon.
• Agent(n) (Engineer) — implements only within files listed on the card. Never picks its own cards. Never merges PRs.
• X (QA Engineer) — executes verification cards deterministically. Never expands scope, never introduces abstractions.
• Chat (Business Analyst) — read-only status queries.
• Operator (Product Owner) — me, the human. Apex authority on every decision, sole owner of Demo → Done transitions and all release cuts.

Every card requires a Card Completion Brief before handoff. Every PR passes through a Verify CI gate: typecheck ratchet, lint, tests, build, migration lint, layer parity. Release governance is codified in an eight-step process from staging verification through post-tag deploy verification.

Governing scope inside expanding work

A sprint typically starts with about 15 planned cards. During execution, agents surface adjacent work — a security issue, an infra fix, a UX gap discovered in an unrelated flow — that's out of scope for the current card but genuinely needed. A three-tier action gate governs the response: Tier 1 (inline fix, under 15 minutes) gets absorbed into the current PR; Tier 2 (related but distinct) allows amendment with a strict cap; Tier 3 (unrelated or large) files a new card and escalates to a Drift Log I review as Operator.

One sprint planned 12 Coach Pulse accountability cards and shipped 20+ once mid-work drift was formalized as its own work stream.

The PO's job shifted with the workflow. Instead of protecting scope by keeping the sprint tight, the work became governing what the agents did inside expanding scope — making sure every card that got added still traced back to the roadmap, still passed the doctrine, still shipped through the same acceptance criteria.

Current state

Pre-launch, in active development. The v3.0.0 milestone is explicitly reserved for public relaunch. Current sprints are closing out Coach Pulse Phase D — completing the remaining drawer patterns and routing — and preparing the accountability loop for launch readiness.

What I learned

The role harness was the highest-leverage decision on the project.

I initially expected agents would need continuous human oversight per card. In practice, the constraints are the oversight. An agent that can't pick its own cards, can't merge its own PRs, and can only touch files listed on the card produces predictable, reviewable work. The "file new card for drift" rule alone prevented dozens of scope-creep PRs. Judgment gets applied at the card-specification gate and the PR-review gate — not continuously during implementation. That's the entire reason the workflow ships good code instead of a lot of code.

I would formalize the behavioral laws earlier.

The five-tier deterministic pipeline that classifies behavior, computes trends, gates escalation, constrains output, and controls tone was codified after significant feature work had already shipped. Earlier features were built on implicit assumptions about how the system should respond to user behavior. When the laws were codified, several features needed retroactive alignment — not full rewrites, but adjustments to match the now-explicit rules. In a rules-driven system, formalize the rules before building the features, even when the rules feel premature. Premature formalization is cheaper than retroactive alignment.