PF_MULTI_006 — Reconcilable production-cost comparison across completed run quantities
This proof tests one bounded set of completed manufacturing orders for a single item at one work site, over a buyer-declared window of at least six months during which the module-level manufacturing costing strategy did not change. It requires at least two completed orders whose ordered quantities differ by a buyer-declared factor, requires each inspected row's planned cost, total cost, and cost per unit to reconcile to its source manufacturing order, requires recalculation to reproduce those values, and requires a named planner to confirm the comparison is sufficient as one input to a production-quantity decision. It does not establish expected stock value, inventory carrying cost, total economic cost, expected scrap for a candidate quantity, or a preferred batch size.
kind: proof_catalog
schema_version: 2
proofs:
- id: PF_MULTI_006
vertical_ids:
- M1_V1
- M1_V2
- M1_V3
- M1_V4
- M1_V5
- M1_V6
- M1_V7
name: 'Reconcilable production-cost comparison across completed run quantities'
status: approved
proof_type: 'dataset test'
safe_artifact: >-
One sanitized set of completed manufacturing orders for a single generic
item and variant at one work site, covering a buyer-declared window of at
least six months and containing at least two materially different ordered
quantities. Each order carries its ordered quantity, quantity completed,
planned cost, total cost, cost of scrap, and actual bill-of-material
lines. The set records the module-level manufacturing costing strategy in
force for the whole window. No customer identity, selling price, margin,
or customer financial data is required, and no live customer database
access is required.
procedure:
- >-
Record the module-level manufacturing costing strategy in force and
confirm it was unchanged for the whole declared window. The setting is
module-level rather than per order, so a change inside the window
invalidates the comparison.
- >-
Declare the comparison scope before inspecting any cost: item and
variant, work centers and routing, warehouse and work site, the window,
the minimum qualifying order count, and what counts as comparable
operating conditions.
- >-
Filter manufacturing orders to status completed for the declared item
and window, and record how many qualifying orders exist at each ordered
quantity.
- >-
In the manufacturing orders table with pivoting, inspect each qualifying
order's order date, item name, status, total quantity, produced
quantity, overproduction, planned cost, planned cost per unit, total
cost, cost per unit, raw material cost, and scrap rate in one
cross-order view.
- >-
For at least two qualifying orders at materially different ordered
quantities, open each order and reconcile the displayed planned cost,
total cost, and cost per unit to that order's own planned cost, total
cost, cost of scrap, and actual bill-of-material lines, including the
consumption-variance classification on each line.
- >-
Recalculate manufacturing-order cost for those orders and confirm the
recalculated planned cost, total cost, and cost per unit reproduce the
values already inspected.
- >-
Record every difference between the compared orders in material, labor,
routing, equipment, product specification, or costing configuration, and
state which comparisons those differences disqualify.
- >-
Label the result a production-cost comparison and record that expected
stock value, inventory carrying cost, and total economic cost are absent
from it.
- >-
Have a named planner review the comparison and confirm in writing whether
it is sufficient to be one input to a production-quantity decision.
expected_observation: >-
One cross-order view for the declared item, window, and unchanged costing
strategy exposes each completed order's quantity, planned cost, planned
cost per unit, total cost, cost per unit, raw material cost, and scrap
rate; each inspected row reconciles to its source manufacturing order;
recalculation reproduces the same values; and the view is labeled a
production-cost comparison carrying no expected stock value, inventory
carrying cost, or total economic cost.
acceptance_criterion: >-
For the declared item and work site, over a buyer-declared window of at
least six months of completed manufacturing orders during which the
module-level manufacturing costing strategy was unchanged, the comparison
contains at least two completed orders whose ordered quantities differ by
at least a buyer-declared factor; every inspected row's planned cost, total
cost, and cost per unit reconciles to its source manufacturing order within
a buyer-declared tolerance; recalculating manufacturing-order cost
reproduces the same values; and a named planner confirms in writing that
the comparison is sufficient to be one input to a production-quantity
decision. The criterion is not met if the comparison is presented as
identifying the preferred or optimal batch size, or as a total economic
cost.
owner: COO
capability_boundaries:
- >-
The account context for this proof is a single-site industrial
manufacturer of 20 to 100 employees. No customer has executed this test,
so there is no calendar observation period and no observed result. The
window is declared by the buyer at execution.
- >-
MCP server d8189168 grounds the manufacturing-order cost fields, the
completed status, the consumption-variance classification, the
cross-order pivoting table columns, the six costing strategies, and the
cost-recalculation rules. It does not establish that any customer ran
this comparison or accepted its result.
- >-
The manufacturing costing strategy is module-level and has six values.
Three of the six include scrap cost and three exclude it, so the strategy
in force determines whether scrap is inside cost per unit at all.
Comparing orders across a strategy change is not a valid comparison.
- >-
Cost values depend on complete recording of production reports, work
orders, time tickets, material consumption, labor, and scrap. The
calculation resets all accumulators and rebuilds from those records, and
a zero variant cost rejects the calculation outright.
- >-
The pivoting table's verified columns include total quantity, produced
quantity, and quantity. The mapping of a specific column to the
document-level orderedQuantity field was not verified, so the ordered
quantity used for grouping must be confirmed against the manufacturing
order before the comparison is trusted.
- >-
No native production-cost-by-run-quantity or batch-size comparison report
was found in the manufacturing-reports collection. The comparison depends
on the pivoting table's grouping configuration, which was not executed
during authoring, so its configuration and testing effort cannot be
sized.
- >-
No expected-stock valuation, inventory carrying-cost, or
economic-order-quantity implementation was found. That is an unverified
result rather than proof of absence, and it must not be presented as
shipped, configured, or on the roadmap.
- >-
Expected scrap for a candidate future quantity is not established by this
proof. Converting completed-order scrap history into an expected value
remains a customer-defined derivation, and no native expected-scrap model
was verified.
- >-
EV_PRODUCT_002 and EV_PRODUCT_006 are product-surface internal_validation
records that carry no vertical scope of their own. Listing all seven
verticals rests on the costing engine being vertical-neutral. The vertical
catalog states that shared material or end-market context cannot transfer
production behavior, and no evidence establishes that a batch-quantity
cost comparison is directly applicable in each listed vertical.
- >-
Confirmed sales-order demand and current stock quantity are deliberately
out of scope for this proof, so nothing here can be read as expected
stock value.
- >-
This proof does not measure expected stock value, inventory carrying
cost, total economic cost, expected scrap for a candidate quantity, the
preferred or optimal batch size, future run behavior after any
engineering or process change, any quantified saving or scrap reduction
or return on investment, production-queue behavior, labor savings, or
implementation effort.
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.
Every canonical proof-transfer rule in the vertical catalog declares
from_vertical_id M1_V1 only, so no incoming rule authorizes an unlisted
destination from this proof. Any unlisted or future vertical requires
separately validated evidence and an explicit applicable canonical
transfer rule.
evidence_ids:
- EV_PRODUCT_002
- EV_PRODUCT_006
Duplicate review
The closest existing record was PF_MULTI_002, which shares the manufacturing
costing engine and the EV_PRODUCT_002 evidence record. That proof compares one
order to its own plan across a single order lifecycle, grouped by warehouse and
work center. This proof compares several already-completed orders against each
other by run quantity, constrains the costing strategy across a declared window,
and requires scrap rate per compared order. The duplicate review therefore found
moderate overlap on the calculation and approved a materially distinct record.
Outstanding
P_00013has no customer-side evidence. The problem'sevidence_idsis empty and its supporting call remains a provisional inbox item.W9must create acall_learningrecord before the mismatch is treated as an externally supported claim.- Vertical breadth is not evidenced per vertical. Both cited evidence records are product-surface observations with no vertical scope. The listing of all seven verticals was an explicit authoring decision on 2026-08-02 and is recorded as a capability boundary rather than as an evidenced scope.
S_00012capabilityevidence_idsremain empty.EV_PRODUCT_006supports several of those capabilities, but adding it is a solution-record edit outside this workflow's write scope. Route it throughW13.S_00012capability 3 references a sales-order status the product does not have.sales/order.data.statushas noconfirmedvalue; confirmation is expressed throughacknowledgedorin-process, or through the separate invoice and shipping status datatypes. Demand is out of scope here, so this does not affect the proof, but the solution wording needs aW13correction.- The comparison has never been executed. Before use, fix the item, variant, work centers, warehouse, window, minimum order count, the ordered quantity factor, and the reconciliation tolerance.
status: approvedwas set by explicit authoring decision. Thecreate-proofrule writes new proofs asapproved; the user directedapprovedon 2026-08-02 for consistency with the sibling proof records. Lifecycle review is still required after execution and evidence review.