Thirteen questions,
answered against the repo.

Built on the structure of your July investor-demo runbook, re-cut for a diligence audience. The order matters: earn the architecture conversation by showing the thing work first.

The chain is real, and it runs in two halves that were only recently joined. Walk it in order:

• Setup — facilitator adds a client and a workshop through a 3-step wizard; pre-work uploads land in R2. Shipped and live.
• Capture — the in-room recorder cuts audio into ~45-second self-contained segments, writes each to on-device storage before any network attempt, and uploads to R2 in parallel. The device keeps its copy until the server acknowledges a matching hash. A session can complete with zero connectivity and upload afterward. Shipped, with real transcription running.
• Submit — segments are reconciled (expected vs received, contiguous sequence) before transcription can be submitted at all. Then batched Whisper on the full session — deliberately not real-time, because late-session discussion routinely flips an earlier conclusion.
• Run — submission writes a run; the bridge on the Hetzner box claims it and executes a sandboxed claude -p session. Worker → bridge → Claude → done is verified live.
• Strategy dashboard — same evening.
• Flywheel — a Python orchestrator runs seven chained Claude sessions (1 → 2a‖2b → 3 → 4 → 5a → 5b), fanning out to roughly fifty agents across the skill library, doing live research and image generation, into its own per-client repo and Pages project. Several hours. The host deploys the finished showcase outside the sandbox.

This is their sharpest question and it has a clean answer, because the line is deliberate rather than accidental. Three tiers:

1 · Production software. Real code, versioned, migrated, tested, auto-deployed.

• Facilitator platform — Cloudflare Worker with static assets, D1 (14 tables, native wrangler migrations), R2, Better Auth across Google / Microsoft / email+password, row-level tenant scoping, Playwright browser E2E, push-to-main auto-deploy.
• The bridge — FastAPI service on Hetzner, SQLite job queue in WAL mode, asyncio worker with concurrency limits, systemd-managed, per-client bubblewrap sandbox, bearer-token auth, full log per job.
• Dashboard shells — the v7 and v8 templates: real front-end code with a 165-assertion end-to-end suite green against production on v8.
• Deterministic Python — the build orchestrator, the data validators, the schema validators, the smoke-render test, the asset builders, the summary generators.

2 · The engine — orchestrated skills, agents, and prompts. Roughly 98 skills and 91 agents, the meta-orchestrator, the eight-phase workshop skill set, the Flywheel build pipeline. This is the irreplaceable IP and it is deliberately not rewritten as conventional software. The architecture spec states the reasoning: re-platforming the orchestrator onto an SDK means re-validating the entire workshop and moving onto metered billing at the same time. That's a considered later-phase decision, not a prerequisite.

3 · The boundaries, which is what they're really asking:

• Engine ↔ platform — the platform's only jobs are capture reliably, queue a run, watch it, host the deliverables. The orchestrator is lifted verbatim as a portable prompt-and-config bundle. The platform does not know what a workshop is.
• Pipeline ↔ dashboards — the pipeline writes JSON and assets; the dashboard shell is a template that renders that JSON. The shell is template, the JSON is data. Clients do not get bespoke shells, which is why one front end serves dental, youth sports performance, sports software, and home services without a fork.

Tenancy is enforced at three layers, and the honest framing is that they're different mechanisms — say which is which.

• Data — row-level. Every row carries a tenant id; every query is filtered by the tenant derived from the authenticated principal. Cross-tenant reads are impossible by construction rather than by convention. This was verified adversarially: an independent agent attempted cross-tenant access, ID enumeration, injection, and path traversal against the live schema, and all were blocked.
• Compute — process-level. This is the strong part. Every client build runs inside a bubblewrap sandbox with a per-client filesystem and network policy. Reads are denied across the operator home, the service directories, and root, then re-opened only for that client's own repo. Writes are denied everywhere except that client's paths. Network is default-deny with an explicit domain allowlist — the strategy build reaches one domain; the marketing build reaches an enumerated research and image list, because the sandbox refuses a wildcard by design.
• Delivery — multi-tenant hosting. A new deliverable is a new storage prefix and a database row, never a new hosting project. Project count stays flat as client count grows.

Across industries: industry variance lives in the client JSON and the knowledge base, not in code. The evidence is that the same shell ships across four unrelated verticals with no fork.

