This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step
Platform Tenant, Operating Profile, Capability And Configuration — Reconciliation¶
- Status:
SOURCE-RECONCILED PLATFORM FOUNDATION INPUT - Source baseline:
qa@4f6165bc4c53a7d98b0c246392dd9ed5bd75c21c - Source authority:
PLATFORM_TENANT_PROFILE_CAPABILITY_CONFIGURATION_SOURCE_AUTHORITY.md - Rebuild packet:
PLATFORM_TENANT_PROFILE_CAPABILITY_CONFIGURATION_REBUILD_PACKET.md - Related owners: P4 tenant platform, P2 live-tenant safety, P5 callers, P6 process applicability, P8 admin/support knowledge, P12 migration
- Process registry effect:
NONE; this is platform concern reconciliation, not one atomic business process - Effect boundary: documentation only
1. Reconciliation Result¶
The current platform already contains several important foundations, but they are not one active end-to-end contract.
Typed tenant execution context exists
Typed capability-resolution value/resolver exists
Tenant/module/config admin UI/API exists
Page/module/config guards exist
Process documents use operating profiles
However:
broad Runtime callers do not all use typed context
Operating Profile is not a first-class Runtime tenant binding
module missing/error can compatibility-allow
config scalar helpers lose source/validity
current Admin edits applied state directly
menu/page/API/action/record authorization remains separate and incomplete
The target must join these foundations without merging their concerns.
2. Current Concern Owners¶
| Concern | Current owner | Current result | Current ambiguity |
|---|---|---|---|
| effective local tenant | session/impersonation/getClientId() |
scalar positive tenant or deployment fallback | fallback provenance can be lost |
| strict tenant context | typed context + adapters + selected API routes | actor/subject/provenance/request aware | opt-in coverage only |
| global tenant mapping | injected published mapping target | MAPPED or LEGACY_LOCAL_ONLY |
trusted Runtime mapping broadly unavailable |
| operating profile | Product/P6 docs and per-caller behavior | ctc-execution / mk-order semantics |
no accepted first-class binding |
| module | T_MODULE, T_TENANT_MODULE, module guard |
enabled/disabled/compatibility allow | missing/error indistinguishable from explicit enable at boolean caller |
| page module/config | config/modules.php, T_MODULE_PAGE, module guard |
page availability result | unmapped page can allow/unknown |
| named process capability | ad hoc config/module/branch/record rules | caller-specific | no accepted broad active definition registry |
| config | T_TENANT_CONFIG, helper, env/default |
scalar typed-ish value | provenance/validity/source error collapsed |
| credential | provider-specific config/env and typed owner foundation | caller-specific availability | owner/capability/access separation incomplete |
| menu/role | menu rows, page helpers, API numeric roles | user route/action compatibility | not equivalent to module/capability |
| record | handler-specific SQL predicates | per command/query | no central record-access result |
| admin control | Admin Console + platform APIs | direct applied-state writes | no versioned release/apply/rollback contract |
3. Current Request Path¶
3.1 Legacy page path¶
Browser session
-> page bootstrap
-> getClientId()
-> page role/menu guard when present
-> module/page guard when present
-> page-specific config/customer branch
-> query/write helper
-> record predicate
Possible compatibility outcomes:
- no session tenant in direct/CLI code can fall back to deployment tenant;
- page guard and API guard can differ;
- a numeric tenant branch can select Product behavior;
- a missing module assignment can allow;
- a config error can fall back silently.
3.2 API v2 path¶
route match
-> authentication
-> optional strict tenant principal
-> module guard
-> required menu routes
-> required numeric role IDs
-> body parse
-> handler
-> handler-specific record/state checks
A strict route carries safe typed context plus scalar compatibility fields. A non-strict route reconstructs only legacy scalar context.
3.3 Job/integration path¶
Current jobs/providers are caller-specific. Some use explicit tenant config, some use deployment env/defaults, and legacy jobs can rely on deployment Config::CLIENT_ID.
Target rule:
one explicit strict child tenant context per job/provider execution
4. Current Admin Configuration Path¶
Administrator/Super Admin
-> Admin Console Tenant tab
-> select local tenant ID
-> GET modules/configs
-> PATCH tenant/module/config
-> local DB commit
-> UI reload/readback
Current positive result proves only local applied state.
local row updated
!= versioned release published
!= every deployment applied
!= every Runtime cache invalidated
!= every caller resolved the new value
!= Client 1/Client 2 role path accepted
Dedicated deployment currently presents tenant management as read-only in the page, but exact API-side enforcement and field behavior require Runtime verification.
5. Target Concern Resolution Path¶
Strict TenantExecutionContext
-> Portable Tenant Mapping
-> OperatingProfileResolution
-> ModuleResolution
-> ProcessCapabilityResolution
-> Typed ConfigResolution
-> CredentialAvailability
-> Menu/Page/API AccessDecision
-> Action/Record AccessDecision
-> Query/Command
-> Exact Readback / Effect Result
Each stage returns a typed result and stable reason. A later stage consumes earlier evidence but does not rewrite it.
6. Operating Profile Reconciliation¶
6.1 Current source of profile meaning¶
ctc-execution and mk-order are currently established in Product/process documentation.
Their Runtime behavior is reconstructed from:
- modules/pages;
- named config toggles;
- numeric tenant branches;
- order class/direction;
- process records;
- terminology/templates;
- provider/device availability.
6.2 Target profile role¶
The profile determines applicable Product/process defaults and terminology.
It does not grant access or provider use.
profile
-> applicable process families and default definitions
-> module/capability/config diagnostics
6.3 Migration rule¶
Before removing a numeric Client branch:
- identify the actual business difference;
- assign it to profile, named capability, typed config, terminology or template;
- publish explicit tenant parity state;
- compare old/new behavior for Client 1 and Client 2;
- cut over one caller;
- retain rollback;
- prove old branch caller-zero.
7. Module Reconciliation¶
7.1 Current state model¶
EXPLICIT_ENABLED
EXPLICIT_DISABLED
UNCONFIGURED_COMPATIBILITY
SOURCE_ERROR_COMPATIBILITY
INVALID
Current boolean callers commonly collapse the first, third and fourth states into true.
7.2 Target state model¶
ENABLED / VALID
DISABLED / VALID
DISABLED / MISSING
UNAVAILABLE / ERROR
UNAVAILABLE / INVALID
ENABLED / MISSING / COMPATIBILITY_FALLBACK
ENABLED / ERROR / COMPATIBILITY_FALLBACK
The target state is definition/caller-specific. Do not globally reinterpret all missing rows.
7.3 Explicit parity seed¶
A strict rollout requires an explicit current-intent seed for selected tenants/modules before disabling missing-row compatibility.
The seed is a migration artifact, not proof of entitlement.
8. Capability Reconciliation¶
8.1 Current examples¶
module + config key
module + numeric tenant default
page route + config
module + record state
provider config + caller branch
8.2 Target¶
named capability definition
+ applicable profile
+ module prerequisites
+ config prerequisites
+ credential prerequisite when applicable
+ explicit applied/default decision
Examples of capability scope:
mk.export-brokerage.create
mk.documents.render
mk.scale.reverse
ctc.billing.qbo.deliver
The exact registry and naming require P4/P6/P5 acceptance.
9. Config Reconciliation¶
9.1 Current scalar path¶
read tenant row
-> optional secret alias/decrypt
-> missing/empty/error => default
-> type helper casts
-> caller proceeds
9.2 Target typed path¶
load definition
-> load explicit observation with source metadata
-> validate type/shape/range/empty semantics
-> select allowlisted source/default
-> return value + validity + source + fallback flag + stable reason
9.3 Cache/readback¶
Current static request caches are safe for ordinary read-heavy requests but become a concern when an admin write and effective reread occur in the same process/request or long-running job.
Target apply completion requires:
row commit
-> applied version
-> cache invalidation/version switch
-> row reread
-> resolver reread
-> selected caller readback
10. Secret Reconciliation¶
Current encrypted tenant values and env fallbacks remain provider-specific compatibility.
Target separates:
credential reference ownership
credential availability
module/capability decision
provider call authorization
provider result
No diagnostic or Wiki page contains credential values.
11. Package / Entitlement Reconciliation¶
Current package/tier selection appears in tenant onboarding/module admin surfaces. Current source does not prove it is the universal commercial entitlement authority.
Disposition:
ENTITLEMENT SEMANTICS: OPEN PRODUCT DECISION
ENFORCEMENT: NOT AUTHORIZED
Until accepted, package/tier may be documented as onboarding/advisory metadata only.
12. Cross-Concern Handoff Matrix¶
| From | Completion evidence | To | What is not implied |
|---|---|---|---|
| tenant context | strict context validates tenant/actor/request | profile | profile assignment not implied |
| profile | assigned valid profile/version | module/capability | modules/capabilities not automatically enabled |
| module | explicit/compatible module result | capability | named behavior not implied |
| capability | enabled with prerequisites | access | role/record access not implied |
| config | typed valid value with source | capability/command | authorization not implied |
| credential | owner-matched availability | provider command | provider call permission/result not implied |
| menu/page/API | route access result | action/record | command/state eligibility not implied |
| approved release | immutable published package | deployment apply | local apply not implied |
| local apply | rows and applied version reread | effective diagnostics | every consumer cache not implied |
| diagnostics | effective result observed | field acceptance | workflow success not implied |
13. Current/Target State Diagrams¶
Tenant identity¶
LEGACY_LOCAL_ONLY
-> MAPPED
any mapping mismatch
-> MAPPING_CONFLICT
Module¶
UNCONFIGURED_COMPATIBILITY
EXPLICIT_ENABLED
EXPLICIT_DISABLED
SOURCE_ERROR_COMPATIBILITY
INVALID
Profile¶
MISSING
COMPATIBILITY_INFERRED
ASSIGNED_VALID
ASSIGNED_INVALID
DEPRECATED
Config¶
VALUE_VALID
VALUE_COMPATIBILITY_DEFAULT
MISSING
INVALID
SOURCE_ERROR
STALE
Release/apply¶
DRAFT
-> REVIEWED
-> APPROVED
-> PUBLISHED
-> APPLYING
-> APPLIED
APPLYING -> PARTIAL | FAILED | UNKNOWN
APPLIED -> DRIFTED | SUPERSEDED | ROLLED_BACK
These are semantic states, not current schema changes.
14. High-Risk Current Examples¶
Numeric MK document default¶
config row missing
+ clientId = 2
-> MK document workflow enabled
Target disposition:
explicit mk-order profile capability/config parity
-> retire numeric default caller-by-caller
Missing module row¶
module catalog exists
+ tenant row missing
-> current compatibility allow
Target disposition:
explicit parity seed
-> strict definition/caller migration
Admin direct config write¶
PATCH current applied row
-> success
Target disposition:
versioned release/apply/readback/rollback
Legacy CLI fallback¶
no explicit tenant binding
-> Config::CLIENT_ID
Target disposition:
explicit strict child context or reject write
15. Required Policy Decisions¶
- profile composition and assignment owner;
- profile definition/version lifecycle;
- capability definition owner/storage/source;
- explicit module parity seeding;
- package/entitlement semantics;
- config definition registry owner;
- empty-value semantics per definition;
- cache/version/invalidation contract;
- Control Tower release and local applied-version representation;
- emergency local override procedure;
- Shared/Dedicated apply authority;
- credential external-ref support;
- strict-context caller priority;
- Client 1 and Client 2 acceptance cohorts.
These decisions are enumerated in the policy matrix; this reconciliation does not make them.
16. Required Verification¶
- current source/deployment/config identity;
- direct session, impersonation, admin override and explicit job contexts;
- missing/disabled/error module behavior;
- config missing/invalid/error/default behavior;
- numeric Client compatibility branches;
- current admin module/config before/after/readback;
- same-request and subsequent-request cache behavior;
- provider credential owner negatives;
- page/API/action/record parity;
- current and target CTC/MK profile results;
- Control Tower publish/apply/rollback/drift;
- Shared/Dedicated parity.
No verification above was executed in this source-only wave.
17. Current Disposition¶
Platform source reconciliation: COMPLETE INPUT
Operating Profile binding: OPEN / NOT IMPLEMENTED
Typed context: PRESENT / PARTIAL ADOPTION
Typed capability resolver: PRESENT / INACTIVE BROADLY
Admin applied-state editing: CURRENT COMPATIBILITY
Control Tower release/apply integration: TARGET INPUT
P4-003 activation: NO
Runtime/role/DB/provider evidence: REQUIRED
Wiki publication: NOT AUTHORIZED
---¶
Source:
docs/processes/PLATFORM_TENANT_PROFILE_CAPABILITY_CONFIGURATION_RECONCILIATION.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.