BBBB
Internal · Admin/Engine pinned to v0.4.0

The BBB Method,
explained end-to-end.

The methodology, the engine, and the platform — what each one is, why it exists, and how they fit together. Read this top to bottom to understand the whole system; jump to the 28-day cycle validator to see it run against any client profile.

Run the 28-day cycleRead the explainer first
The why

Philosophy

Every engine number traces back to Ben's first principles. Read this before anything mechanical.

The Hypertrophy Equation
Tension×Volume×FrequencyRecovery Cost

Every engine number traces back here. Volume is scaling; Frequency is density. The denominator decides how much of the numerator the body can actually convert into tissue.

Seven pillars

The whole methodology, on one face.

Train with intent. Recover with discipline. Eat with purpose. Each pillar maps to engine mechanics — the methodology articles in 00-philosophy/ spell out which.

Tension

Mechanical load on the target muscle. The cellular trigger for growth.

Control

Tempo + range. Convert load into productive tension instead of momentum.

Recruitment

Mind–muscle connection. The trainable skill that makes the target do the work.

Fatigue

Effective reps (0–3 RIR). The on-8 Set Score threshold codifies it.

Recovery

Per-muscle recovery windows. The denominator of the Hypertrophy Equation.

Progressive Overload

Seven levers: execution > load > reps > sets > range > tempo > density.

Consistency

Same stimulus, repeated. Staple exercises across years; variation within structure.

The shape

System architecture

Three layers, one direction of flow. Methodology defines what; engine computes; platform delivers.

Layer 1 · spec

Methodology

built-by-ben/methodology

The canonical source of truth. Every article in this repo is what the engine is supposed to do. Edits flow through methodology PRs; auto-sync mirrors them into platform.

D-decisions63Spec articles40+Canonical tagv0.18.0
  • 00-philosophy/ — Ben's first-principles articles (11)
  • 01-engine-pipeline/ — the 12 stages, spec-side
  • 02-reference-systems/ — exDB, equipment, variants
  • 05-governance/ — audit-trail · era archives · CHANGELOG
git subtree auto-syncmethodology release → repository_dispatch → platform PR (labeled methodology-sync)
Layer 2 · compute

Engine

bbb-platform · lib/engine/

Twelve pure-function stages. Same inputs always produce the same outputs. The engine pins itself to a methodology version; tests pin engine outputs against canonical fixtures.

Pinned tov0.4.0Stages0 → 12Tests998
  • stages/ — one file per stage · pure (input) → output
  • tables/ — tbl_* lookup data (exDB, focus, equipment presets)
  • fixtures/ — canonical sample clients pinned to methodology §5
  • __tests__/ — per-stage + per-D-decision + integration
server action callapp/(admin)/methodology/_actions/run-cycle-action.ts → runPipeline()
Layer 3 · surface

Platform

bbb-platform · app/ + components/

Next.js 16 App Router. Three rendering tiers project from the same methodology: public (marketing), subscriber (in-app coaching), internal (this validator + admin tools).

FrameworkNext 16Tiers3AuthSupabase
  • lib/methodology/public.ts — marketing pages (access_tier: public)
  • lib/methodology/subscriber.ts — in-app coaching (gated)
  • ai/methodology-loader.ts — prompt-cached "Ask Ben" chatbot
  • Supabase · Stripe · Cloudflare R2 + Stream · Resend
Methodology lives separately

Code-canonical here. Methodology-canonical at built-by-ben/methodology. The subtree at methodology/ is read-only — edits flow back through the methodology repo.

Persistence is Supabase

Postgres + RLS. Per-client equipment profile, admin exclusion list, intake notes, session history. Engine is persistence-agnostic; it reads ClientProfileInput from whatever loads it.

Three access tiers

access_tier frontmatter on every methodology article decides which renderer projects it: public marketing, gated subscriber, or internal-only.

The compute

Engine pipeline

Five phases, twelve stages — each one produces something concrete you can inspect inside the validator. Read it top to bottom like a coaching journey.

Client profile in━━━━━━━5 phases · 12 stages━━━━━━━Rendered session out
Phase 1 of 5

Intake

Tell us who the client is.

Stage0
Inputs

21-field client profile validated end-to-end.

Example out
James · 28 · 175 lb · intermediate · PPL · 4 days/wk · cut
Phase 2 of 5

Read the client

Figure out where they are physically + where they're heading.

Stage1
Derive

Body comp, energy, volume scalar, where they are in the phase cycle.

Example out
BMI 25.1 · TDEE 2,840 cal · AdjVol 1.08 · Phase: Build (3/4)
Stage2
Align

