The building blocks behind the Custodian platform: what talks to what, where the engine sits, and where the data lives.
The Custodian runs as a multi-tenant platform on three services: a single Cloudflare Worker for delivery and execution, Supabase for persistent storage, and the Anthropic API for reasoning. The platform passed through three earlier deployment forms — a local proxy, Netlify functions (abandoned over execution timeouts), and Cloudflare Pages — before consolidating into one Worker, custodian-v2, that serves the interface and handles every request.
The architecture follows one governing principle: everything of consequence passes through a single chokepoint. The browser holds no intelligence, no secrets, and no direct line to the database or the reasoning engine. The Worker mediates all of it. This is not an implementation convenience. The Custodian's value rests on a constitution that does not drift toward the founder's framing, and that holds only if the constitution is injected server-side, beyond the founder's reach, on every request. The chokepoint is what makes the constitutional guarantee enforceable rather than aspirational.
The system has four layers. At the top sit the clients: each founder opens a dedicated session at /f/{slug} — Mobideo at /f/mobideo, Irrevio at /f/irrevio — and the operator opens the admin panel for onboarding new founders and updating the Custodian centrally. Both are interfaces only: they render state and send requests, nothing more.
The second layer is the Worker itself, and its consolidation is the structural change from the platform's earlier form. Where the Pages deployment split static files from a serverless function, custodian-v2 is one deployed unit that serves the founder dashboard per tenant, handles every API route — decisions, signals, profile updates, document uploads, admin operations — and is the only component permitted to read the environment secrets: the Anthropic API key, the Supabase credentials, and the admin key, all set through Wrangler and never sent to the browser. That single fact draws the system's trust boundary: everything above the Worker is untrusted client territory; everything the Worker holds is privileged.
The third and fourth layers are the engine and the memory. The engine is a pair: the Worker's API routes are the body, and the Anthropic API — carrying the Custodian constitution as its system prompt — is the mind. The memory is Supabase, which now holds five kinds of record per founder: the session identity, the uploaded documents injected into every exchange, the decision archive with its full conversation threads, the signal log, and the Living Company Profile. Alongside founder data sits the config table containing the constitution itself, the CRIP definitions, interface text, and design tokens. Because the system's governing content lives in data rather than code, what the Custodian is can be revised centrally, without redeploying the Worker.
The structure above is static. What matters at runtime is the path a single decision travels — and where, on that path, the constitution enters.
The founder enters a decision from their dashboard. The Worker receives it and assembles the full reasoning context from Supabase: the constitution and CRIP definitions from the config table, plus the founder's Living Company Profile, uploaded documents, and prior decisions. With that context attached, it calls the Anthropic API — the constitution as the system prompt, the founder's framing as the user input, in that order of authority. The response is written to the decision archive and returned to the dashboard, where each decision is a permanent, reopenable record: the founder can return to any archived decision and continue the conversation in its original thread, with full history intact.
Two additions complete the loop. After every response, the Custodian proposes an update to the Living Company Profile in editable fields that the founder approves — the system's structural picture of the company is revised in the same breath as the decision that changed it. And founders retain control of their record: signals and decisions can be deleted, each deletion removing the entry and its full conversation.
Decisions are episodic; reality is continuous. The Signal Log is the organ that closes that gap. A founder observes something between formal decisions — a customer says something unexpected, a competitor moves, an institutional actor changes behaviour — and drops it into the log as one or two sentences of observable fact. Not a decision, not a question.
The Signal Log gives the platform a second runtime path with the same constitutional discipline as the first. The classification call travels the same route as a decision — through the Worker, with the constitution and the current profile attached — so the same instrument that examines decisions examines the signals arriving between them. The result is that the Living Company Profile stays current continuously, not just at decision moments, and the founder dashboard reads top to bottom as the company's structural state: Living Company Profile, then Signal Log, then Decision Archive.
Four properties fall out of the design. First, isolation: each founder's session is a separate record set keyed by slug, so tenants share the platform but not each other's reality — Mobideo and Irrevio run side by side without contact. Second, constitutional integrity: the governing prompt lives in privileged storage and enters every request from the server, never from the client. Third, continuity of record: decisions persist as reopenable threads and signals as a chronological archive, so the causal history of the company accumulates rather than evaporating between sessions. Fourth, revisability without redeployment: constitution, CRIPs, interface text, and design tokens are data in the config table, so the Custodian can be amended centrally while the deployed Worker stays untouched.
The known limits are equally plain. The admin panel is protected by a single shared key, which is adequate for a one-operator pre-seed platform and inadequate beyond it. Tenant isolation is enforced by the Worker's queries rather than by database-level row security — sufficient while the Worker is the only client of the database, worth hardening before it is not. And the platform runs on a workers.dev address pending a custom domain.