Skip to content

CTC And MK Operating Profile Gap Matrix

  • Classification: OBSERVED-FACT

  • Status: EVIDENCE (2026-07-10 snapshot)

  • Current owners: docs/PRODUCT.md, docs/DESIGN.md, .agents/rules/ARCHITECTURE.md
  • Interpretation: this matrix preserves dated source/local-DB evidence and must not override the current product, target-design, or runtime owners.

Purpose

This document is a dated sourced baseline for the two operating profiles used to investigate the multi-tenant model at the recorded snapshot:

  • CLIENT_ID = 1: CTC execution-first operations.
  • CLIENT_ID = 2: MK order-first operations.

It records shared platform behavior, tenant variations, active client-number branches, and the smallest follow-up work needed to remove customer-specific assumptions without forcing both tenants into the same business workflow.

Work Item: CTC-1153 under CTC-1151.

Evidence Boundary

Evidence Scope
Source checkout Committed qa source at bd6b895e5 after CTC-1152.
Local database kyle-mba:3306/prod, read-only queries on 2026-07-10.
Tenant rows T_CLIENT.ID IN (1, 2) only.
Runtime evidence Existing documented CLIENT_ID=1 field runbook and CLIENT_ID=2 local browser evidence. No new browser run was performed for this baseline.
Excluded Production DB writes, schema changes, tenant config writes, module writes, menu writes, and application behavior changes.

Local data describes the current development baseline. It is not proof that a production deployment has identical tenant rows. Unknown or stale behavior is marked NEEDS CONFIRMATION.

Executive Findings

  1. The two profiles already share one page, API, module, and table ownership model. Their visible menus differ through tenant menu data rather than separate application entrypoints.
  2. Menu separation is stronger than module separation. All 35 catalog modules are effectively enabled for both tenants because a missing T_TENANT_MODULE row currently means allowed.
  3. MK has 16 implicitly enabled modules, including CTC execution modules such as delivery, transload, yard map, and yard move. Hiding those pages in the MK menu does not establish a reusable module boundary.
  4. MK has six role rows matching CTC role names 1-6 but only one active local user. Five roles have no default menu. Those role names are placeholders, not verified MK field-user contracts.
  5. MK_DOCUMENT_WORKFLOW_ENABLED has no tenant config row. Runtime still uses a CLIENT_ID = 2 compatibility default.
  6. EXPORT_BROKERAGE_WORKFLOW_ENABLED is enabled for both tenants locally. It is visible for MK because MK has the required order menus. Its CTC value has no current visible effect and needs confirmation or removal.
  7. Nine direct client-number behavior branches remain. Seven are business/UI variations that should move to config or process capabilities, one is a temporary client-2 config fallback, and one is a client-1 report migration compatibility branch.
  8. Multi-tenant readiness should not be claimed until module rows are explicit, missing-module behavior can become deny-by-default, MK config defaults are seeded, and a CLIENT_ID=2 browser regression pack passes.

Operating Profile Matrix

Dimension CTC execution-first MK order-first Shared contract / gap
Business trigger Appointment, dispatch, transload, yard, or delivery work. Commercial order, purchase order, sales order, booking, allocation, or scale work. Preserve different triggers; do not force a shared first record.
Primary systems YMS and TMS, with WMS and BMS side effects. OMS and WMS, with BMS, booking, scale, and explicit execution bridges. Shared module catalog and API ownership.
Primary composite process PROC-OPS-DAILY-CTC. No MK composite process registered. MK composite process remains NEEDS CONFIRMATION; do not duplicate the atomic order process.
Registered atomic processes PROC-TMS-INBOUND-PLANNING, PROC-YMS-YARD-DISPATCH, PROC-TMS-DRIVER-DELIVERY, PROC-BMS-BILLING-CLOSE-CTC. PROC-OMS-ORDER-TO-PACKING-MK. Booking, scale, inventory, and tenant onboarding still need explicit shared/variant contracts.
Operational source T_TRANSLOAD, T_LOADING_PLANNER, T_YARD_LOCATION, T_YARD_DISPATCH_QUEUE, T_DELIVERY. T_LOAD, T_LOAD_ITEM, T_INVENTORY_LOT, T_LOAD_ALLOCATION, T_BOOKING, conditional T_SCALE_TICKET. Shared tables remain tenant-scoped; process ownership differs.
Menu shape Yard, Inbound, Shipping, Accounting, Reports, Driver, Label Print. Operation, Billing, Setting, MK Daily Dashboard. Tenant menu data is the correct presentation boundary.
Current users 66 active local users. One active local user (admin2 evidence in the existing manual). MK field roles cannot be approved from copied role rows alone.
Current browser evidence Field-user system test runbook for CTC roles and flows. Local admin2 browser evidence dated 2026-06-23. MK evidence is useful historical evidence but must be rerun against the current contract version.
Tenant Active menu rows Page menu rows Interpretation
CTC 64 55 Broad execution, yard, driver, inbound, billing, and reporting surface.
MK 27 24 Narrow order, allocation, scale, booking, rate, and reporting surface.

