Architecture principles

Four principles are applied consistently across every LEVR system: a thin edge control plane, a separate execution plane, deterministic logic wherever a deterministic answer exists, and a structural human gate before anything reaches a client.

Shared primitives across products

• Tenant identifier on every row, with tenant-prefixed indices and a tenant-scoped data access layer.
• Append-only audit and event logs.
• Redundant capture on anything that cannot be re-recorded.
• Tokenised capability URLs for one-off external access.
• A shared skill and agent library reused across the marketing pipeline, the harness, and the routines.
• A voice interface and an MCP surface on the systems that need machine-to-machine access.

Application portfolio

Eight production systems. Each entry gives function, stack, hosting, measured usage, and data architecture. All usage figures were read from live systems on 20 August 2026.

1. LEVR Platform — the commercial core

The facilitator sells the engagement, runs the one-day session, and records it on an iPhone. Audio uploads in chunks, is transcribed, and drives the agentic build that produces the strategy dashboard the same day and the go-to-market dashboard within 48 hours. An integrator observes every run. The design goal is that a non-technical facilitator runs the entire pipeline from a browser and a phone.

Stack

npm workspaces monorepo on Node 22. Four Cloudflare Workers: auth (Hono, Better Auth with OAuth provider, Kysely over D1, JOSE — issues OAuth tokens and publishes JWKS), clients-api (owns client and workshop schema, verifies JWTs via JWKS over a service binding), pipeline (cron- and queue-driven, no public hostname, consumes the speech-to-text queue), and web (Vite 8 + Alpine.js 3.15 + Tailwind 4.3, static-assets Worker proxying the auth and platform APIs behind an httpOnly refresh cookie).

Mobile

Expo 57 / React Native 0.86 / React 19.2 / TypeScript. iOS only, target 16.4, background audio mode enabled. Local SQLite, secure storage, notifications, over-the-air updates.

Legacy generation

Still live. Single Cloudflare Worker with static assets, Hono, Better Auth, Zod, Playwright end-to-end tests. Browser MediaRecorder → IndexedDB → object storage capture path.

Hosting

LEVR corporate Cloudflare account (created 5 August 2026) on the levr.live zone. Two D1 databases, two R2 buckets, a speech-to-text queue with a dead-letter queue (batch 10, 3 retries), one-minute cron, and Cloudflare Secrets Store for third-party credentials. Mobile ships through EAS to TestFlight.

Measured usage

Legacy database, which holds every real engagement to date: 6 tenants, 8 users, 23 clients, 23 workshops, 26 runs, 43 recordings, 32 transcripts, 1,323 run events — 1,557 rows / 2.90 MB. Rebuilt platform: 213 rows in the client database (3 clients, 3 workshops), 104 rows in the auth database (3 users), 57 audio objects / 9.96 MB.

Data architecture

Two D1 databases with ownership split by convention and enforced by an invariant test. Auth database: 16 tables, 12 migrations. Client database: 12 tables (clients, workshops, chunks, submissions, audit log, heartbeat, orgs, grants, invites, issues, pre-work), 12 migrations. Audio chunks in object storage; transcripts in the database. Table names carry the owning database as a prefix.

Availability

No contracted SLA, no status page, no external uptime monitoring. Live probes on the day of writing: JWKS 200 in 0.25–0.52s, API health 200 in 0.21–0.35s, admin surface 200 in 0.33s.

Engineering

216 commits on the rebuild since 13 August 2026 (Tom 198, Ben 18); 146 mobile commits (Tom); 99 on the legacy generation (Ben 83, Chase 15).

2. LEVR Bridge — the agentic execution runtime

A job API that runs an agent in a per-client sandbox scoped to that client's repository. It produces the strategy dashboard (capped at roughly one hour) and the full marketing showcase build (a seven-session pipeline with a 16-hour timeout).

Stack

Python 3.11, FastAPI, Pydantic, 19 pinned dependencies, 1,608 lines across 10 modules, SQLite in WAL mode. Agent runs in a bubblewrap sandbox via Anthropic's sandbox runtime. Provisioning calls the source-control API to create a private repository per client and the hosting API to create a deployment project per client. Vendored: the marketing pipeline bundle (98 skills, 93 agent definitions) and the dashboard template.

Hosting

Hetzner CX33 (4 vCPU / 8 GB / 80 GB), Ubuntu 24.04, Nuremberg, backups on, €9.99/month. Bound to loopback only; public access exclusively through a named Cloudflare tunnel with a bearer token. Health probe 200 in 0.84s.

Concurrency limits

