A namespace is your own Layer 0 boundary — a name you lock like a domain, a signer only you hold, and the human-authored grants every consequential action is admitted against. Reserve it once; every decision made inside it is signed, verifiable, and yours.
Not an account and not a plan. A namespace is the unit the whole runtime is scoped to: the identity your admission decisions are issued under, and the boundary they're checked against. Three things travel with it.
Unique across the system and yours alone. A name already taken is refused at checkout — namespace_taken — exactly the way a registrar refuses a domain someone already holds.
Decisions inside your namespace are issued as signed receipts under a key identifier (kid) bound to you. Anyone can verify a receipt with the public key alone — no call back to us required.
Consequential actions are refused unless a boundary you authored grants them. The namespace is where those human-authored permissions live — omission is safe by construction.
The name is claimed the moment you reserve, like a domain. The boundary is only created when the payment is proven — never before, and never from a browser.
The door POSTs /v1/checkout with {email, namespace, tier}. The service validates the name's format and availability first; a taken name comes back namespace_taken before any charge.
Checkout runs on Stripe — a founding reservation or a subscription tier. If billing is ever unconfigured the service answers an honest 503, never a fabricated session.
Your namespace is created — the 0 → 1 moment — only from a signature-verified Stripe webhook. Never from a browser landing on a success URL.
Honest state. Live today · REST POST /v1/checkout answers now, and reservations are open. A namespace is provisioned exclusively from a verified checkout.session.completed webhook.
Why it matters: URL parameters are caller-asserted — anyone can type ?checkout=return. The same hardening that refuses caller-asserted evidence for a boundary guards your money: the return page shows a welcome and derives state live; it never claims payment succeeded. authority_effect = 0 — provisioning a namespace binds no authority; it hands you a boundary to author, not a permission to act.
The primitive is already running — reserving a namespace scopes it to you. Everything here rides the one contract at barycenters-admit.fly.dev.
Every consequential action you route is admitted or terminally refused against your boundary. POST /v1/admit — REFUSE is terminal, no override.
Each decision is a signed Ed25519 receipt — proposal hash, policy version, decision, reason, principal, time — single-use and tamper-evident, verifiable with the public key.
POST /v1/lumen/compile turns human-authored rules into the boundary. Lumen fails narrower, never silently wider — a broken grant denies, it never over-permits.
Wire it in shadow: it records what would have been refused and blocks nothing. Zero-risk to try, and the record is what earns the later move to enforce.
Lock the name like a domain, hold the signer, author the boundary. The primitive is live over REST today; reserving scopes it to you. A REFUSE is never billed, and nothing here binds authority until you say so.
authority_effect = 0 until a human signs · provisioned only from a verified payment · a REFUSE is never billed