SculptAI

Most training software is organized around producing a plan: you answer some questions, the product hands back a program, and from then on the program is the fixed thing and you are the variable. Keeping the two aligned becomes the user's job. That transfer is the problem, because almost everything the plan depended on is in motion from the day it is written.

• Goals change, and so does their order — someone who set out to lose fat now cares about their shoulders.
• Training activity diverges from the schedule: sessions get done early, late, partially, or not at all.
• Missed work is information, and it is what a static plan is least equipped to use — nothing happened, so nothing triggered.
• Recovery is uneven: the same prescribed volume is easy one week and too much the next.
• Nutrition drifts independently of training; the plan's assumptions about it do not.
• Measurements, photographs and check-ins accumulate, and the picture they form is the real answer to 'is this working'.
• Consistency is a signal in itself — four near-perfect weeks and four half-attended ones should not produce the same next month.

The thesis

A training plan should be a response to signals, not a document the user is asked to obey.

That imposes three structural requirements. The plan has to be a function of current state rather than a stored artifact. Absence has to be representable, because a system that only listens for actions cannot notice the week in which nothing happened — the week an adaptive product most needs to react to. And the adaptation has to be legible: a product that changes what it asks of someone has to be able to say what it is now focusing on.

Each signal has a defined entry point, and the architecture declares how far it travels.

Goals, in the user's words

Captured at onboarding, re-openable later. Goal Profile normalizes raw goal text, focus areas and constraints into a profile the planner consumes.

Goal priorities

Structured fields, not prose: the Framework Registry consumes a primary goal key and priority areas, so a change of emphasis reshapes the week.

Training activity

Completing a workout is a declared event, defined by an inserted workout log row, that propagates rather than terminating at the write.

Missed workouts

An expected training day passing with no workout log is its own declared event, with its own propagation.

Nutrition

Meal logging is a third declared event; Nutrition is one of five top-level domains, and nutrition targets are declared outputs of the prescription engine.

Recovery

Recovery targets and rules are prescription-engine outputs: an input to what is asked of the user, not a note beside the plan.

Consistency

Derived state, not a streak counter: recovery, consistency and recent impacts are builders other surfaces read from.

Measurements and photographs

Baseline photos, food, water and a daily check-in are Journey checklist items — how the product asks for the evidence it reasons over.

Progress evidence

Scored per-region muscle health with an explicit next focus: where the system's conclusion becomes visible to the person it applies to.

Those parts are not one pipeline. Atlas — the internal architecture map covered in section 05 — decomposes the product into five domains with engines beneath them, so a signal like nutrition is not locked inside the screen that collects it.

Expand — open full-resolution capture

Five tabs carry the product — Journey, Coach, Plan, Progress and Library — with Gym Mode reachable from anywhere. The surface that matters most is used mid-session, standing in a gym: there, anything that needs a paragraph read or a decision the product could have made is a defect, however reasonable it looks in a mockup.

Gym Mode

The in-session surface: set counters, elapsed and remaining time, an exercise pager, start and end movement blueprints, and an 'Equipment busy? Swap exercise' escape hatch.

Plan

The week as the planner produced it: one composed title per day, rest days left open, and a regenerate action on the surface rather than in settings.

Journey

The daily surface: the goal in the user's own words, a current-versus-future body view, and the day's checklist.

Progress

Derived state: 'Objective signals — no guesswork about how it's going.' Muscle health is scored per region with a specific 'Focus next' list.

Expand — open full-resolution capture

Expand — open full-resolution capture

Expand — open full-resolution capture

Expand — open full-resolution capture

Expand — open full-resolution capture

Expand — open full-resolution capture

The asset pipeline behind the exercise library+

The exercise library is produced by an import pipeline, because a catalog that grows with the product cannot depend on manual asset production. The import screen is the whole interface: a start photo and an end photo go in, and SculptAI names the movement, tags the musculature and renders the blueprint card the library shows. Each movement carries male and female views behind a toggle. Production cost is treated as an architectural constraint rather than an afterthought, and the resulting trade-off is stated to the user on the import screen itself rather than hidden behind it.

Expand — open full-resolution capture

Account, settings and beta gating+

The sign-in screen at the top of this page is framed by what an account gives the user: save workouts, view history, pick up from previous weights. Settings groups appearance, plan structure, feedback straight to the founder, account controls and a legal hub, with the build stamped in the footer.

Expand — open full-resolution capture

Section 02 described the loop in the abstract. Here it is traced through the running product. Every quoted string below is text visible in a capture on this page.

Steps five and six quote the same string, character for character — and the words it is built from are the categories Goal Prescription declares it owns.

It holds in the other direction too: a meaningful action is not a private transaction between one screen and one table, but a named event whose reach the registry declares.

Expand — open full-resolution capture

An expected training day that passes with nothing logged is itself an event, with four ripple steps of its own. Not doing the thing is modeled as information.

Anchoring an event to a checkable state change rather than to a button handler is what makes the event testable — and it makes absence representable, the second of the three requirements in section 01.

Where the event registry says how far something travels, the dependency graph says along which edges: what each engine reads, emits, and who is downstream.

Expand — open full-resolution capture

Everything above is behavior; Atlas is where the same product is described as a system. It is internal tooling, built at the point where reading the code stopped being a fast enough way to answer why something happened.

Expand — open full-resolution capture

World Map

Five domains — Experience, Intelligence, Nutrition, Planning, Transformation — and their engines.

Health Overview

The summary view, with the counts below.