The MK menu is data-driven and already follows the intended order-first profile. The active MK operation pages are:

  • mk-commercial-orders
  • mk-inbound-orders
  • mk-doortrade-orders
  • mk-outbound-orders
  • mk-export-brokerage
  • mk-allocation-workbench
  • mk-order-schedule
  • mk-booking-list
  • scale-portal
  • scale-ticket-list
  • mk-deal-ledger
  • fleet-management

Role Baseline

Tenant Role state Gap
CTC Seven roles with established field-user evidence and default landing pages. Continue role-specific regression; menu access remains data-driven.
MK Six role rows match CTC role names 1-6; only Administrator has a default menu (scale-portal). Office, Dispatch, Forklift, Truck, and Yard roles have no current local user or approved default landing path.

Decision: keep shared role concepts available, but classify MK roles 2-6 as NEEDS CONFIRMATION. Do not onboard field users or derive permissions from the role names until the MK process owner confirms responsibilities and browser workflows.

Module Baseline

Tenant Catalog modules Explicit enabled Implicit enabled Explicit disabled
CTC 35 23 12 0
MK 35 19 16 0

Current compatibility behavior in config/config.php and the module guard is:

T_TENANT_MODULE row exists  -> use IS_ENABLED
T_TENANT_MODULE row missing -> allow

This is acceptable only during migration. A reusable onboarding model requires an explicit enabled/disabled row for every relevant module. Changing the guard to deny missing rows before seeding existing tenants would be a high-risk rollout and is not part of this baseline.

The first module seed is a parity migration, not a product-profile decision. It must insert only missing T_TENANT_MODULE rows with the same currently effective value (IS_ENABLED = 1), leave existing rows unchanged, record every inserted row for rollback, and prove that page/API behavior is unchanged. Any later disable is a separate product-approved task based on an explicit desired state matrix.

Profile Emphasis

Capability CTC MK Required disposition
Yard map/move and transload execution Primary and explicitly enabled. Implicitly enabled but not part of the primary menu. Parity seed as enabled first; desired enabled/disabled state remains NEEDS CONFIRMATION.
Delivery/driver portal Primary and explicitly enabled. Implicitly enabled; no validated MK truck-user process. Parity seed as enabled first; any disable waits for role/process approval.
OMS commercial/inbound/outbound/allocation Not primary; several modules are implicitly enabled. Primary and explicitly enabled. Parity seed CTC as enabled first; later CTC disable decisions require confirmed bridge ownership.
Scale Explicit for both tenants. Primary MK operating surface. Retain shared YMS/BMS ownership with tenant-specific validation rules.
Booking Explicit for both tenants. Primary document workflow. Retain shared TMS ownership; move MK presentation and document options to config.
AI and email add-ons Explicit for CTC. Implicitly enabled for MK. Parity seed as enabled; desired state requires integration owner and credential-readiness decisions.
QuickBooks, reports, Telegram Explicit for both tenants. Enabled, but active use varies. Confirm integration credentials and operational owner per tenant; module enablement alone is not readiness.

Tenant Config Baseline

Only config presence and safe non-secret boolean values were inspected. Secret values were not read or recorded.

Config area CTC MK Gap / disposition
MK_DOCUMENT_WORKFLOW_ENABLED No row; default false. No row; code defaults client 2 to true. Seed explicit values, then remove the client-number fallback.
EXPORT_BROKERAGE_WORKFLOW_ENABLED true, but required MK order menus are absent. true and menu/API gates are active. Confirm and likely remove the CTC value; retain explicit MK config.
KJ_TABLE_OPTIONS No row. Present. Retain as a tenant/page UI option source; do not use it for business permissions.
AI_TASK_PROFILES No row. Present. Retain as task-profile context, with addon.ai explicitly enabled or disabled.
OPERATION_EVENT_ROLE_POLICY Present. Present. Retain; verify role policy after MK roles are approved.
QuickBooks credentials/config Present for CTC. No runtime config rows in the inspected baseline. Do not infer MK QuickBooks readiness from module enablement.