Across facilitators: facilitators are users scoped to a tenant who own their own clients and workshops; integrators are cross-tenant staff in a reserved staff tenant. Roles are assigned once at first sign-in, are never settable by the client, and the system is deny-by-default — an email that is neither on the integrator allowlist nor holding a pending invite cannot create an account at all.

Lead with the correction, not the number. Earlier financial drafts assumed a subscription token pool as a roughly ten-fold cost arbitrage and produced a 92% subscription margin. That arbitrage is prohibited under Anthropic's terms as of April 2026 — verified. The hardened strategy re-baselined every cost line onto compliant metered infrastructure and dropped the headline to ~80–88%, explicitly labelled measured-not-assumed, with instrumenting one real build registered as a kill-gate before any margin number gets quoted externally.

What the unit math looks like today, stated as estimates:

• Flywheel build: roughly 30–45M tokens, flagged medium confidence. At blended metered pricing that's a few hundred dollars of model cost per build — not the twenty-five to fifty the old pool math implied.
• Ongoing production per client at the top tier: roughly 25–40M tokens a month.
• The dominant cost is not tokens. It's six to ten hours of integrator time monitoring and rescuing each build. Infrastructure is about fifteen dollars a build and thirty-five a month per active client. Anyone who models this as a compute business is modeling the wrong line.

The cost firewall that does hold: bring-your-own-key on the Harness is inviolable. A flat seat price cannot cover unbounded agentic usage, so the client pays their own inference. That converts the most compute-intensive product into the highest-margin one. The real path to better economics on LEVR-run delivery is a negotiated commercial volume agreement, not arbitrage.

Failure modes — the designed answer. The spec is genuinely strong here, and it's worth walking:

• A crash resumes from the last completed job checkpoint. Completed work is reused from storage, so an hour-six crash costs minutes, not hours.
• A stale heartbeat is the catch-all stall detector — it catches hangs that no specific error class would.
• Job failures retry with bounded attempts and backoff; retries are idempotent at the job level.
• Token expiry is checked every thirty seconds mid-run, and expiry pauses the run rather than letting it silently produce garbage.
• Quota exhaustion pauses and pages a human. There is no silent fallback to metered billing — ever, by design.
• Strategy and knowledge base are never auto-edited. The agent proposes a diff and the run pauses until a human approves.
• A twenty-event controlled vocabulary drives everything: the integrator console and the facilitator's progress bar are pure projections of that event stream. There is no second source of truth for what is happening.

Own the dependency rather than hedging it. The engine runs headless on Claude Code. That is load-bearing and deliberate — it's what makes a seven-to-nine-hour autonomous build possible at all today.

What multi-model means concretely, right now — separate three things:

• Routed today. Image generation already routes across nine providers behind one interface with a spend gate. Transcription runs across three depending on the path. These are real, in production, and provider-swapped without touching the pipeline.
• Proven buildable. A provider-routing proxy runs in production on your own machine, transparently serving one model tier from a different vendor entirely. The routing layer isn't a slide — it exists.
• Designed for, not yet built. The Harness is specified multi-model with bring-your-own-key across vendors.
• Not portable. The workshop orchestrator itself. Swapping it is a re-validation project, not a config change. Say that plainly.

On the labs shipping adjacent capability — the right answer ranks the moat honestly, from most to least durable:

• The accumulated client knowledge bases and the outcome dataset. The stated identity is a data company, not a software company. Every engagement enriches a corpus no lab can see.
• The accredited operator network. Supply-gated, slow to copy, and contractually locked — equity and profit-share with vesting, non-solicit, and company-owned demand generation, engineered before recruiting scales.
• The methodology — assigned to the company, with the room and the facilitator as the delivery mechanism. A lab does not sit an executive team in a room.
• The prompt and skill library. Real, valuable, and the most erodible layer — it gets cheaper to rebuild every year.

The posture that follows: use the labs as ingredients, own the positioning, the governance, and the network.

There are four named gates, and one of them has a receipt worth bringing.

1 · Human approval on strategy and knowledge base is a non-negotiable invariant. Never auto-edited. The agent proposes a diff; the run pauses until a human approves. Three gate tiers — deterministic, model-judged, and integrator.

