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

CTC Operating Model, Process Portfolio And Migration Map¶

Status: CURRENT PROCESS PORTFOLIO / RECONCILIATION IN PROGRESS
Owns: L0-L3 operating-model hierarchy, value-stream composition, cross-process handoff view, portfolio gaps and migration-priority inputs
Does not own: atomic process semantics, Runtime implementation facts, Task status, user-facing Wiki content or migration authorization
Update when: a value stream, composite/atomic process, profile applicability, major handoff, lifecycle state or migration-readiness disposition changes
Context: Context Appendix M
Process standard: PROCESS_CONTRACT_STANDARD.md
Registry: process-registry.yaml
Migration extension: PROCESS_MIGRATION_READINESS_EXTENSION.md
Wiki projection: docs/wiki/internal/PROCESS_PROJECTION_REQUIREMENTS.md
Baseline revision for this initial reconciliation: 4fc2f5a893765fbb95e0a2bdcb971322b0ec9fc0

1. Purpose¶

This document explains how the registered CTC/MK processes fit together as one operating portfolio and how that portfolio becomes a migration plan.

It is intentionally above the detail level of an atomic workflow contract.

Product operating model
-> value streams
-> composite processes
-> atomic processes
-> commands / queries / events
-> current and target runtime adapters

The process registry remains the exact machine-readable index. Individual process documents remain the semantic owners. This portfolio provides the missing cross-process and migration view.

2. Current Baseline Assessment¶

The current repository contains substantial process detail, but the portfolio is not yet approved or migration-ready.

Existing strengths¶

Stable process and scenario identifiers exist.
CTC and MK profiles are separated conceptually.
Major CTC execution and MK order-first workflows have composite owners.
Many atomic process documents name pages, APIs, data, exceptions and evidence.
The Wiki map links many user pages to process owners.
Existing contracts distinguish composite reconciliation from child mutation authority.
Retry, unknown-result, correction and provider-effect gaps are often documented honestly.

Portfolio deficiencies¶

Gap	Current consequence	Required owner
No canonical L0-L2 hierarchy	Readers must reconstruct the company operating model from many files	P6-007
Registry last-updated marker predates recent August work	Current operational behavior can be absent from the process index	P6-007 + Operational owner
All previously inventoried processes are `draft / partial`	Source detail exists without reviewed/approved operational meaning	Process owners + user/operations review
Role/cadence/escalation often unknown	A workflow cannot be adopted or migrated safely by target roles	P6/P8/P2
Cross-process handoffs vary in detail	Partial completion and recovery can be interpreted differently	P6
Process-to-runtime mapping is distributed	Migration may become route/file based	P6/P5/P12
No standard migration packet per process	One-writer cutover and caller-zero are not uniformly planned	P6/P12
Wiki crosswalk does not prove content coverage	Users may find a page whose procedure is stale or incomplete	P8
Operational changes do not always update process owners	Process docs can lag real work	Operational Delivery + P6/P8
Recent Final Loading/Bale Review is not a registered process owner	Important current office work has no final portfolio disposition	P6-007

The prior P6-001 inventory counted 40 registered processes: 35 atomic and 5 composite, all draft / partial, with a large unresolved-unknown set. That count is a baseline input and must be revalidated against the current source and Operational Delivery history before lifecycle promotion.

3. Process Hierarchy¶

L0 — Product Operating Model¶

CTC is one modular Operations Platform with two current reference operating profiles.

Profile	Operating emphasis	Primary composite view
`ctc-execution`	appointment, physical execution, yard/driver, warehouse and billing close	`PROC-OPS-DAILY-CTC`
`mk-order`	commercial order, inbound/outbound, inventory allocation, conditional scale and documents	`PROC-OMS-ORDER-TO-PACKING-MK`

The profile selects sequence, terminology and enabled capabilities. It does not own copied process authority or customer-ID branching.

L1 — Value Streams¶

Value stream	Outcome	Current profile applicability
Demand / request to planned work	A reviewed request becomes identifiable scheduled or ordered work	CTC + MK by different child processes
Planned work to physical completion	Assigned work is physically executed with authoritative state and evidence	CTC primary; MK conditional
Receipt to inventory	Received material becomes a traceable lot/balance/location	CTC + MK
Inventory to outbound fulfillment	Available inventory is linked to outbound demand and shipment context	MK primary; CTC uses execution-first paths
Execution to document / billing close	Local records, files, invoices and provider effects are reconciled	CTC + MK with different owners
Correction / recovery / reconciliation	Partial or incorrect results are corrected without losing provenance	Cross-cutting
Daily / management control	Operators identify pending, blocked and completed work across child owners	CTC daily + MK dashboard/composite

L2 — Composite Processes¶

