Process Reconstruction Standard¶
- Status:
CANONICAL - Structured registry:
../../catalog/processes/ - Live execution:
../EXECUTION.md
This standard reconstructs business meaning from current evidence without promoting accidental Legacy code structure, a design artifact or an old Task plan into Product policy.
1. Levels¶
L0 Operating Model
L1 Value Stream
L2 Composite Process
L3 Atomic Process
L4 Command / Query / Event
L5 Runtime Adapter
A page, endpoint, table, function, folder or prototype is not a Process by itself.
2. Evidence Classes¶
current source and tests
current DB/schema/data evidence
current Wiki/runbook
operator and role observation
logs, provider and device evidence
approved Product/design direction
accepted target decision
Evidence classes are not interchangeable. Design cannot prove business meaning; source review cannot prove physical completion or target-role acceptance.
3. Lifecycle¶
CANDIDATE
SOURCE_MAPPED
SOURCE_RECONCILED
OPERATIONALLY_VERIFIED
TARGET_APPROVED
IMPLEMENTED
TARGET_ROLE_VERIFIED
STABILIZED
RETIRED
UNKNOWN and CONFLICT remain explicit facts. They are never silently converted into lifecycle
promotion.
4. Required Process Contract¶
A Process contract records only material semantics:
- stable semantic ID, version, level and owner;
- profiles, capabilities, policies and persisted facts;
- purpose, trigger, actors, preconditions and completion meaning;
- authoritative records and identity carried between handoffs;
- independent states and transitions;
- commands, queries and events;
- transaction, provider and physical-effect boundaries;
- duplicate, concurrency, timeout and unknown-result behavior;
- correction, reversal, retry, recovery and reconciliation;
- UI/readback implications and current/target adapters;
- sources, freshness, confidence, conflicts and unknowns;
- migration readiness and retirement conditions.
Do not create sections with no current content merely to satisfy a template.
5. Current And Target Separation¶
Keep the following distinct:
current confirmed behavior
current inferred or unknown behavior
approved Product/design input
target proposed or accepted behavior
migration/coexistence mapping
exact consuming Task
Target architecture does not rewrite current facts. Current accidental code does not automatically become target policy.
6. Tenant And Profile Variation¶
Represent variation as:
shared semantic Process
+ capability enablement
+ typed policy
+ persisted record facts
+ profile-specific composition
Do not create customer-specific Process copies unless an accepted decision proves different business meaning.
7. Reconstruction Workflow¶
- identify the question and required evidence;
- inventory relevant pages, APIs, jobs, tables and integrations;
- trace normal, negative, duplicate, timeout, correction and recovery paths;
- identify record, state, command, query and effect owners;
- separate confirmed facts, inference, unknowns and conflicts;
- draft or update the narrative Process contract;
- update structured relations under
catalog/processes/**; - independently verify unsupported claims;
- hand only the exact unresolved implementation work to the consuming Task.
8. Authority Boundary¶
catalog/processes/**
→ stable IDs, lifecycle, ownership and structured relations
docs/processes/**
→ human-readable Process meaning and source-reconciled evidence
PRODUCT_REALITY.md
→ current capability disposition and evidence
EXECUTION.md + exact Task/manifest
→ current work, paths and effects
catalog/processes/** is the only structured Process index. It does not own implementation status
or execution order.
9. Implementation Gate¶
A mutating implementation may consume a Process only when the semantics required by that change are accepted or directly resolved in the exact authorized Task. Unrelated unknowns do not block bounded work, but a required unknown cannot be replaced with a plausible default.
10. Verification Questions¶
- What triggers and completes the Process?
- Which actor and record owns each transition?
- What does completion not imply?
- What happens on duplicate, timeout or partial result?
- How are correction and reversal represented?
- What is the authoritative readback?
- Which provider or physical result is separate?
- Which variations are policy/fact rather than a different Process?
- Which claims remain unknown or conflicting?
11. Initial Discovery Coverage¶
This section absorbs the original 2026-08-15 candidate inventory's omission checks, not its obsolete NS0 progress table. The ten-family order remains in the historical reconstruction Task; current work is selected from EXECUTION. CTC/MK were that discovery's initial cohorts; YP, Export Brokerage, Doortrade and other discovered families were deferred inputs, not newly activated scope. Do not infer current capability status or client applicability from those initial labels.
| Discovery family | Semantics to account for when the selected reconstruction includes it |
|---|---|
| Platform and master data | strict/compatibility tenant context; profile/module/capability/policy; access/audit/files; Party, Material, UOM and Location |
| Commercial, service, Booking and Fulfillment | Commercial Agreement; service/appointment intake; Ocean Booking; explicit Fulfillment/source linkage |
| Operations | Transload Plan; Assignment; Field Execution; Office Confirmation; correction/reconciliation |
| Scale | Weigh Session; Scale Reading; Scale Ticket; correction/void; Weight Allocation |
| Inventory | Receipt; Inventory Lot; Ledger/Balance; Placement; Cost Layer; Allocation; correction/reconciliation |
| Transportation | Shipment; Transport Leg; Internal Dispatch; external carrier reference/milestone; customer-owned leg; proof/recovery |
| Equipment lifecycle | Container/Chassis assignment; yard position; availability/loading/dispatch; port return; closure/correction |
| Settlement | CTC Service Charge; MK Purchase/Sales Settlement; Landed Cost; Trade Margin; accounting handoff |
| Documents and providers | Booking/Packing/BOL/Weight/Invoice documents; files; email/messaging; accounting; AI extraction; jobs/retry/reconciliation |
The original cross-profile checks remain reconstruction inputs, not a universal test pack or proof of completed acceptance. Select applicable cases in the exact Task; do not create new policy from them.
| Original cohort | Retained scenario questions |
|---|---|
| CTC | service/appointment → Fulfillment; Booking → planning without implicit completion; Loader/Transload/internal delivery; yard/container return; custody/leftover inventory; service-charge evidence |
| MK | Commercial Agreement → execution order; Booking/source linkage; receipt → owned lot/cost; Allocation → outbound demand; external carrier reference/milestones; Office-confirmed execution/weight; trade margin |
| Composition | MK internal trucking without a source fork; CTC commercial trading/mixed settlement; record facts over profile defaults; profile-version changes do not rewrite history; shipment delivery does not close container return |
Reconstruction index routes source families. The existing structured Process catalog owns IDs and relations; this checklist does not duplicate its lifecycle values.
---¶
Source:
new-system/docs/processes/PROCESS_RECONSTRUCTION_STANDARD.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.