Three concurrent jobs maximum; marketing builds take a single global lock; agent loops are bounded by turn caps (15 default, 150 ceiling) and hard timeouts (1 hour / 16 hours).

Measured usage

171 jobs total: 145 completed, 26 failed — 84.8% success. By type: 91 dashboard, 67 ad-hoc marketing, 13 full marketing. 28 distinct client slugs, including test and smoke runs. Range 10 June to 11 August 2026.

Data

A single SQLite jobs table. On boot, in-flight jobs are re-marked failed; the deploy process drains the queue first. Client output lives in per-client repositories and deployment projects, with per-job logs retained.

Engineering

179 commits — Ben 152 (~85%), Tom 7, Chase the remainder. Single-maintainer system today.

3. LEVR Loops — multi-tenant content platform

A weekly agentic routine drafts on-brand social content into a brand-themed approval queue. Approved on-strategy work publishes directly to Instagram and Facebook through a third-party publishing API. Off-strategy work requires a Slack card, a tokenised approval page, and a PIN held by a named person at the client.

Stack

Cloudflare Pages in Advanced Mode with a hand-written ES-module worker — no framework, no npm dependencies; the worker entry point is 227 lines. Front end is Alpine.js and Tailwind. Cloudflare Workers AI provides Llama 3.3 70B for strategy-alignment scoring (publish threshold 0.6) and LLaVA for media tagging. Integrations: publishing API (publish and OAuth connect), Slack, transactional email. One additional publishing adapter is a stub. The weekly producer is a headless agent plus Python on the execution plane.

Hosting

Cloudflare Pages with D1, R2, KV sessions, and Workers AI. Access is gated by Cloudflare Access email OTP, with three bypass applications protected by service tokens or HMAC. Producer runs on a Monday 08:00 cron.

Measured usage

1 tenant, 4 users, 255 media items, 38 content moves, 4 publications — 385 rows / 422 KB. 255 objects / 70.86 MB in storage. 10 weekly runs between 28 June and 10 August 2026. The mechanism is proven; commercial usage has not begun.

Data architecture

10 tables, tenant identifier on every row, 14 tenant-prefixed indices, an 841-line tenant-scoped data layer. The decisions table is append-only and serves as the canon training signal. There is no public publish route — the gate is structural rather than enforced in application logic.

Engineering

Single contributor. The local working tree is file-synced rather than version-controlled; moving it into source control is an open item. A second engineer is designated as secondary owner.

4. GTM Dashboard platform (Flywheel)

The client-facing deliverable. One shared Alpine shell renders both the asset dashboard (cards with drill-down) and the strategy dashboard. Python builders emit JSON content packs; the shell renders them.

Stack

Vanilla JavaScript with a vendored copy of Alpine, no build step. Shell: 2,027 lines of HTML, 4,869 lines of JavaScript, 9,245 lines of CSS. Nine Python builders using the standard library only. QA harness in Playwright (2,402 lines). An audio Worker streams ElevenLabs text-to-speech with an object-store cache — 2.72s cold, 0.35s cached.

Hosting

Cloudflare Pages, one project per client instance, deployed from the client's content folder. Live instances respond 200 in 0.29–0.35s.

Measured usage

Three live instances across two clients (asset and strategy dashboards for one, strategy for the other). None of the dashboards carry web analytics. The QA harness reports full passes; a documented discrepancy between the reported assertion count and the source is flagged internally as unverified and is under review.

Data architecture

There is no database; the data plane is JSON content packs per instance against a defined strategy contract with nine block primitives, plus per-client manifests. The settled direction (19 August 2026) is object storage as the default data plane behind an authenticated API proxy.

Engineering

Repository created 17 August 2026 as a handoff package to the incoming full-stack engineer. One contributor to date.

5. LEVR Agent Harness — customer agentic teams

A customer's marketing team receives an AI agent preloaded with a curated go-to-market execution library, deployed and maintained by LEVR.

Stack

An open-source coding agent on Node 22, running GLM-5.2 through a flat-rate coding plan. 53 curated skills and 43 subagent definitions converted to the harness format. A custom skill-router keeps the system prompt to roughly one line instead of loading 30,000–50,000 tokens of skill definitions. Web extraction via a third-party crawler.

Hosting

Dedicated Hetzner CX23 created 14 August 2026, €6.49/month. Hardened: root SSH disabled, key-only authentication, host firewall, fail2ban, named sudo with I/O logging.

Measured usage

Zero customer deployments. This is a reference deployment. The remaining blocker is a missing crawler API key on the box.

Security position

