PF_MULTI_003 — Production work-order reflow with inspectable planned-date changes
This proof tests one bounded workflow: a synthetic open work order with no time logged or recorded dependency has a planned start earlier than its linked manufacturing order's future manufacturing-order date. Run the explicit Reflow Work Orders action and inspect whether the work order moves forward from its recorded before state. The buyer determines whether the resulting reflow is correctly set. Direct planned-date editing and maintenance-block creation are explicitly excluded.
kind: proof_catalog
schema_version: 2
proofs:
- id: PF_MULTI_003
vertical_ids:
- M1_V1
- M1_V2
- M1_V3
- M1_V4
- M1_V5
- M1_V6
- M1_V7
name: 'Production work-order reflow with inspectable planned-date changes'
status: approved
proof_type: 'workflow test'
safe_artifact: >-
One synthetic, non-sensitive test schedule containing at least one work
order with data.status set to open, no logged time, an empty
data.workOrderDependencyIds array, and recorded data.workOrderNumber,
data.workCenterId, data.plannedStartDate, and data.plannedEndDate. Its
linked manufacturing order has a future data.manufacturingOrderDate later
than the work order's initial plannedStartDate and may separately carry
data.productionDueDate. The assigned work center is active and has
maintained capacity data. No live customer data or overlapping maintenance
block is used.
procedure:
- >-
From the Work Order Timeline and the work order's Details or View path,
record its work-order number, assigned work center, status, planned start
date, and planned end date before reflow.
- >-
Inspect the linked manufacturing order and record its
manufacturingOrderDate and, when present, productionDueDate. Confirm
that manufacturingOrderDate is in the future and later than the work
order's initial plannedStartDate.
- >-
Confirm that the representative work order is open, has no logged time,
and has no workOrderDependencyIds. Confirm that its assigned work center
is active.
- >-
From the Work Order Timeline, run the separate explicit Reflow Work
Orders action. Do not directly edit the work order's dates and do not
create an overlapping maintenance block during this proof.
- >-
Refresh the Work Order Timeline and reopen Details or View Work Order.
Record the resulting planned start and planned end dates for the same
work order.
- >-
Compare the before-and-after dates and ask the buyer to determine whether
the resulting reflow is correctly set for the representative test.
expected_observation: >-
After the explicit reflow action, the eligible open work order has a
visible plannedStartDate different from its recorded before value and no
earlier than its linked manufacturing order's manufacturingOrderDate. Its
resulting plannedEndDate remains inspectable through the work-order detail
path. Direct planned-date editing is not used or demonstrated.
acceptance_criterion: >-
For the representative synthetic schedule, Reflow Work Orders completes;
the eligible open work order's resulting plannedStartDate differs from its
before value and is on or after the linked manufacturing order's future
manufacturingOrderDate; its plannedEndDate is visible and is not earlier
than its plannedStartDate; and the buyer confirms that the resulting
reflow is correctly set.
owner: sales
capability_boundaries:
- >-
This proof demonstrates only explicit active-schedule reflow under
S_00005. Direct work-order date editing belongs to P_00008 and S_00007
and is excluded.
- >-
Work-order fields used by the proof are data.workOrderNumber,
data.workCenterId, data.plannedStartDate, data.plannedEndDate,
data.workOrderDependencyIds, and data.status. The scheduling anchor is
the linked manufacturing order's data.manufacturingOrderDate;
data.productionDueDate is a separate manufacturing-order field. No
data.requiredDate field exists on manufacturing/workOrder.
- >-
MCP server d8189168 verifies the Work Order Timeline, explicit Reflow
Work Orders action and event, work-order and manufacturing-order
relationships, forward-reflow hook, dependency handling, planned-date
updates, capacity and maintenance inputs, and locking of in-progress and
maintenance work. MCP does not establish a customer result or acceptance
decision.
- >-
Only forward scheduling is demonstrated. This proof does not demonstrate
backward scheduling or scheduling from productionDueDate.
- >-
The reflow implementation uses a confirmed hardcoded 24/7 default.
Tenant work-shift integration was not established and must be separately
verified before relying on multi-shift or non-continuous-calendar
behavior.
- >-
In-progress and maintenance work orders are locked by the reflow
implementation. This proof uses one open work order with no logged time
and does not test preservation of started work.
- >-
The reflow implementation supports workOrderDependencyIds, but this
bounded fixture has no dependencies and does not test dependency-chain
correctness.
- >-
Maintenance work orders can block a work center, but their creation path
rejects a window overlapping existing work and asks the user to move the
conflict manually. This proof therefore does not create an overlapping
maintenance block as its changed condition.
- >-
The generated arrangement remains subject to planner review and
correction. This proof does not demonstrate autonomous or review-free
scheduling.
- >-
The buyer-interview evidence covers 25 production manufacturer accounts
across M1_V1 through M1_V7 over one year, but exact account identities,
account descriptions, calendar dates, per-vertical observation counts,
representative before-and-after values, and changed constraints were
not supplied.
- >-
This proof does not establish initial work-order generation, compatible
work-center assignment or load-balanced scoring, global schedule
optimality, freight or transportation optimization, preventive or
predictive maintenance, or feasible placement for every unslotted order.
- >-
No quantified changeover, utilization, freight, output, margin, delivery,
productivity, throughput, latency, concurrency, or time-saving
improvement is measured or claimed.
transfer:
level: prohibited
from_vertical_ids: []
conditions:
- >-
Use is limited to M1_V1, M1_V2, M1_V3, M1_V4, M1_V5, M1_V6, and
M1_V7. Any unlisted or future destination requires separately
validated evidence and an explicit applicable canonical transfer
rule.
evidence_ids:
- EV_PRODUCT_005
- EV_MULTI_005