Commitments & allocation
Pegging
The trace that links a quantity of demand to the supply, capacity, or planned action intended to cover it - and back to the demand claims consuming each supply element.
Operator definition
A plan should never stop at "covered." It should be able to show covered by what.
Pegging creates that causal connection. A customer order may be pegged to on-hand inventory, a purchase order, a transfer, a production order, or a chain of component and capacity actions. A planned supply order may in turn be pegged to one or many demand requirements.
Good pegging is often many-to-many and time-phased. It reveals not only coverage but competition: which demands are drawing from the same receipt, which component shortage blocks a finished item, and which planned action would become unnecessary if the causal demand disappeared.
Why it matters
Without pegging, planners can see a shortage but cannot explain it. They can see an expedite recommendation but cannot identify the demand that caused it. They can see an inbound order but cannot tell which commitment will fail if it slips.
Pegging makes a planning recommendation inspectable. It also improves change control. If a priority changes or a receipt moves, the system can show which demand paths are affected rather than asking the operator to infer the blast radius from totals.
The planning physics
A pegging graph can be represented as weighted edges:
Demand node d <- quantity q -> Supply or action node s
For each edge:
0 <= q(d, s) <= min(uncovered demand d, eligible supply s)
The edge should also carry dates, location, priority, state, and reason. In a multi-level bill of material, the graph may continue through component and resource dependencies. A useful trace also records its authority state: generated by a plan run, protected by policy, reserved by execution, or committed by an approved promise.
Pegging order matters. FIFO, priority, due date, reservation, firm status, and other rules can produce different valid graphs from the same aggregate quantities. The engine should therefore disclose the rule set rather than treating the graph as an obvious physical fact.
Simple example - pegging trace
Demand due in Week 4: Order A needs 80 units at priority 1. Order B needs 70 units at priority 2. Eligible supply is 50 on hand, purchase order P1 for 60 units in Week 3, and purchase order P2 for 100 units in Week 5.
A due-date and priority rule creates this trace:
The trace explains coverage, competition, and the timing shortage.
Order A consumes 50 on hand and 30 from P1. Order B consumes the remaining 30 from P1 and still has a 40-unit Week 4 gap because P2 arrives in Week 5.
| Demand | Supply or action | Quantity | Reason | State |
|---|---|---|---|---|
| Order A 80 / W4 / prio 1 | On hand | 50 | Earliest eligible supply under due-date and priority rule. | Generated planning peg |
| Order A 80 / W4 / prio 1 | Purchase order P1, Week 3 | 30 | Arrives before the Week 4 need date. | Generated planning peg |
| Order B 70 / W4 / prio 2 | Purchase order P1, Week 3 | 30 | Remaining eligible receipt after higher-priority demand is covered. | Generated planning peg |
| Order B 70 / W4 / prio 2 | Required action by Week 4 | 40 shortage | No eligible supply remains before the need date. | Planning exception |
| Order B late alternative | Purchase order P2, Week 5 | 0 pegged | Late against Week 4 demand, despite aggregate surplus. | Excluded alternative |
A dashboard that totals all supply would show 210 units against 150 units of demand. Pegging makes the 40-unit timing shortage visible.
What goes wrong without it
- Aggregate supply masks time-phased shortages.
- Expedites cannot be tied to the demand that justifies their cost.
- A delayed receipt has no visible impact chain.
- Planners cannot distinguish a true material shortage from a policy exclusion.
- Cancellation leaves unnecessary planned orders in place.
- Explanations become generic narratives instead of evidence-backed traces.
How it shows up in high-consequence supply chains
Pegging can link a lot to a named patient, a blood component to a procedure, a qualified spare to a safety function, or a shipment to a country program. The trace must preserve identity and eligibility, not merely quantity. In some settings, the peg itself may be a protected claim that cannot be reassigned without approval.
A high-consequence trace should also show why visible alternatives were rejected: incompatible, unreleased, expired, unqualified, too late, already committed, or outside the approved route. It should make status visible too: informational planning peg, protected allocation, hard reservation, or committed promise. Those states should not blur together.
Common confusion
Pegging is not automatically the same as a reservation or legal commitment. A dynamic planning peg may change when the plan reruns. A protected peg should require policy or authority to change. A hard reservation or promise should advance through an explicit commitment transition.
Pegging also is not absolute proof that the plan is right. It is the engine's declared coverage relationship under its rules and current context. Its value depends on the correctness of those rules and the quality of the accepted state.
| Planning peg | A generated coverage relationship under the current run and rule set. It may move on the next run. |
|---|---|
| Protected peg | A policy-protected claim whose reassignment requires authority. |
| Reservation | An execution-created hold on specific supply or quantity for a demand. |
| Promise | An approved external commitment that should advance through a controlled transition. |
Vista point of view
Vista's view is that pegging is the evidence layer between a plan and an action. It should not be a hidden engine artifact or a static report. It is the operator's way to ask what depends on this supply, what supply supports this demand, what changed since the last run, and what would be displaced if the peg is reassigned.
Established planning practice already treats pegging as demand-source and supply-demand traceability. Vista's distinction is to make that trace durable enough for governed action: tied to plan run, rule version, eligibility filters, commitment state, exclusions, and alternatives.
The payoff is not only explanation. Better pegging lets teams learn why shortages recur, find root causes faster, protect the right commitments, avoid unnecessary expedites, and negotiate tradeoffs with a visible impact chain. Explanation without that evidence is narration, not proof.
Sources Reviewed 22 June 2026
- Jacobs, Berry, Whybark, and Vollmann treat pegging as a material requirements planning topic within manufacturing planning and control; the table of contents places pegging under MRP technical issues: Manufacturing Planning and Control for Supply Chain Management, 6th ed..
- ASCM/APICS includes resolving conflicts through pegging relationships in material planning competence for CPIM candidates: CPIM Exam Content Manual.
- Oracle's FIFO pegging documentation is implementation evidence for bidirectional demand-supply links and rule-dependent sorting: How FIFO Pegging Is Used in Supply Chain Planning.
- Oracle's reservations documentation is implementation evidence for many-to-one and one-to-many pegged quantities, and for distinguishing planning display from execution-created reservation: Reservations in Supply Chain Planning.
- Pegging order, stability, and authority state are implementation-dependent; vendor documentation is evidence of documented product behavior, not proof of one universal architecture.