Composite	Purpose	Current maturity concern
`PROC-OPS-DAILY-CTC`	CTC daily sequence and cross-child checkpointing	No direct API/data owner; role matrix and full child coverage incomplete
`PROC-OPS-YARD-TO-DRIVER-HANDOFF-CTC`	Conditional Yard completion to Driver eligibility	No durable shared correlation or cross-process transaction
`PROC-BMS-BILLING-CLOSE-CTC`	Local transaction, AR, QBO, file and email reconciliation	Provider/role/field evidence incomplete
`PROC-OPS-REPORT-RECONCILIATION-CTC`	Periodic operational report review	No stored completion and production accuracy acceptance incomplete
`PROC-OMS-ORDER-TO-PACKING-MK`	MK cross-child order-first reconciliation	Role, concurrency, optional-child and durable-output gaps remain

Composite completion is a reconciliation disposition, not an invented cross-child status or transaction.

4. CTC Execution Value Streams¶

4.1 Request To Planned Inbound Work¶

appointment email / manual appointment
-> human review
-> scheduled transload or appointment
-> Inbound Planning visibility
-> check-in / plan / assignment

Primary owners:

PROC-TMS-APPOINTMENT-EMAIL-TO-SCHEDULED-CTC
PROC-TMS-INBOUND-PLANNING

Migration-critical questions:

Which request and item IDs provide durable idempotency?
Which role may approve, reschedule, reject or contact manually?
Which provider reply is a separate effect?
What exact read proves the scheduled handoff?
Which current compatibility rows remain required?

4.2 Planning To Loader Completion¶

planned row
-> assignment
-> loader start
-> loader completion
-> exact completed detail
-> inventory / yard / review handoff as applicable

Primary owner: PROC-TMS-INBOUND-PLANNING

Important variants:

unload;
transload/load-to-load;
reload;
spare;
domestic pickup;
break and staff-time effects.

Migration blockers include partial Undo compensation, client/role parity, side-effect durability and implicit state/materialization paths.

4.3 Yard And Driver Execution¶

yard demand
-> queue / schedule
-> claim
-> physical move or pull-out closing
-> current yard location and queue readback
-> conditional Driver Start eligibility
-> delivery execution and evidence

Primary owners:

PROC-YMS-YARD-DISPATCH
PROC-OPS-YARD-TO-DRIVER-HANDOFF-CTC
PROC-TMS-DRIVER-DELIVERY

This value stream is not migration-ready until command-role authority, concurrency, duplicate completion and partial physical/provider recovery are proven.

4.4 Inventory, Warehouse And Bale Reconciliation¶

completed receipt / unload / reload
-> inventory lot and placement
-> warehouse visibility
-> source / leftover / spare / allocation relation
-> review, correction, void or reconciliation

Current registered owners include:

PROC-WMS-WAREHOUSE-GRID-INVENTORY-OVERLAY
PROC-WMS-LABEL-WAREHOUSE-PLACEMENT-CTC
PROC-WMS-BALE-INVENTORY-ADJUSTMENT-CTC
PROC-WMS-INVENTORY-LOT-CORRECTION
physical snapshot and report processes

Current unregistered process candidate¶

The current Final Loading/Bale Review operational flow introduces or consolidates:

completed Reload/Transload
-> compare inbound and outbound quantity/weight
-> reconcile L2L / Source / Leftover / SPARE evidence
-> confirm or reopen review
-> expose BAL TRK result

It must be dispositioned by P6-007 as one of:

a new atomic process;
a versioned extension of PROC-WMS-BALE-INVENTORY-ADJUSTMENT-CTC;
a composite/review child linked to Inbound Planning and Inventory;
an Operational-only compatibility flow with an explicit retirement plan.

Until that decision, it is a NEW PROCESS CANDIDATE, not an approved registry process.

4.5 Billing, Files And Provider Close¶

source transactions / completed work
-> review and local confirm
-> file/document evidence
-> provider delivery where required
-> local/provider two-sided reconciliation
-> correction or manual recovery

Primary owners:

PROC-BMS-TRANSACTION-LIFECYCLE-CTC
PROC-BMS-AR-BILLING-CONFIRM-CTC
PROC-BMS-AR-QBO-DELIVERY-CTC
PROC-BMS-TRANSACTION-DOCUMENT-CTC
PROC-TMS-BOL-EMAIL-CTC
PROC-TMS-PACKING-LIST-EMAIL-CTC
PROC-BMS-BILLING-CLOSE-CTC

Local commit, provider success, readable file and user-visible close are independent checkpoints.

5. MK Order-First Value Streams¶

5.1 Commercial Agreement To Execution Children¶

Purchase / Sales agreement
-> Inbound and/or Outbound child
-> optional Booking and allocation

Primary owner: PROC-OMS-COMMERCIAL-ORDER-MK

Key open questions include status derivation, post-execution editing, role-by-command authority and relationship cardinality.