High-blast-radius credentials are deliberately kept off customer agent boxes, on the basis that anything reachable by the agent is exfiltratable by prompt injection. Model identity is pinned, because the underlying model otherwise self-reports incorrectly.

6. Knowledge-Base MCP and site editors

The knowledge-base MCP server exposes a per-client marketing corpus to the client's own AI tools. The site editors are MCP edit connectors: propose → preview → promote, with strategy-affecting changes routed to a named human approver.

Stack

Knowledge base: Cloudflare Worker, TypeScript, MCP SDK, Workers OAuth provider, Hono, Zod, and one Durable Object — the only Durable Object in the estate. Site editors: git-backed through the source-control API against the deployment project, with a Workers AI model acting as a strategy-change classifier alongside a deterministic zone lock. Slack and transactional email for approver routing.

Measured usage

2 corpora with per-corpus bearer tokens, 118 objects / 3.82 MB, 2 client sites, 1 named approver. Live probes 200 in 0.22–0.39s. Per-endpoint call counts are not available — no request analytics are enabled.

7. Walk-and-Talk — voice companion

A voice agent for executive input and deliverable feedback: a brief is handed off, the conversation runs over WebRTC, and the transcript is distilled back into the workflow. Multi-tenant with per-user and per-location siloing since 28 July 2026. This is the candidate backend for the dashboard voice agent.

Stack

Cloudflare Pages PWA in Advanced Mode. OpenAI realtime voice over WebRTC plus whisper for transcription. Capacitor 8 iOS shell with remote loading and native push. A companion editor extension with 58 tests.

Measured usage

The highest-volume system in the estate: 5,537 messages, 128 conversations, 5 users, 1 tenant, 577 objects / 132.97 MB. Usage is overwhelmingly internal founding-team usage rather than customer usage.

Known issue and remediation

The committed schema had drifted from the live database by two tables and eight columns — evidence of past hand-applied production schema changes. Remediated with regenerated migrations and a deprecation banner on the stale file. The current platform prevents the same class of drift with migration-only schema changes.

8. Weekly Pulse — market intelligence routine

A Monday re-scan of the client's market — competitors, search, AI-answer visibility, voice of customer, legal, social — producing a deterministic week-over-week delta, trend stories, battle cards, and an audio brief into the client dashboard.

Stack

A headless agent bounded at 200 turns, plus 23 deterministic Python scripts. The diff computation is pure Python — the model never counts deltas. Signal sources are plugins with per-client YAML configuration validated against a JSON schema. Data sources: a SEO/SERP API covering AI answers across ChatGPT, Gemini, Perplexity and AI Overviews; a crawler; a Reddit archive API; review sites. Audio via ElevenLabs; notifications via Discord and email. Three validators plus a blocking humanisation gate.

Hosting

Dedicated Hetzner CX23, Monday 07:00 UTC cron. Output is preview-only by default; promotion to production is manual. Host uptime 111 days.

Measured usage

29 scheduled runs plus 21 manual runs, continuous from 8 June to 17 August 2026 with no gaps. 21 published editions. One paying client on the routine.

Platform inventory and capabilities

What exists

A microservice edge architecture: four Cloudflare Workers communicating over HTTP and service bindings, an execution plane reached through a Cloudflare tunnel, and MCP servers as the machine-to-machine surface. Managed primitives in use: Workers, D1, R2, KV, Queues with a dead-letter queue, one Durable Object, Workers AI, Access, Secrets Store, and Tunnel. Authentication is OAuth 2.0 with JWTs verified against published JWKS, with a separate OAuth client per surface.

What does not exist

There is no enterprise data warehouse, data lake, ETL platform, or BI layer, and no message bus beyond Cloudflare Queues. There is no relational server database, cache tier, or search cluster in the estate — the data layer is D1, R2, KV, Queues, one Durable Object, and per-host SQLite. These are deliberate omissions at current scale rather than gaps under remediation.

Production data footprint, 20 August 2026

Client deliverables live in per-client repositories and deployment projects alongside a synced content vault. The largest single repository is 235 MB.

Development methodology

Languages and platform choices

Testing

2,620 automated test cases run on the two newest codebases.

Coverage is uneven across the estate, and this is stated plainly:

Environments

Production only. There is no staging environment. This is written into the repository and asserted by an invariant test so it cannot be assumed away. Local development is complete — a single boot command brings the whole platform up and proves health.

Staging is designed and approved in an architecture decision record: durable but expendable, promoting an exact SHA-pinned artifact, backward-compatible migrations only, human-initiated promotion. It is blocked on a paid source-control organisation tier, which is also what blocks branch protection.

