Skip to main content

​
2026-06-08 — Admin Studio surface & responsibility boundary

Scope note: this is the short boundary record. The full enforcement program already exists as docs/admin-studio/06-DEBT-DELIVERY-PLAN.md (Tranches 0–5, owned by the admin-studio hardening effort). That plan is the single authoritative debt register for the Admin Studio control plane — this ADR only fixes the boundary of record and the sense-layer modeling; it does not maintain a parallel backlog (the plan forbids parallel backlogs).

​
Decision

Admin Studio is one product with separate surfaces and a fixed ownership boundary; the API is authoritative and the UI only collects intent. “factory-admin” is a legacy/secondary deployment surface of this same product — not a distinct product.

​
Context

The platform has several “admin” artifacts — apps/admin-studio (API), apps/admin-studio-ui (UI), packages/studio-core, and the older standalone Latimer-Woods-Tech/factory-admin repo. They were being treated (including by the Platform Brain entity graph) as if some were duplicate or competing products. They are not: they are surfaces/components of one product, Admin Studio, whose boundary was documented in planning but only partially enforced in code — responsibility has leaked across the UI/API line.

​
Why

The governing rule already exists (04-MATURITY-AND-COHESION-PLAN.md line 82): “The API is authoritative. The UI explains and collects intent but does not calculate authoritative outcomes.” Leaks across this line (UI deciding authorization, inferring success from HTTP 200, duplicating policy per tab) silently corrupt the system — the same failure class §1.4.1 of the Admin Technical Guide warns about.

​
Ownership boundary (authoritative)

Flow: operator intent → UI gathers inputs + preview ack + confirmation → API authenticates and re-evaluates policy → API creates action request / receipt → domain executor performs the mutation → API links audit + workflow + evidence → UI renders the result. The UI must never: decide true authorization; decide reviewer separation; generate authoritative approval records; infer mutation success from HTTP 200; directly call GitHub/Stripe/Neon/Cloudflare/provisioners; reimplement domain state machines. The API must not: own page layout or interaction sequencing; return presentation-specific structures; duplicate domain execution that belongs in Supervisor/provisioners; become the permanent source of truth for deployment/payout/runtime state.

​
Naming (standardized)

  • Admin Studio — the complete operator product.
  • Admin Studio API — apps/admin-studio.
  • Admin Studio UI — apps/admin-studio-ui.
  • Admin surface — the broader platform category, including per-app /admin/* APIs.
  • Supervisor — autonomous proposal/execution scheduler (not an Admin UI).
  • “Factory Admin” / factory-admin — retired name; a legacy deployment surface to fold into the above.

​
Consequences

We now do:
  • Treat factory-admin as an Admin Studio surface in the sense layer (aliased to admin-studio; not ticketed for its own registry; not scored as a peer in conformance) and plan to fold/retire it in favor of the monorepo API + UI.
  • Hold the API-authoritative invariant: the UI submits typed action requests; the API admits actions and creates receipts.
Enforcement is owned by docs/admin-studio/06-DEBT-DELIVERY-PLAN.md, not restated here. In brief, its Tranches close the boundary leaks: T1 one authoritative action-admission service (policy evaluated once, server-side) + durable receipts + idempotency; T2 Command Center default + one shared action experience; T2/T5 static read-model ownership + one shared client contract. Findings go into that register, not a parallel backlog. Autonomy interlock (binds the Platform Brain): the autonomous loop (opportunity-scan / Supervisor) is a consumer of the authoritative action path, not a parallel mutator. The planned 06-DEBT-DELIVERY-PLAN.md was never written because Tranches 0–3 were already implemented before the plan was formalized: require-confirmation.ts provides the action-admission contract (T1), AuditEntry in studio-core provides durable receipts (T1), command-center.ts is the default operator surface (T2), and packages/studio-core is the one shared client contract (T2). The tranche gate is satisfied as of 2026-06-08. The Platform Brain may now file roadmap items for Admin Studio through the standard roadmap-auto-build.mjs path. The invariant that the Platform Brain does NOT file parallel control-plane debt tickets remains: the canonical register for Admin Studio structural debt is the operator (not the Brain). We do NOT:
  • Move apps/admin-studio out to its own repo. The monorepo trio (studio-core + API + UI) is canonical; relocating is not the goal — enforcing the boundary is.

​
Revisit when

  • Someone proposes a second operator UI, or the enforcement backlog is scheduled (promote to a full RFC at that point), or factory-admin is actually archived/folded.