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 (Continuous Integration) 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 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 28 weeks, came from a delivery model built for the purpose: traditional agile ceremonies on top, a CH(Ai)SE governance harness underneath. 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.

The system operates under seven defined roles across portfolio and project scopes:

• Operator (Product Owner): the sole human seat. Final decision-maker for product scope, acceptance, and all release cuts.
• Chaise (Portfolio Manager / Methodology Owner): cross-project coordination, methodology ownership, and canon authorship. Does not run per-project ceremonies or feature cards.
• Sys (Project Architect): per-project governance, one per project at every tier. System design, card grooming, and sprint ceremonies. Operates in three activation modes: Starter (sprint kickoff, grooming, planning), Steward (mid-sprint scope tracking), and Closer (sprint review, release ceremony, the staging-to-main merge, and the Verifying → Done sweep). Never runs feature cards or merges feature PRs.
• Board (Engineering Manager): dispatches cards to agents, vets PRs, merges to staging. Its own seat, one per project, not one the Operator fills. Never authors canon.
• Agent(n) (Engineer): implements only within files listed on the card. Card-level validation mode (strict/standard) controls execution rigor. Never picks its own cards. Never merges PRs.
• Tester (Verification): exercises every acceptance criterion on staging through runtime pathways. A verification walk is structural, not optional. The Tester confirms the feature works as specified before any card moves to merge.
• Counsel (Portfolio Review): look-overs, research, and lineage judgment, invoked by the Operator. Read-only. Returns findings, never decisions, and holds a required review gate on canon changes.

Every card requires a Card Completion Brief before handoff, and a formal verification doctrine requires a runtime walk of the change (not just a code review) before it's marked done. Every PR runs six automated CI gates: lint, web typecheck, mobile typecheck, mobile bundle, a Vercel preview build, and a custom schema-drift detector that automatically catches prod/staging divergence, phantom columns, upsert conflict targets, ledger drift, and reference-data drift. Release governance is codified in an eight-step process from staging verification through post-tag deploy, producing 68 tagged releases at a roughly weekly cadence.

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 reviewed by the 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 and early signal

In private beta and active development: production-ready, not yet publicly launched. The v3.0.0 milestone is explicitly reserved for public relaunch. Small numbers, but real signal:

Takeaways

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

The initial assumption was that 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.

The behavioral laws should have been formalized 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.