Skip to content

Decision 0027 — Tenant Administration Foundation Sequencing

  • Status: ACCEPTED
  • Authority: RATIONALE_ONLY
  • Date: 2026-09-09
  • Approval: direct Product-owner acceptance of the detailed v2 proposal and request to adjust and deploy
  • Partially supersedes: Decision 0016, only basic administration placement and blanket advanced-console sequencing
  • Retains: six-phase numbering, historical evidence, Phase-6 persistence and separately authorized Legacy transition
  • Current order: ROADMAP
  • Product definition: PRODUCT
  • Current execution: the related Task and Git history

The current execution path follows the Task guidance above. The EXECUTION mention in Context below and the verification status in Evidence and approval are records from 2026-09-09 and are not read as the current progress state or as new verification results.

Context

The Product owner clarified that commercial packages, feature eligibility, operational activation, typed policies and user permissions are distinct. Prior documentation attached basic package-aware administration to NS5-008 while EXECUTION still required all NS5-007 transfer/bootstrap work first. That placement delays a foundation that CTC/MK workflow implementation and acceptance need now.

Earlier Phase-2 Admin work already provides reusable identity/profile/module/config/role paths. It is neither absent nor proof of the newly requested commercial-assignment behavior. NS5-006 is a pure internal lifecycle core without persistence/UI; its completed status is not a working store.

Alternatives

Option Consequence Decision
Keep base Admin behind Phase-5 import/bootstrap dependent migration risks temporary customer branches, false switch-based licensing and late integration reject
Move the entire Control Plane and all consoles before migration speculative horizontal scope; delays working business consumers reject
Correct basic single-tenant administration now; advanced repeatable operations later preserves existing owners and history while proving the necessary Admin-to-business vertical adopt

Decision

Basic offering assignment, feature activation, typed policy, action permission and applied-state management belong to the early tenant foundation. Preview, expected revision, atomic persistence, audit, authoritative readback and manual configuration restore as a new change are basic safety. Do not defer tenant isolation, privilege checks, redaction or effect-specific recovery until Phase 5.

Deliver the missing scope as current Phase-3 prerequisite correction NS3-122. Do not reopen all Phase-2 Tasks or halt independent Phase-3 work. Dependent eligibility/Transload changes and their acceptance consume the shared contract and its executed evidence. No temporary numeric-client branch is justified by waiting for a later admin UI.

NS5-008 retains only advanced release/onboarding views. NS5-007 adds durable release envelopes and configuration/template transfer/bootstrap using the accepted base, not a second assignment writer. Support/Engineering/QA, mass actions and operational readiness follow their actual accepted access, storage and environment dependencies. No blanket completion of every Phase-4 improvement or every preceding console is required; final Phase-5 operational/onboarding acceptance remains intact.

The minimum manual new-tenant journey can be admitted independently of full automation. Existing CTC/MK proof does not require third-tenant creation. No live tenant, account, secret, commercial term or data copy is created by this decision.

Consequences and boundaries

  • Keep the approved base/six-package/field-add-on catalog; no source-package renaming or SQL move.
  • Retain old Tasks and evidence; a new target is not retrospective failure or accepted implementation.
  • Reconcile the current ROADMAP, the relevant Tasks and Git evidence, and policy/module documentation together.
  • Keep basic and advanced implementations under separate exact write ownership; preserve concurrent work and use current-checkout admission before runtime edits.
  • Do not require durable draft/approve/publish infrastructure for ordinary single-tenant save.
  • A configuration restore is a new revalidated revision, not a rewind of business/audit history.
  • Current missing persistence and field-policy gaps remain explicit until actual implementation proof.
  • No runtime, schema, permission, credential, payment or service change is part of this decision.

Evidence and approval

Approval is the Product owner's explicit request, not an invented independent architecture review. The source/document review establishes current owners and sequencing gaps only. Runtime/DB/browser acceptance of NS3-122 remains NOT_RUN. Exact storage schema, new public contracts and their bounded implementation must follow existing admission; this decision does not pre-approve arbitrary DDL.

Rollback and review trigger

Reconsider the ordering only with specific consumer/dependency evidence and a recorded decision. Restore documentation through an ordinary reviewed forward change, not history rewrite. Restoring a prior roadmap does not restore live tenant configuration or erase audit/business facts. Phase 6, local/cloud authority and Legacy retirement conditions remain outside this amendment.

Source: new-system/docs/decisions/0027-tenant-administration-foundation-sequencing.md — ctc repository · This page is an English translation of the source document.