Active Client-Number Branch Inventory

Classification values:

  • retain-temporarily: compatibility behavior with a named exit condition.
  • convert-to-config: tenant variation is valid but must not use a numeric client check.
  • remove-after-migration: duplicate client-side or legacy compatibility logic.
  • needs-confirmation: the business rule is not yet approved.
Location Current branch Classification Target / exit condition
app/platform/tenant/config_helper.php:375 Client 2 defaults MK_DOCUMENT_WORKFLOW_ENABLED to true. retain-temporarily Seed explicit CTC/MK config rows, verify both tenants, then remove the numeric fallback.
app/systems/OMS/inbound-order/mk_post_helper.php:188 Client 2 may submit zero scale axle weight. needs-confirmation, then convert-to-config Confirm the MK scale process rule and add a named scale validation config/capability.
public/assets/js/modules/yms/scale-portal.js:65 Client 2 duplicates zero-weight allowance in the browser. remove-after-migration API/options response exposes the approved validation capability; browser stops checking client ID.
app/addons/reports/query_helper.php:423 Client 2 uses the MK sales-order packing-list query. convert-to-config Use the approved document workflow/process capability, initially MK_DOCUMENT_WORKFLOW_ENABLED.
public/assets/js/modules/shared/kj-table-options-master.js:276 Client 2 shows MK booking columns and labels. convert-to-config Load booking presentation options from page/tenant config or API options. This is not a popup task.
public/assets/js/modules/shared/popup.core.js:7882 Client 2 selects the MK booking popup layout. convert-to-config Booking popup task consumes server-provided workflow/presentation options.
public/assets/js/modules/shared/popup.core.js:10545 Client 2 adds Booking Confirmation. convert-to-config Use MK_DOCUMENT_WORKFLOW_ENABLED from booking options; preserve popup-specific testing and rollback.
public/assets/js/modules/shared/popup.core.js:14579 Booking record client 2 changes cutoff label and commodity-rate visibility. convert-to-config Booking popup task uses explicit field presentation options rather than record client ID.
app/platform/audit/super_admin_query_helper.php:1036 Client 1 receives legacy page-report rows when client buckets are absent. retain-temporarily Remove after all historical report buckets are migrated or the compatibility window is explicitly closed.

Deployment Fallbacks That Are Not Profile Rules

Config::CLIENT_ID remains a deployment fallback in Gmail, QuickBooks, OrderSync, and a yard-state helper. These are not CTC-versus-MK business branches, but they still need explicit tenant context before a shared multi-tenant deployment can run the corresponding background/integration path for more than one tenant.

Shared Process And Tenant Variation Decisions

Area Canonical decision
Authentication, menu, module guard Shared platform implementation. Tenant variation is data.
CTC daily operations Keep PROC-OPS-DAILY-CTC as a CTC composite. Do not make MK inherit it.
Inbound planning/loader Keep PROC-TMS-INBOUND-PLANNING CTC-only until an MK execution bridge is approved.
Yard and driver Keep CTC process ownership. MK module and role access require explicit confirmation.
MK order to packing Keep PROC-OMS-ORDER-TO-PACKING-MK as the current MK atomic process. Extract it from the general operations manual before approval.
Booking documents Shared TMS module with tenant-configured document and presentation variation. A dedicated process contract is still missing.
Scale Shared YMS/BMS implementation with process-specific validation. Zero-weight behavior remains unapproved.
Billing Shared BMS module ownership, but CTC execution billing and MK order/rate/invoice flow remain separate process variants.

Browser Evidence Gaps

CTC

  • Current field-user runbook covers Office, Loader, Yard, Driver, Billing, and Label roles.
  • Future tenant/module changes must rerun the affected scenario IDs through the real menu with CLIENT_ID = 1.

MK

  • Existing local browser evidence used admin2 on 2026-06-23.
  • Current source and config have changed since that evidence.
  • No field-user evidence exists because the inspected local tenant has one active user.
  • The next MK pack must cover menu access, direct-route module denial, order create/edit, allocation, booking documents, conditional scale, reports, visible errors, refresh persistence, and cleanup under CLIENT_ID = 2.