Engine Registry

One stated responsibility and a self-declared status per engine.

Event Registry

Each event defined by the state change that constitutes it, with its ripple-step count.

Dependency Graph

Per-engine contracts: consumes, produces, consumers.

Ownership Graph

Accountability boundaries. In the navigation; not among these captures.

Connectivity Graph

Confirmed gaps and unverified assumptions, ranked by severity.

Every engine states one responsibility and a status, so an engine that has quietly grown a second job shows up as a description that no longer fits.

Expand — open full-resolution capture

The view that turned out to matter most is the one I expected least of: the connectivity view, where Atlas records confirmed defects and unverified assumptions ranked by severity. It currently holds five entries — two confirmed defects, one migration that was applied but never backfilled, and two relationships whose only content is that they were not checked this pass. Each names the surface it affects and says plainly what is known and what is not.

Those entries are why the Coach tab is not presented as a feature anywhere on this page, and why the beta invitation flow is described as unfinished. The tool is doing its job when it makes a claim harder to make.

SculptAI carries two pieces of validation tooling inside the application, both kept out of the ordinary user experience: a behavioral evidence harness gated to development builds, and a manual smoke checklist for a new account behind an admin-only tools route.

Expand — open full-resolution capture

The harness is the part I would point an engineer at. Each test captures a real server snapshot, performs a live mutation scoped to the operator's own records, refetches the queries the UI uses, and reports before and after. Mock fallbacks are flagged in red rather than silently substituted — a green run that had fallen back to fixtures would be worse than no run at all.

• The loops are named after behavior, not modules: Workout Completion, Missed Workout, Daily Check-In, Meal / Protein, Muscle Health Score, Wins, Workout Session, Core & Mobility.
• Query Invalidation is a loop in its own right: an adaptive product most often looks broken while being correct underneath.
• Theme Safety is there too, because a rendering regression that makes a screen unreadable is a product failure whatever caused it.
• The smoke checklist covers what the harness cannot: a genuinely new sign-up, the beta gate, the legal hub, and intake persisting a profile.

Expand — open full-resolution capture

A product heading into a beta needs somewhere to answer operational questions — is anything down, who has been invited, who is actually in. SculptAI has that surface built in, under the name Cockpit, described on the screen itself as a place to “operate SculptAI as a live business — monitor users, growth, health & operations.”

Expand — open full-resolution capture

System status

Server health, database, API, storage and background jobs, each reported independently rather than as one aggregate green light, and stamped with the build.

Beta invitations

Issuing and redeeming invitations, so admitting a tester is an operational action rather than a database edit. Section 05 records an open defect behind this flow, so it is a surface that exists rather than a finished one.

User management

Per-user administration — what makes it possible to answer a beta tester's support message without opening a console.

Activity feed

A running view of what is happening in the product: the operational counterpart to the event model in section 04.

Operating a product asks questions on a different axis from building one, and answering them by hand does not scale past the first days of a beta. An operational action with no home in the Cockpit is one that will end up being performed unsafely.

I hold sole technical ownership of SculptAI: product strategy, architecture, implementation, validation and operations. There is no engineering team behind it. Every decision on this page is one I made and can defend — including the ones I would make differently now.

Product design

Framing the problem as adaptation rather than plan generation, deciding what the product asks for and what it infers, and drawing the line between shipped and unfinished.

UX and UI

The mobile-first surface, the five-tab structure, and the in-session design of Gym Mode — the subtractive decisions that come from designing for a busy gym floor.

System architecture

The engine decomposition, the event model, the declared contracts between engines, and the choice to model absence as a first-class event.

Implementation

The interfaces, the application logic, the generation pipeline behind the exercise library, and the internal tooling in Atlas and the Cockpit.

AI systems design

Deciding what the product infers versus what it asks, where model-driven behavior is allowed to act on a user's plan, and what it must declare when it does.

Engineering method

AI accelerates exploration and implementation in my work, and I keep responsibility for the result: the architecture is mine, I review the source, and behavior has to survive automated tests, live-data validation and visual QA before it counts as working.

Testing and validation

Identifying the behavioral loops worth verifying, building the harness that exercises them against live data, and writing the release smoke checklist.

Product operations

The Cockpit: system status, invitation control, user administration and an activity feed — the operational surface a live product needs on day one.

The interesting failures in an adaptive product live between disciplines. A missed workout is at once a data-model question, an interface question, and a question about how it feels to be told your plan has changed.

When one person holds the whole system, the architecture has to carry the institutional memory. That is why the map, the contracts and the harness exist as products in their own right.

SculptAI is in active development and beta preparation. The build shown throughout stamps itself v1-beta-rc-1; the surfaces around it — beta gate, invitation flow, legal hub, smoke checklist — are the work of getting a first group of real users in.

• Built and demonstrable: the onboarding-to-plan chain, the weekly split, Gym Mode, Progress, the exercise library and its generation pipeline, Atlas, the evidence harness, the smoke checklist and the Cockpit.
• In progress: closing the gaps the connectivity graph records, and running the seventeen loops and eighteen smoke checks to completion against the release candidate.
• Explicitly not shipped: Coach, whose backing data store SculptAI's own tooling records as absent from production.
• Outcome metrics — users, retention, revenue, latency — are not claimed here; the product has not met a cohort yet.

What this demonstrates is the discipline that produces business results: framing a problem, decomposing it into a system, building the software and the tooling that keeps that system inspectable, defining what would count as proof, and being precise, in public, about which parts are finished.