2 · Deterministic validators run inside the build. Schema validation, data validation, a render smoke test, a 165-assertion end-to-end suite, cross-reference validation, broken-asset gates, and brand-conformance greps. These are code. They don't have opinions.

3 · The source-provenance pass — this is the specific answer to their question about statistics. Every claim on a client-facing page is mapped to claim, figure, source, method, confidence tier. The pass mandates a "softest numbers" section where the agent volunteers its own weakest figures, and an "unbacked claims" section for anything it cannot trace. Inventing a citation to fill a gap is explicitly forbidden. Links are validated deterministically — extracted and fetched in parallel, then bucketed into live, bot-blocked, and genuinely dead — not eyeballed by a model. Financial models get two tables, inputs versus derived projections, with a mandatory "breaks if…" column on every projection.

4 · A humanization gate on every client-facing prose surface before publish, and adversarial verification — independent verifier agents grade each platform milestone against an honest rubric rather than the builder marking its own homework.

This is your strongest technical answer. Do it live, not on a slide.

• Isolation at rest — row-level tenant scoping, adversarially verified against cross-tenant access, ID enumeration, injection, and path traversal.
• Isolation at compute — the per-client sandbox described in question 3. Add the defense-in-depth detail: the sandbox always blocks writes to shell profiles, git hooks, and tool config even inside otherwise-writable paths, so a session cannot rewrite its own configuration to escalate later. The stored operator credentials file is explicitly unreadable, so a build authenticates only through the token injected for that job.
• Deploy credentials live outside the sandbox. The host performs the publish step; no hosting or repository credentials are ever exposed to a model-driven session. That boundary is deliberate and worth naming — it's the one that matters most in an agentic system.
• Auth and access — federated sign-in, roles fixed at account creation and never client-settable, deny-by-default, and adding an email to the allowlist does not promote an account that already exists.
• Recordings — treated as the one irreplaceable artifact. Two independent durable copies, hash-acknowledged before the device releases its own, and a reconciliation gate that must pass before transcription can even be submitted.
• Client share links — scoped, revocable capability tokens, not a password mailed around. Staff access is separately authenticated.
• Secrets — mode-600 on the box, owned by the service user, never baked into machine images, pulled at boot; platform secrets held in the hosting provider's secret store.
• Audit — every integrator intervention is logged with before-and-after state; the event stream is append-only.

What a non-Chad facilitator needs today. Four of five things exist:

• The Calibration Day agenda — the deployed day-arc is the contract, not a suggestion.
• The facilitator playbook — twelve written chapters covering the mandate, the philosophy of the room, the models, running the day, the objection playbook, the sales motion, the accreditation path, and the platform relationship.
• An auto-generated prep brief on the client, plus a fresh competitor scan the morning of.
• A permanently assigned integrator who guarantees the build and rescues technical failure, so a facilitator is never alone with a technical problem.
• Missing: the ability to run the build without Claude Code fluency. That is exactly what milestone 5 removes, and until it lands, a non-technical facilitator runs the room but cannot run the machine alone.

The designed ramp — shadow to lead over four workshops. Chad sources and leads the first at roughly seventy percent while the recruit actively co-facilitates; the second is about sixty percent the recruit; the third and fourth the recruit sources and leads. Splits climb 60/40 → 70/30 → 80/20, with no upfront training fee — deliberate, because a fee deters the ex-CEO calibre the model depends on. Accreditation is the assigned integrator's sign-off after three to four clean workshops with no major delivery issues. The reference model is EOS.

Answer the maturity question with a capability gate, not a date. The gate is: a non-technical facilitator can deliver a workshop end-to-end without touching a terminal. That is the v0 definition in the engineering roadmap, and three milestones close it — the real orchestrator stages behind the button, the integrator console with intervention, and tokenized deliverable publishing. Four of seven milestones are done.

Recruiting can start ahead of that gate, and should. The first workshop of every ramp is co-facilitated with Chad and the integrator carries the build regardless — so cohort recruiting and shadow workshops are not blocked by the platform. What should be gated on v0 is the first solo workshop, because that's the first one where a facilitator is alone with the machine.