Continuous integration

Platform and mobile run credential-free CI on every push and pull request — the pipeline needs no secrets, so a fork or an untrusted branch cannot exfiltrate anything. 76 platform CI runs at 87% success; 32 mobile runs. The execution runtime has a deploy workflow but no CI test job. Dashboards, content platform, Pulse, and the voice product have no CI.

Source control: a single organisation created 25 June 2026, 12 private repositories, 4 members, conventional commits. 30 pull requests on the platform and 16 on mobile.

Deploy pipeline and controls

Three deploy controls worth naming

• Preflight probes every resource the deploy token must see before anything is written, so a scope error fails before it does damage rather than halfway through.
• The smoke gate asserts behaviour with no credentials. It proves the JWKS is usable, that an unauthenticated call returns a 401 with the correct body — which proves the middleware is actually in the path — and that the web surface serves and proxies.
• There is no rollback step, by design. The model is fix-forward with idempotent deploys and migrations. Because branch protection is unavailable on the current source-control tier, deploys are workflow-dispatch-only and a test fails the build if a push trigger reappears. Restoring push-to-deploy requires the paid tier first.

Planning system

There is no Jira or Linear. The system of record is a structured vault repository (263 commits, created 11 August 2026) holding 461 tasks each with a priority and a test contract, 138 lessons, 86 decisions, 37 specs, 54 session records, 13 architecture decision records, and 4 area profiles — kept in both Markdown and JSON. Specs carry acceptance criteria and checkpoints, and work follows a blocking verification step before implementation begins.

Limitation: the system is roughly one month old and largely reflects one engineer's practice. Whether it survives a larger team is not yet demonstrated.

Infrastructure and operations

Fleet

LEVR owns no data centres; all compute is Cloudflare's managed edge plus four Hetzner servers, all in Nuremberg, all Ubuntu 24.04, all with backups enabled.

High availability and disaster recovery — current state

• The server tier has no high-availability layer. No load balancers, floating IPs, private networks, or attached volumes; no cloud firewalls configured; delete protection off. The execution runtime being loopback-bound behind a tunnel limits exposure but provides no redundancy — if that host is down, builds stop.
• The Cloudflare tier is genuinely distributed and managed, so the client-facing surfaces do not share that single-host exposure.
• No documented DR plan, no RPO or RTO, no rehearsed restore. Point-in-time recovery on the edge database is unconfirmed, and no object-storage lifecycle policy has been verified on the workshop audio bucket.
• Planned close: an open P1 task assigns backup and retention ownership and requires a rehearsed restore of one complete workshop.

Account consolidation

The LEVR corporate Cloudflare account was created on 5 August 2026 and now holds the platform (1 Pages project, 5 Workers, 3 D1 databases, 3 R2 buckets, 2 queues). A second account, used through the pre-incorporation build phase, still holds most client-facing deliverable sites (60 Pages projects, 8 Workers, 4 D1, 7 R2, 18 KV, 1 Durable Object, 8 zones). Migrating those onto the corporate account is a scheduled cleanup item. A near-duplicate copy of the legacy platform database exists on both accounts and is reconciled as part of the same work.

Monitoring — current state

Cost base

Infrastructure cost is trivially low: €29.46/month of servers, effectively zero Cloudflare spend (free zone, pay-as-you-go object storage at negligible volume), and AI subscriptions. What matters for modelling is the shape rather than the amount.

Today the AI execution layer runs on subscription-based Claude Code authentication, which sets a quota ceiling rather than a spend ceiling. This is recorded as a High risk in the platform specification. Migration to metered API access is planned, and unit-economics modelling has already been re-baselined onto metered pricing. Cost-threshold environment variables and a run-log convention exist today; there is no cloud budget alerting.

Scalability

The edge tier auto-scales. The constraint is the execution plane: three concurrent builds per host and a single global lock on full marketing builds. The queue architecture settled on 19 August 2026 addresses this — a job queue feeding a worker fleet, where concurrency equals worker count, with a pluggable agent harness and QA and destination modelled as finite interface sets. It is designed with named milestones and an owner; it is not yet built.

Data flows and quality controls

Processing schedules

Data intake

Audio arrives as standard audio MIME types (m4a, mp3, wav, webm, ogg); browser capture produces webm, mp4, or ogg, with iOS emitting mp4-encoded audio under an m4a filename. Transcripts are plain text or Markdown. Pre-work documents, decks, and logos are accepted without a MIME allowlist. Content media are images. Knowledge-base sources arrive as JSON in three recognised formats. Strategy sources are Markdown or JSON compiled into the database.