Match the goal × experience to the right rep scheme.

Example out
Hypertrophy aligned · rep source: 6–10 with top-set + AMRAP
Stage3
Split

Pick the training split — honor the client's preference if it fits the frequency.

Example out
PPL chosen · valid for 4 days/wk · preference honored
Phase 3 of 5

Set the week

What training shape fits today.

Stage4
Focus

Pick today's focus from 19 internal IDs × 4 variant rotations = 76 structures.

Example out
Today: Push · variant A · primary: Chest, Front Delts, Triceps
Stage5
Budget

Per-muscle monthly volume target driven by AdjVol + frequency.

Example out
Chest 14 sets/mo · Quads 12 · Shoulders 8 · Calves 6 ...
Stage6
Active

How many slots actually fire today — clamp(4, 8).

Example out
6 active slots · derived from monthly total 380
Phase 4 of 5

Pick the work

Which exercises actually fire today, and what comes next.

Stage7
Select

Cluster lookup → equipment + admin exclusion filter (D62) → variant filter → ordinal pick → coach override.

Example out
Bench Press · Incline DB Press · Cable Fly · Lateral Raise · ...
Stage8
Cycle

Rotate focus across sessions · D30 pairing across the 4-week cycle.

Example out
Next: Pull · variant A · cycle pos 1/6 · pair: Deadlift ↔ Quad-Emphasis
Phase 5 of 5

Build the session

Sets, reps, loads — what the client actually sees.

Stage9
Sets

Allocate working sets per slot via D13 / D17 / D22 rules.

Example out
Bench 5×6 · Incline DB 4×8 · Fly 3×12 · LR 3×12-15 · ...
loops
Stage11
Memory

Accumulate effective sets per muscle; advance the phase when ready.

Example out
Chest +12 effective sets · advance Chest to Peak next week
Stage12
Render

Final session card — set-by-set table, totals, per-muscle accumulator.

Example out
24 working sets · 38.5 session difficulty · ready for client
Feedback loop

Stage 11 (Memory) feeds Phase 2 on the next session. Phase advances automatically when every muscle hits its weekly minimum — Base → Build → Peak → Deload.

In and out

One client, end-to-end

The same sample client runs through every test we ship. Here are the real inputs and what Stage 12 actually returns.

What goes in

The 21-field client profile

One real intake — the canonical sample client from lib/engine/fixtures/sample-client.ts. Every downstream stage reads from this shape; the schema doubles as the contract for the subscriber-facing intake form.

Personal
name
Sample Client
age
32
sex
Male
height
5′ 10″
weight
185 lb
body fat
18%
Fitness profile
experience
Intermediate
current freq
3/wk
goal freq
4/wk
goal
Build Muscle
split
Push/Pull/Legs
Priorities
weak 1
Back
weak 2
Quads
strong
Chest
Lifestyle
activity
Moderate
nutrition phase
Maintenance
Leg emphasis
legEmphasis
Both
Calendar
mode
FallWhereTheyFall
static days
—
Optional 1RMs
squat
—
bench
—
deadlift
—
Preference flag
biceps_double_iso
false
Plus three constraint domains (D62)

What Ben knows about this client

The engine doesn't try to model coaching judgment. It accepts structured constraints from Ben + the client and applies them at Stage 7 Step 0c.

Domain 1

Equipment availability

Tier preset (bodyweight_only / home_gym / apartment_gym / commercial_gym) + per-implement overrides + quantitative caps (max DB lbs, max plate inventory).

Domain 2

Admin exclusions

Per-client list of exercise IDs to drop from the candidate pool. Set by Ben on the onboarding Zoom (injuries, preferences, equipment edge cases collapsed into structured decisions).

Domain 3

Free-text intake notes

Client's own words. Collapses into Domain 2 via Ben's judgment — Ben IS the rules engine for coaching nuance. The engine never parses free text.

What comes out

Engine output for the same client

All values below are computed live by runPipeline() against the sample client. Refresh and the page re-runs the full 12-stage pipeline — no fixtures, no drift.

Stage 1 · Derived profile
BMI26.5Overweight
BF classBalanced
BMR1795cal/day
TDEE2782cal/day
AdjVol0.879scalar
DistributionBalanced
PhaseBasecycle 1
Phase progress0%
Age cap0.925
Exp mod1.00
Start %0.95
Nut mult1.00
Stages 4-12 · Today's prescriptioncycle pos 1 · variant A
Push(4 active slots)
1Barbell Bench Pressbig-3
4 working sets
2Machine Shoulder Press
3 working sets
3Cable Chest Fly
3 working sets
4Dumbbell Lateral Raise
4 working sets
+ 1 more slots in the rendered session
Working sets
17
Effective sets
18.5
Session difficulty
2272.0
Working difficulty
1522.0
From their seat

