Loomworks — Platform-founder authority standing note

Version 0.1
Date 2026-06-12
Provenance Operator (Marvin Percival) direction. The authority model was ruled this session (2026-06-12, rulings R1–R4) after the founder-authority Step-0 inspection at engine HEAD 158d4bc. The principle is the Operator's.
Status Settled principle. Records a new authority kind in the engine — a platform-level founder principal, distinct from and above engagement-scoped Operator designation. Built by CR-2026-101 (founder principal + require_founder + the /admin/* gate). Candidate for absorption into the methodology / architecture spec at the next consolidation. Operator-facing. HTML primary, Markdown source alongside.
Parent / sibling Sits beside standing-notes/loomworks-standing-note-engine-enforced-authentication-v0_4.md (how the engine enforces authentication); this note records how the engine represents one form of platform authority.
Cross-links change-requests/cr-2026-101-founder-authority-principal-and-admin-gate-v0_1.md (the build); change-requests/cr-2026-098-engine-api-boundary-closure-v0_3.md (the deferral this closes — "A3"); architecture/loomworks-companion-functional-spec-v0_3.md §10.3 (operator-mediated recovery, which this unblocks); candidate-seeds/loomworks/loomworks-candidate-seed-v0_12.md (Authorisation; Account recovery mechanism 3).

Plain-language summary

The Loomworks engine now has a platform-level founder — a single identity, above any one engagement, that gates the platform-administration routes. Until now no such identity existed: the /admin/* credit routes (issue a grant, provision a reservoir) were reachable by any authenticated person, a known exposure CR-2026-098 deferred. This note records that the founder principal now exists, what it is, what it gates today, and what it unblocks next.

It records an addition to the seed's authority model, stated plainly, not smoothed. The seed's model is "the Operator governs, Contributors participate" — at engagement scope. The platform founder is a new kind of authority that sits above engagement scope. That is a real addition; this note marks it as one.

What this records

The engine has gained a platform-level founder authority principal. It is distinct from the engagement-scoped Operator designation the seed already names:

Engagement-scoped Operator (existing): a person holds the "operator" designation on a specific engagement membership; it gates engagement-scoped privileged actions (managing that engagement's API keys, memberships, shaping). Checked by require_operator_designation. It says nothing about the platform as a whole.
Platform founder (new): a single identity for the whole platform, not tied to any engagement. It gates platform-administration routes. Checked by require_founder.

The seed (Authorisation) names Marvin Percival as "founder of DUNIN7 … the Operator for the Loomworks engagement," and frames authority as "the Operator governs; Contributors participate." That framing is engagement-scoped. The platform founder is the same person in the real world, but it is a new authority representation in the engine that did not exist before — one that reaches across engagements to the platform's own administration surface. The addition is recorded here so a later reader does not mistake the platform founder for the engagement Operator: they are different scopes, different checks, and the platform one is new.

What it is

A singleton, stored in system_config. One row, key platform_founder_person_id, value the founder person's UUID. No PersonRow role column; no migration (the table is key/value). The value column is Fernet-encrypted (the store was built for secrets); a founder UUID stored there is encrypted for no security reason — an accepted cosmetic mismatch, not worth a plaintext column or a migration. (R1.)
Checked at the door, not recorded in a ledger, for routine admin routes. A session-checked dependency, require_founder, resolves the current person and refuses with 403 if they are not the founder, before the handler runs. The routine /admin/* routes get the door only — they already write their own domain records, so a second audit row would be redundant. (R2.)
One shared dependency. Exactly one require_founder (mirroring require_operator_designation). Every founder-gated route uses it; adding a future founder-gated route is "add the dependency," never "re-implement the check." (R3.)
Bootstrapped out-of-band. There is no founder-gated route to set the first founder — setting the founder is what creates the first founder (a chicken-and-egg). The first founder is written by a one-time management script at the same trust level as direct database access; no HTTP surface sets it. Recorded so the bootstrap is understood as deliberate, not a gap.

What it gates today

The three platform-administration credit routes, and only those:

POST /admin/grants — issue a credit grant.
GET /admin/grants — list issued grants.
POST /admin/provisioning — provision a credit reservoir.

These were the "any authenticated person" exposure CR-2026-098 v0.3 recorded as accepted-and-temporary. With require_founder applied, they are founder-only; a non-founder receives 403. The live Operator Layer admin-grants UI already handles that 403 gracefully (it maps it to its existing permission-refused state), so closing the exposure required no frontend change — only that the founder's own session resolves to the stored founder identity.

When no founder is set, the routes fail closed (403) — an un-bootstrapped deployment exposes nothing rather than everything.

What it unblocks next

Operator-mediated account recovery — the seed's third account-recovery mechanism (candidate seed v0.12, Account recovery: "operator-mediated identity verification"). The Companion functional spec v0.3 §10.3 records it as "committed, deferred … gated on a prerequisite the Engine has deliberately not yet built — a platform-founder authority principal." That prerequisite is what this note records as built. Operator-mediated recovery — a governing human re-authorizing a locked-out person's access — is the highest-stakes consumer of founder authority, and it was deferred to exactly this gate. It is a separate later arc, built on require_founder, adding the recording ledger (an account_recovery_granted event) and the credential-reset mechanics. This note closes the two open threads — CR-2026-098 v0.3's deferral and Companion spec v0.3 §10.3's "concrete unblock condition" — by recording that the gate now exists.

The principle it follows — govern at the door, record the high-stakes

The founder governs — the door (require_founder) decides who may act. High-stakes founder actions will additionally be recorded — a ledger — when operator-mediated recovery builds, because resetting another person's credentials is exactly the kind of action whose provenance must be preserved. The door-only choice for the routine /admin/* routes is recorded as deliberate, not an omission: those routes write their own domain records (a grant row, a provisioning row), so the act is already accountable; a second audit row would be redundant. The distinction — door everywhere, ledger for the high-stakes — is the founder-authority shape this note sets down for the work that builds on it.