Gaps stated plainly: there are no upload size limits and no antivirus scanning on uploads today. Both are open items.

Collection software

LEVR-built: the workshop recorder including locked-screen capture, the voice companion, transcript ingestion, the pre-work uploader, the research agent swarm, 23 Pulse collectors with four signal plugins, moments ingestion, the site-editor MCP, and the connector MCP with per-user OAuth and an audit trail.

Third-party: speech-to-text and realtime voice, a web crawler, a SEO/SERP data provider, a Reddit archive API, a social publishing API, a website platform API, Slack, an edge access gateway, and an authentication library.

Quality controls, in order of application

AI model usage and data policy

Position

LEVR trains no models and owns no weights. Every model in use is third-party hosted and used zero-shot or few-shot with retrieved context. What LEVR owns is the layer above the models: the skill and agent library, the evaluation rubrics, and the encoded strategy graph.

Models in use

Execution-layer authentication. The build execution layer runs on subscription-based Claude Code authentication today. Migration to metered API access is planned, and cost modelling has been re-baselined onto metered pricing.

Vendor selection includes a data-terms review. One low-cost provider was declined on trust and data-terms grounds despite a cost advantage of roughly 19–29× on the relevant workload.

Customer data and training

• No customer data is used to train any model. LEVR does not train, fine-tune, or contribute data to model training.
• Per-client tenant isolation is enforced at the data layer — tenant identifier on every row, tenant-scoped access layer, tenant-prefixed indices.
• Learning happens at the prompt and canon level only. When a client approves or rejects a piece of work, that decision is written to an append-only decisions log and shapes future prompts for that client. It does not update model weights and does not cross tenants.
• Open item: formal vendor documentation of customer-data-in-training terms is being assembled into a published policy. The retention terms of the primary model API are tracked internally.

Retention, ownership and export

Stated gap: there is no published formal retention policy or set of TTLs yet, and no executed DPA template or published sub-processor list. Formal data-protection documentation is an active workstream. Consent enforcement for end-customer contact data is deliberately left with the client.

AI quality controls

The three-tier gate (deterministic → independent judge → human), provenance gates on research inputs, bounded agent loops with turn caps and timeouts, and cost caps. The governance evaluation itself contains no model in the decision path: it is deterministic, and where the system is uncertain it widens constraints rather than narrowing them.

Security posture and maturity roadmap

No security incident, breach, or notification has ever occurred. No penetration test has ever been performed. Both statements are true and both matter.

What is in place

• OAuth 2.0 with JWT verification against published JWKS; a separate OAuth client per surface; httpOnly refresh cookies on the web surface.
• Deny-by-default authorisation. Roles are never client-settable.
• Tenant isolation enforced at the data-access layer rather than at the query site.
• Cloudflare Access in front of internal and client approval surfaces, with bypass applications protected by service tokens or HMAC.
• Credentials held in Cloudflare Secrets Store for the platform; credential-free CI so pipelines cannot leak secrets; a preflight credential gate on deploy.
• Servers hardened: root SSH disabled, key-only authentication, host firewall, fail2ban, named sudo with I/O logging.
• The execution runtime is loopback-bound and reachable only through an authenticated tunnel; agents run in per-client sandboxes scoped to that client's repository.
• High-blast-radius credentials are deliberately kept off customer-facing agent boxes.
• Append-only audit logs across every surface.

Gaps, stated plainly, with planned closes

Engineering team and operating model

A four-person technology organisation, three of whom write code.

What the org does not have

There is no dedicated DevOps, QA, production support, client support, security, or data function, and no on-call rotation; at current scale these responsibilities are carried by the three engineers.

Key-person concentration

This is the principal technical risk and it is not obscured. The execution runtime is roughly 85% one engineer; the rebuilt platform is roughly 92% one engineer who started 11 days ago; everything else is effectively single-author. Mitigations in motion:

• A senior full-stack hire is in market with an approximately 45-day timeline.
• The dashboard platform was packaged into a dedicated handoff repository on 17 August 2026 specifically to move it off single ownership.
• A second owner is designated on the content platform.
• The new engineer's month-one exit criterion is stated explicitly: Chase is no longer the only person who can touch the platform in production.
• The vault planning system exists in large part to make one engineer's context transferable.

Incident history and technical debt

Material production incidents

None involved customer data or a security breach. Each is listed with the structural fix it produced, because the fixes are the point.

Technical debt register

This register is maintained in the repositories themselves and is reproduced here in full rather than summarised.