What the subscriber experiences

One 28-day cycle from signup to phase boundary. Ben enters the flow exactly once.

End-user journey · one 28-day cycle

Subscriber

What the paying client experiences from signup through one full monthly phase. Ben enters the flow once (the onboarding Zoom). The engine does everything else.

  1. Step 1 / 8

    Sign up

    builtbyben.com

    Public marketing site → email + payment intent. Subscriber tier unlocked on Stripe confirmation.

  2. Step 2 / 8

    Subscribe

    Stripe

    Embedded Checkout → customer record at app layer (clean separation from Supabase Auth identity).

  3. Step 3 / 8

    Intake form

    21 fields · D62 domains

    Personal + fitness + priorities + equipment toggles + free-text notes. Saved as ClientIntakeInput in Supabase.

  4. Step 4 / 8

    Onboarding Zoom

    Ben · once

    Ben reviews intake live. Converts free-text notes + injury history into structured admin exclusions.

  5. Step 5 / 8

    First session prescribed

    runPipeline()

    Engine fires Stage 0-12 with empty history. Returns Stage 12 rendered session — slots, sets, reps, loads.

  6. Step 6 / 8

    Daily session loop

    Stage 8b · 28 days

    Each day, Stage 8b decides train-or-rest. If train, runPipeline returns today's session. Client logs reps + difficulty.

  7. Step 7 / 8

    Phase advancement

    Stage 11 · breadth-gated

    When ALL 14 muscles hit their weekly_min, Stage 11 advances Base → Build → Peak → Deload automatically.

  8. Step 8 / 8

    Next cycle

    month-over-month

    Phase progression resets at Deload completion; per-muscle volume budget recalibrates for the next 28-day arc.

From Ben's seat

How the coaching + methodology loops work

Two lanes: the daily per-client loop, and the methodology-evolution loop that keeps the spec moving forward.

Admin lane 1 · Ben's daily loop

Per-client coaching

What Ben does between intake and the next intake. The engine doesn't replace coaching — it operationalizes Ben's decisions so every client gets the same standard of care.

  1. Step 1 / 4

    Review intake

    Read the 21-field profile + the free-text notes before the Zoom. Build mental model of the client.

  2. Step 2 / 4

    Set admin exclusions

    D62 Domain 2

    Decisions from the Zoom converted into structured exercise-ID exclusions. Stored per-client in Supabase.

  3. Step 3 / 4

    Monitor sessions

    session history

    Watch how the prescribed sessions are landing. Effective sets per muscle, phase progress, difficulty trend.

  4. Step 4 / 4

    Adjust per-client

    Coach Overrides

    If a client needs deviation from the engine default, push a Coach Override (slot-level exercise swap, variant E).

Admin lane 2 · the spec moves forward

Methodology evolution

When Ben surfaces a new architectural decision (a D-number), it goes through methodology before it ever touches engine code. Two repos, one direction of flow.

  1. Step 1 / 6

    Ben raises a question

    Coaching observation or methodology gap. Logged for the next Ben↔Josh sync.

  2. Step 2 / 6

    Josh writes the spec

    audit-trail.md

    New D-decision authored in built-by-ben/methodology. Reasoning + resolution + downstream cascade.

  3. Step 3 / 6

    Methodology PR

    revision:

    PR merges into methodology main. semantic-release tags it (v0.18.0 → v0.18.1 / v0.19.0).

  4. Step 4 / 6

    Auto-sync to platform

    git subtree

    repository_dispatch fires platform's methodology-sync workflow. Squashed subtree PR opens automatically.

  5. Step 5 / 6

    Engine adapts

    METHODOLOGY_VERSION

    Engine code change (if any) lands in a follow-up PR against the synced spec. METHODOLOGY_VERSION pin advances.

  6. Step 6 / 6

    Tests pin the contract

    998 tests

    Per-stage snapshots + D-decision tests pin the new behavior against canonical fixtures. CI enforces.

Now run it

See the full monthly cycle for any client.

The cycle validator iterates Stage 8b across 28 days and runs the full pipeline for every train day. Click into any session to see the rendered card + derived profile + coach internals.

Open cycle validator
Engine pin v0.4.060 exercises in catalog19 focus IDs × 4 variants = 76 structures63 D-decisions resolved998 tests passing