5.2 Purchase To Receipt And Inventory¶

Inbound Purchase
-> optional physical Scale
-> receipt / transload materialization
-> inventory lot
-> exact quantity, weight and placement readback

Primary owners:

PROC-OMS-INBOUND-PURCHASE-TO-INVENTORY-MK
conditional PROC-YMS-SCALE-TICKET-EXECUTION-MK

This value stream requires explicit separation between order state, physical ticket state and inventory materialization.

5.3 Inventory To Sales, Booking And Allocation¶

Outbound Sales demand
-> Booking / container context
-> inventory allocation
-> execution readiness

Primary owners:

PROC-OMS-OUTBOUND-SALES-ORDER-MK
PROC-TMS-BOOKING-LIFECYCLE-MK
PROC-OMS-INVENTORY-TO-OUTBOUND-ALLOCATION-MK

Major migration blockers include unsupported reversal, concurrent allocation, ambiguous booking compatibility effects and incomplete role/tenant evidence.

5.4 Conditional Scale And Physical Evidence¶

Scale is not a universal step. It is entered only when physical work requires it.

Primary owner: PROC-YMS-SCALE-TICKET-EXECUTION-MK

The process must distinguish:

item/order pre-save;
physical check-in;
physical check-out;
order or receipt finalization;
ticket output;
deletion/correction effects;
unknown-result recovery.

5.5 Cost, Trade And Document Outputs¶

Primary owners include:

PROC-BMS-OUTBOUND-ORDER-COST-MK
PROC-OMS-PACKING-RATE-CORRECTION-MK
PROC-OMS-TRADE-SUMMARY-RECONCILIATION-MK
PROC-TMS-PACKING-DOCUMENT-MK
PROC-BMS-PURCHASE-LOCAL-INVOICE-OUTPUT-MK
PROC-TMS-BOOKING-CONFIRMATION-OUTPUT-MK
PROC-BMS-SALES-WEIGHT-TICKET-OUTPUT-MK
PROC-OMS-EXPORT-BROKERAGE-MK

Most current output processes are projections or browser print flows, not durable document completion. Migration must not invent completion without a Product decision.

6. Shared Cross-Cutting Capabilities¶

These are not automatically separate business processes, but every process packet must account for them.

Capability	Required question
Authentication and actor	Who is acting, and how is impersonation represented?
Tenant/profile/capability	Which policy enables the behavior without numeric customer branching?
Stable identity	Which business ID/UUID supports exact readback and retry?
Files/documents	Is storage, link, output and deletion independently authoritative?
Provider effects	What is local commit, provider result, reconciliation and manual fallback?
Hardware/physical action	What can software prove versus what needs operator/device evidence?
Audit/correction	How are reopen, void, reversal and incomplete compensation represented?
Time and cadence	Which timezone, business date, schedule and escalation apply?
Role/menu/API	Does visible UI match command authorization for the target role?
Observability	Which event/log can prove outcome without exposing protected data?

7. Handoff Contract¶

Every cross-process handoff must state:

from process and completion evidence
carried stable IDs and context
to process entry condition
what is not implied
who owns the next action
how the receiver rereads authority
partial / duplicate / stale behavior
recovery when the receiver fails

A handoff does not transfer mutation authority. Page navigation does not prove completion. A later child failure does not roll back an earlier committed child unless a documented compensation exists.

8. Role, Cadence And Escalation Portfolio¶

The following is a portfolio skeleton, not an approved role matrix.

Operating responsibility	Typical role family	Cadence	Current documentation status
Request and appointment review	Office / Dispatch	continuous/daily	process documented; exact role matrix incomplete
Planning and assignment	Office / Dispatch / Loader lead	daily/shift	documented; command-role evidence incomplete
Loader execution	Forklift Operator	per job	documented; server-side parity gaps remain
Yard movement	Dispatch / Yard Driver	continuous	documented; concurrency/role evidence incomplete
Delivery execution	Truck Operator	per route/workday	documented; assigned-row authority gaps remain
Inventory/warehouse review	Office / Warehouse	daily/periodic	fragmented across several processes
Final loading/bale review	Office	daily/after completion	current operational candidate; registry disposition pending
Billing and provider close	Office / Accounting	daily/periodic	documented; provider/role acceptance incomplete
MK commercial/order flow	MK Office roles	per agreement/order	detailed source contracts; target roles incomplete
Management reconciliation	Administrator / Manager	daily/monthly	reports documented; completion/SLA ownership incomplete

P6-007 must replace assumptions with verified role, cadence, escalation and backup-owner facts or mark them UNKNOWN.

9. Migration Readiness Model¶

Use the readiness levels in PROCESS_MIGRATION_READINESS_EXTENSION.md.

Initial portfolio disposition¶