The training program already exists in written form — the twelve-chapter playbook is the curriculum, and the four-workshop ramp is the practicum. Recruiting channel is in motion too: a ~50-agency network operator is being courted to run regional recruiting events in California, Colorado, and Boston that double as training seminars, with facilitators paying to attend and break-even considered fine.

Start with the uncomfortable finding, because it drove real product decisions. The CEO is probably never going to look at the dashboard. That's Chad's own read, and rather than argue with it, the product moved: toward a feed of virtual-employee cards showing what each is producing and what's queued, an approve-first workflow, and a briefed voice agent the executive team can talk to instead of a dashboard they have to visit. As the framing goes — the marketing manager becomes the person who approves the AI's work.

Skills required on the customer end: none technical to consume. What's required is one accountable approver. The pattern that works in production today is a named approver who holds the publish authority plus role-scoped reviewers who can move content but not publish — established at onboarding, not discovered later.

Who provides support: the integrator, not the facilitator. That's a designed line, not an accident. The facilitator owns the room and the relationship; the integrator owns the machine. It's what makes the 80/20 split honest — the facilitator keeps the larger share because they carry the harder, less scalable thing. As LEVR scales, this becomes the integrator team, which is why integrator leverage is the top engineering theme rather than a nice-to-have.

Adoption friction already paid for and engineered against: a client rework taught the lesson that brand rules and deliverable expectations must be captured before the build, so onboarding gained a voice-agent step that surfaces both up front.

Screen-share this table as-is. It's the artifact that answers the question fastest.

Sequencing. v0 — one non-technical facilitator delivers one real workshop terminal-free. v1 — many facilitators and recurring revenue: an operator console across roughly twenty concurrent runs, per-stage checkpoint and resume, stale-run alerting, the subscription, and elastic compute. v2 — self-serve scale with humans handling exceptions only.

Who's writing code now. Two people: you on the platform and the pipeline, and Ben on the bridge, the box, and the build package. An engineering offer is out at roughly a quarter point, with the first build being the infrastructure for virtual employees.

Two roles, board-authorized, and the reasoning matters more than the titles: a non-founder technical integrator and an integrator-leverage engineer. The rationale on the record is that the integrators-per-facilitator ratio is the revenue ceiling, and it currently sits on a founder's shoulders. Those two hires attack the number one bottleneck and the number one key-person risk with the same move.

In motion: an engineering offer out at roughly a quarter point over five years, first build being the virtual-employee infrastructure. A revenue leader at about a point, with a live operator-experience concern and a named local alternative who exits his current role in roughly three months. The role specs and a technical roadmap written specifically for candidate screening already exist and are shareable.

The one sentence to close on: the Year-3 model is gated by technical-integrator capacity and recruiting — not token cost, not facilitator recruiting, not capital. Every engineering priority in the plan exists to raise the number of concurrent builds one integrator can safely carry.

Two instruments, deliberately. An assignment schedule for what the company owns outright, and a contributed-IP license for what a founder keeps and the company runs under a perpetual, irrevocable, worldwide, royalty-free, sublicensable and transferable license that survives termination — with a grant-back of improvements.

Assigned to the company: the positioning workshop and its dashboard; the go-to-market dashboard — built solely by you and assigned outright; the weekly pulse; the underlying methodology and workshop literature (assigned via the entity that holds them); the workshop skill set; the seven visual models; the facilitator agent; the dashboard application and the product implementation; the book and the interview films.

Licensed, not assigned: the reusable agent engine — the general-purpose skill library, sub-agents, prompt libraries, tooling, and the meta-orchestration pattern — plus the voice-agent app and the connector patterns, both narrow-scope. It's deliberately namespaced so ownership is never ambiguous.

Why that shape, said plainly: the company owns everything it sells. The general-purpose engine underneath is licensed so the company can operate without owning a founder's entire livelihood. Investors get clean ownership of the products plus a perpetual irrevocable license on the layer beneath.

Client IP versus platform IP — the hard split, and it's a locked decision: the client owns the produced strategic and content assets, fully exportable as a self-contained archive. LEVR keeps the prompts, the engine, the architecture, the skills, and the intelligence layer. It's reinforced by the identity: the dashboards and assets are the client's snapshot, built once and theirs to keep, while the continuously-enriched data layer is the company's. That's what makes the handoff honest and what makes this a data business rather than an agency.