These are proposed task boundaries, not completed implementation.

Order Task boundary Parent Why this boundary
1 Build the current CLIENT_ID=2 admin browser regression baseline. CTC-1151 Must run before module, config, or client-branch behavior changes so later regressions are measurable.
2 Seed explicit module rows with parity-only values for CLIENT_ID 1 and 2. CTC-1151 Insert missing rows as enabled, preserve every current effective decision, leave existing rows untouched, and retain an exact delete-only rollback list.
3 Change missing tenant-module behavior from allow to deny after parity verification. CTC-1151 Separate code deployment after every existing module has a row; verify positive and negative page/API paths for both tenants.
4 Approve tenant module desired-state and MK role/default matrix. CTC-1151 Product decision task after browser baseline; classify each module and role as enabled, disabled, or needs confirmation without changing data.
5 Apply approved module enable/disable changes. CTC-1151 Separate DB/config rollout using only the approved desired-state matrix and an exact rollback plan.
6 Seed and reconcile operating-profile config values. CTC-1151 Add explicit MK_DOCUMENT_WORKFLOW_ENABLED; confirm/remove CTC export-brokerage flag; verify integration module/config alignment.
7 Replace scale zero-weight client checks with an approved capability. CTC-1151 One backend/frontend behavior and rollback boundary; no popup dependency.
8 Replace MK packing-list report client check with document workflow capability. CTC-1151 Independent report/query behavior with focused document verification.
9 Replace booking-table client check with tenant/page presentation options. CTC-1150 Non-popup modernization task; can precede popup migration.
10 Migrate the Booking popup client-specific layout/actions/labels. CTC-1150 One popup, one task, one deployment, one rollback. Keep after non-popup work.
11 Register missing booking, scale, and MK composite process contracts. CTC-1140 Process contracts should precede AI recommendation or automation readiness.

Existing CTC-1080 remains deployed history and CTC-1154 already owns the first non-popup KJView CRUD equivalence wave. Do not create duplicate tasks for those scopes.

GitHub issue #823 remains open as the historical KJView technical parent, not the implementation status source. Its comment points to CTC-1082, which was consolidated into deployed CTC-1080. Current execution maps to CTC-1150 and CTC-1154; the proposed booking-table presentation task belongs under CTC-1150 and must not recreate an #823 or CTC-1082 task.

Readiness Gates

The system is ready to claim a repeatable second-tenant onboarding model only when all of the following are true:

  1. Every required module has an explicit tenant enablement decision.
  2. Missing tenant-module rows no longer grant accidental capability.
  3. Numeric client checks are removed from business/UI behavior or have a named temporary compatibility exit condition.
  4. Tenant config values are explicitly seeded and secrets remain masked.
  5. MK roles and default landing pages are approved from real operator needs.
  6. CLIENT_ID=1 and CLIENT_ID=2 page/API negative module tests pass.
  7. Current browser regression packs pass for both operating profiles.
  8. Shared process contracts and tenant variations are reviewed and versioned.

The CLIENT_ID=2 current-state browser baseline is a prerequisite for tasks 2-10, not a post-change validation substitute.

Source Map

  • docs/DESIGN.md
  • .agents/rules/TENANT_CONFIG.md
  • .agents/rules/API_V2_CONTRACT_INVENTORY.md
  • docs/DESIGN.md
  • .agents/rules/DB_SCHEMA.md
  • docs/processes/process-registry.yaml
  • docs/processes/CTC_DAILY_OPERATIONS_WORKFLOW.md
  • DB Wiki overview and mk-operations
  • docs/runbooks/CTC_FIELD_USER_PROCESS_SYSTEM_TEST_RUNBOOK.md
  • config/config.php
  • config/modules.php
  • config/page_routes.php
  • app/platform/tenant/config_helper.php
  • app/platform/tenant/module_guard.php
  • app/systems/OMS/inbound-order/mk_post_helper.php
  • app/addons/reports/query_helper.php
  • public/assets/js/modules/yms/scale-portal.js
  • public/assets/js/modules/shared/kj-table-options-master.js
  • public/assets/js/modules/shared/popup.core.js
  • app/platform/audit/super_admin_query_helper.php

---

Source: docs/research/current-state/2026-07-10/CTC_MK_OPERATING_PROFILE_GAP_MATRIX.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.