Skip to content

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

  1. identify the question and required evidence;
  2. inventory relevant pages, APIs, jobs, tables and integrations;
  3. trace normal, negative, duplicate, timeout, correction and recovery paths;
  4. identify record, state, command, query and effect owners;
  5. separate confirmed facts, inference, unknowns and conflicts;
  6. draft or update the narrative Process contract;
  7. update structured relations under catalog/processes/**;
  8. independently verify unsupported claims;
  9. 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.