SUPERSEDED BY A RULING, 2026-09-14 — the same day this was written, and the reasoning stands. Travis registered `locu.systems` and ruled that §6a of this document — locus hosting — is the direction, not a later phase.
90_LOCUS_HOSTING.mdis the record. Phase one below is not being built: there is no weekly website health report, no customer zero, no billing connector. This document is banded rather than rewritten. Rewriting it would fabricate a design review nobody performed, and the argument in it — that the service package is the commercial object, that cancellation is a lifecycle rather than an invoice event, that a signed record proves issuance and not correctness — is why the ruling had something to rule on. Read §6a first; it became the direction. Read the rest as the case that was made against it.
Version: 0.1 Status: Direction record and pilot plan. `spec` rung. Nothing below is implemented. Audience: Engineering, and whoever runs the first pilot Decided: 2026-09-14, by Travis, in a planning conversation; written here the same day. Not yet entered in the root REVISION_REGISTER.md; that entry is the ruling, this file is the record.
What this supersedes, and what it keeps. The v1 specification set in this folder describes an agent deployment control plane whose unit is the agent. This record changes the unit to the service package a customer buys. It keeps, by reference, the parts of v1 that still apply: the normalized API envelope and idempotency rules (
10_API_CONTRACTS.md), the Runtime Provider Interface as the shape of a runtime connector (20_RUNTIME_PROVIDER_INTERFACE.md), the secrets posture (40_SECURITY_SECRETS_COMPLIANCE.md), and the entitlement and limit-enforcement algorithms (50_OBSERVABILITY_BILLING_LIMITS.md). The data-layer half of v1 is superseded already; see the banner onREADME.md. Nothing in this record depends on the shared Supabase instance.
Service management for agent businesses. An operator sells a recurring, agent-powered service to a customer, and WebHost.Systems connects the thing the customer bought to everything that has to be true for it to be delivered and paid for, across the hosting, runtime, model and billing systems the operator already uses:
purchased promise → permitted work → provider execution → delivery record → customer chargeShorthand, for talking to hosting operators: "WHMCS for agents." WHMCS is a trademark of its owner; the phrase describes the shape, not an affiliation.
What it is not: a host. Compute for agents is a commodity sold by many vendors at nearly the same rate; running the agent is the provider's job, and this product does not compete for it. Nothing on this domain executes a customer's workload.
Every package describes:
| Field | Meaning |
|---|---|
| Promise | What the customer receives, how often, in what form |
| Requirements | Which providers, tools and credentials the service needs |
| Lifecycle | How it is provisioned, updated, paused, resumed and retired |
| Economics | Price, included allowance, internal budget, overage rule |
| Permissions | Which actions run without asking and which need approval |
| Evidence | What counts as delivery and how it is recorded |
Two distinctions the object must preserve:
Provider cost is not customer billing. A failed run costs the operator money and is not
billable to the customer. Both facts are kept.
Cancellation is a lifecycle, not an invoice event. Cancelling means: stop new work, finish or
cancel queued work, revoke access, keep exports for the agreed period, then remove resources. An invoice being cancelled does none of that by itself.
| Reusable capability | First implementation |
|---|---|
| Package definition | Weekly website health report |
| Service enrollment | A customer's selected public URLs |
| Scheduling and execution | Run the defined checks on a schedule |
| Allowance and cost tracking | Account for checks, retries and delivery |
| Delivery record | Store the report and the delivery outcome |
| Cancellation | Stop future scheduled work; apply the retention policy |
Website checks are one package module. The product is the table's left column.
Read-only, on purpose. Every check runs against public URLs. The package holds no customer credentials, changes nothing on a customer's site, and needs no recovery procedure. Maintenance that changes a website is a later package, and it waits until permissions and recovery are proved.
Checks (deterministic; the report is templated; a model-written explanation is added only where it improves the report enough to justify its cost):
reachability and response time, from more than one location
certificate validity and expiry
DNS records as they currently resolve
broken links on the pages the customer named
what changed since the previous run
Allowance. A fixed number of URLs and checks per week, stated in the package. A run that would exceed it stops and says so in the report. Overage is a separate line, never silent.
Evidence standard. Promise repeatable checks, not identical results: a site changes over time and behaves differently by location, and re-running a check tomorrow cannot prove what happened yesterday. So each report preserves
the observation time,
the check version,
the relevant response data,
the calculation or rule that produced each conclusion.
A customer can inspect how a conclusion was reached and run the same check again to see the current state. A signed record proves who issued it and that it has not changed since; it does not prove the work was correct, and no report may imply that a signature does.
Confidentiality scope. Public URLs do not make the customer relationship public. Customer emails, purchased services, payment references, and the association between a customer and a website are private, and a single operator can serve several customers. Customer records stay private. Only deliberately selected statistics of our own operation are published. A file ledger still needs access control, backups and a retention policy, stated before customer zero.
Runtime. Scheduled checks run on Cloudflare Workers cron triggers — the portfolio's ruled provider, on its free tier — with the RPI as the connector's shape. Nothing else is chosen.
Billing. The first billing connection is the simplest one that reports a purchase: Stripe Checkout with a webhook, or a free open-source billing panel. WHMCS is the second connector, added when an operator who uses it pilots; its module verbs (create, suspend, unsuspend, terminate, change package, renew, usage update) are the lifecycle vocabulary the connector port is designed against, and a WHMCS development license requires a paid WHMCS license first.
Customer zero. One complete reporting cycle against our own sites. Record execution costs,
retries, false alarms, delivery failures and human intervention time. This establishes that the pipeline works and gives a first cost measurement. It is a baseline, not a pricing study: one cycle cannot show support cost, unusual failures or willingness to pay.
A small paid pilot. The same package offered to a few paying customers at an explicit
introductory price, over the simplest billing connection. Paid renewals are what establish commercial value.
The next integration is whatever the first external operator needs.
An existing billing system reports a purchase.
WebHost.Systems provisions or assigns the service.
An external runtime performs the scheduled work.
The system records completion, failures and attributable costs.
The customer receives a useful report.
Cancellation stops future work and follows the retention policy.
The marketing page at / is generated from records/surface.json and is gated. It states the direction, the first package, the acceptance test, what is in the tree at which rung, and what is not built. It claims no rung the portfolio nav has not recorded.
A public page for the first operator — spend, deliveries, revenue, human interventions — is a view generated from the operating records, not a separate product. It is built after customer zero has produced records to view, and it publishes only selected statistics.
Status: a drawing, gated on things that do not exist. Nothing below is scheduled.
Phase one sells a service package and runs its work on whatever runtime the operator already has. Phase two makes the runtime ours: the thing a customer buys is a locus — the ComputeDriven unit that carries state, its granted authority, and continuity across restarts — and the thing they are metered on is admitted transitions, the steps the world actually took. The machine underneath is a carrier: rented, replaceable, and never the customer's identity.
The vocabulary is not invented here. Each word has a published pattern, and the console links them: active-locus, locus-is-not-its-carrier, identity-is-a-seal, progress-over-utilization, carrier-confinement, carrier-multiplexing, progress-aware-placement.
Why it is worth drawing now. Every host in the survey of 2026-09-13 bills utilization or vCPU-hours. Billing admitted transitions instead is a claim about what the customer's money buys, and it is one this portfolio has spent a year building the machinery to make good on. It is also the only reading of this domain under which the portfolio nav's word for it — the runtime layer — is literally true.
`/console/` is that drawing. A working prototype of the operator console and the client portal, served from this repository, marked a prototype in a banner that cannot be dismissed, running against a seeded sample fleet in the visitor's own browser. It connects to nothing. Four things in it are worth keeping whatever ships first, and phase one should adopt them:
| Taken from the prototype | Why |
|---|---|
| The two meters, side by side | Utilization and progress are different facts and the page must not let them be confused |
| The interventions log | Every attempt carries the worker, the generation and the evidence it acted on |
| Three outcomes, one of them locked | APPLIED / REFUSED / INDETERMINATE, and an indeterminate is written once and never rewritten |
| The refusal that names the field | Below sufficiency, do not start it, and say which check failed |
| The seal before and after a rehome | The identity claim, shown rather than asserted |
A runtime that admits transitions in production, and counts them. Today that is a
specification: the enforcement kernel is a spec under review with no admitted implementation, and the measured floor is a kernellet, not a hosted service. Until something counts admitted transitions under load, the unit on the invoice does not exist.
A calibrated price. The kernellet's measured cost per transition is a few hundred cycles, so
a million transitions is a fraction of a second of one core. Every figure in the prototype is a placeholder and stays one until a running kernel gives a real number.
Carriers that respect the cloud rulings. Cloudflare for everything with Fly keeping only
Keycloak was ruled 2026-08-15, and Hetzner is already named as hosted capacity. So the carriers the prototype shows are Cloudflare, Hetzner, and the customer's own machine — a T&R box in their own building is a carrier like any other. Any other provider needs the ruling revisited first.
A customer. Locus hosting is bought by someone building on ComputeDriven, and today that is
nobody outside this tree. Phase one's operator is the first candidate.
Phase one does not wait for any of this. The service package stays the commercial object; a locus becomes one more thing a package's provider execution station can name, alongside a Cloudflare cron trigger and whatever the first external operator already runs. The prototype's pricing table has four plans and a favoured tier for a product with no customers; the pilot's rule stands — one package, customer zero, then an introductory price.
Being a host, or a sandbox, or a runtime.
Positioning by asserting what competitors lack. The product wins by making cross-provider service
operations easier; a competitor's feature list is not a claim this project verifies or publishes.
A customer-facing agent that changes websites, in the first package.
Unlimited customisation inside a subscription.
Shipping the phase-two console as anything but a prototype until §6a's four gates are cleared.
| # | Item | Owner |
|---|---|---|
| 1 | Enter this direction in REVISION_REGISTER.md as a ruling | Travis |
| 2 | The portfolio nav records rung: null for this surface; a rung for the plan (spec) is lane N's to record | lane N |
| 3 | The introductory price for the paid pilot | Travis, after customer zero's cost record exists |
| 4 | Where the first ledger lives (a signed file ledger is sufficient for one operator) and its access, backup and retention policy | before customer zero |
| 5 | The first operator's name and public identity | Travis |
| 6 | The nav's tagline for this surface still reads "Hosting + Supabase dashboard" | lane N |
| 7 | Whether phase two is this domain's direction or a separate surface, and whether the nav's runtime layer word should follow it | Travis |
| 8 | A calibrated cost per admitted transition, measured on a running kernel, before any figure in /console/ is repeated anywhere | after the kernel admits transitions under load |
spec names a written specification. This file is one, so the rung the surface may claim is spec — once the nav records it. in_tree needs the package module in code with a test suite. live_local needs customer zero's cycle run on a developer machine with its costs recorded. live_deployed needs the same cycle run on the ruled runtime and a report delivered to a paying customer. Nothing above spec is available until the acceptance test in 5) is run.