Process family	Initial readiness tendency	Reason
Read-only Wiki/manual/report surfaces	`M1-M2 candidate`	Low mutation risk, but role/freshness/query parity still required
Bounded master-data CRUD	`M1-M2 candidate`	Can become a reference after exact authority/caller inventory
Appointment and Inbound Planning	`M1-M2`	Detailed contracts, but role/retry/effect and compatibility gaps
Yard and Driver	`M1-M2`	Physical effects, partial completion and concurrency gaps
Inventory/Bale/Allocation	`M1-M2`	Ledger, balance, reversal and current-process-candidate gaps
Billing/QBO/email/files	`M1-M2`	Local/provider split and durable recovery must be proven
MK order children	`M1-M2`	Good source detail, incomplete target-role and concurrency acceptance
Composite processes	`M1`	Useful orchestration maps; child maturity controls migration readiness

No process is assigned M3+ by this document. P6-007 and the owning acceptance Tasks must supply actual evidence.

10. Per-Process Migration Packet¶

For every selected P12 wave, P6/P5/P7/P12 must produce one packet containing:

Section	Required content
Business identity	Process ID, outcome, profile, value stream, composite parent
Current operation	Roles, entry, normal path, exceptions, recovery, cadence
Authority	Record, state, mutation, transaction, effect and completion owners
Current runtime	PHP pages/APIs/helpers/jobs/tables/providers/files and callers
Target UI	React component tree, Client Component state, Tailwind and accessibility
Target Web	Next.js route/layout/Server Component/Route Handler/Server Action adapters
Target application	TypeScript commands, queries, policies, DTOs and errors
Target data	MySQL repository/transaction and exact readback
Target background	Worker/outbox/retry/reconciliation/manual recovery
Coexistence	One writer, routing selector, compatibility and rollback
Retirement	Static/runtime caller-zero, old URL behavior, file/helper removal
Acceptance	Role/tenant normal/negative/retry/recovery and observation
Knowledge	Process contract and Wiki/manual update/publication/readback

11. Wiki Projection Plan¶

The portfolio must project into user-facing knowledge at multiple levels.

Wiki layer	User question	Example current slug family
Profile overview	How does this company operate in CTC?	`overview`, `ctc-daily`, `mk-operations`
Role quick start	What am I responsible for today?	`roles`, role-specific sections
Value stream	How does work move end to end?	`ctc-daily`, `loader-yard`, `mk-operations`
Atomic procedure	How do I complete this exact job?	`inbound-planning`, `yard-dispatch`, `mk-booking`
Exception/recovery	What do I do after an error or uncertain result?	`errors-recovery` plus process pages
Reference	What do statuses and terms mean?	profile/process-specific reference sections

Repository mapping and draft preparation are owned by P8-001. Publication to T_WIKI_PAGE requires separate authorization, field review and readback.

12. Current Gap Register¶

P6-007 must reconcile at least the following.

Revalidate process count, versions and registry last_updated against the current revision.
Disposition Final Loading/Bale Review as a process or bounded compatibility flow.
Reconcile current L2L/BAL TRK behavior with Inventory/Inbound/Transload process owners.
Resolve version drift between registry and Wiki crosswalk where present.
Build an exact CTC and MK value-stream-to-child matrix.
Identify missing operational process candidates and obsolete registry entries.
Name role/cadence/escalation owners or retain explicit unknowns.
Classify each process by M0-M5 migration readiness.
Select the first bounded P12 read-only and transactional process candidates.
Build the process-to-Wiki content coverage map, not only slug linkage.
Define lifecycle promotion candidates and blocking evidence.
Ensure every recent Operational Delivery handover has a process-impact disposition.

13. Update And Acceptance Rules¶

P6-007 is the current owner of portfolio reconciliation.
Individual process files remain the semantic authority.
The registry is updated only when exact process metadata changes.
This portfolio is updated when hierarchy, composition, readiness or major gaps change.
P8 updates user-facing projections after process meaning is stable enough for the target audience.
P12 cannot treat an undocumented route as the migration unit.
Process lifecycle and migration readiness remain distinct.
No process becomes approved, M3, M4 or M5 from repository review alone.

14. Initial Completion State¶

portfolio hierarchy: INITIAL DRAFT ESTABLISHED
registered process reconciliation at current revision: NOT COMPLETE
unregistered candidate review: NOT COMPLETE
role/cadence/escalation matrix: PARTIAL / MOSTLY UNKNOWN
migration readiness scoring: INITIAL TENDENCY ONLY
Wiki content coverage: NOT COMPLETE
process lifecycle promotion: NONE
Runtime/DB/Wiki publication effects: NONE AUTHORIZED

---¶

Source: docs/processes/OPERATING_MODEL_PROCESS_PORTFOLIO_AND_MIGRATION_MAP.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.