Traceability & governance
Commitment ledger
A planning record of recognized claims on future supply or capacity: what was protected, who owns it, what authority created it, what supply supports it, and how it later changed.
Operator definition
Inventory does not have to leave a warehouse to become unavailable. A promise can consume it first.
Suppose 500 units are due next month. A planner allocates 300 to a hospital. A sales system then promises 400 to a customer. Each decision may look valid inside its own system. Together, they create 700 units of claims against 500 units of expected supply.
Nothing has shipped. But the plan already contains a contradiction.
A commitment is a recognized claim that restricts how future supply or capacity may be used by competing demand. A commitment ledger records those claims: what was protected, who owns it, what authority created it, what supply supports it, and how it later changed.
It does not replace ERP orders, warehouse reservations, production schedules, or order-management systems. Those systems often protect commitments within their own boundaries. The problem appears when claims cross systems, use different states, or carry planning meaning that no single system can see.
Supply is not the same as availability
Supply records tell the organization what may exist. Commitment records tell it which part of that future is no longer open to competing demand.
Availability is not one universal number. It answers a particular request: available for whom, where, when, for what use, and under which policy?
Supply allocated to Hospital A may be unavailable to Customer B while remaining available to Hospital A. A country allocation may be protected by donor policy. A unit may be reserved for a named patient or mission.
For a defined request:
Free promiseable supply = usable supply - authoritative active claims that apply to that request
Those claims may include reservations, approved allocations, accepted promises, and other protected uses. Several systems may hold records for the same underlying promise, so the ledger must connect them into one commitment history rather than subtracting each as a separate claim.
A commitment is a history, not a field
A commitment is a sequence of events.
A claim may begin as a proposal, become a temporary hold or approved allocation, enter execution, be partly consumed, and later be cancelled or replaced.
Different states protect the future differently. A scenario changes no baseline availability. A temporary hold may protect supply for a limited time. A firm allocation excludes competing demand until an authorized release.
A minimal commitment event might record:
commitment and event IDitem, resource, quantity, and locationrequired date or promise datedemand owner and priorityprior state -> new stateauthority and policy versionsupporting supply and source plan runtransaction and effective timereason, evidence, and replacement link
Later events supersede earlier ones rather than erasing them. The ledger preserves the history; the planning system derives the current commitment state and calculates what remains available.
The commitment must be protected when it is created
A ledger does not prevent overcommitment if two users can claim the same supply at the same time.
The availability check and acceptance of the claim must behave as one protected operation:
validate availability + create commitment = one protected operation
Another request must not be able to consume the same option between those steps. The implementation may span several systems, but each type of claim must have a named source of authority. A copied record received after the decision can support audit, but it cannot prevent overcommitment.
A simple example
An inbound receipt of 500 units is expected on July 15.
The ledger keeps future claims conserved.
The 500-unit receipt can support the 300-unit Hospital A allocation and only 200 of the 400-unit Customer B request. The remaining 200 moves to CTP or exception handling.
| Time | Event | Free promiseable | Planning meaning |
|---|---|---|---|
| 08:45 | candidateReceipt of 500 admitted into the plansource: plan run PR-1043 | 500 | Supply exists as a future option. No demand owns it yet. |
| 09:00 | allocationPlanner allocates 300 to Hospital Aauthority: critical-care policy P-14 | 200 | 300 is protected from competing demand but remains usable for Hospital A. |
| 09:03 | promiseCustomer B requests 400tool: order promising | 200 | The transaction validates free supply before creating the promise. |
| 09:03 | split resultPromise 200; leave 200 uncoveredstate: accepted promise plus uncovered request | 0 | The rejected portion is evidence, not friction. It prevents a false promise and routes the remainder to CTP or an exception workflow. |
| 11:30 | supersessionHospital A allocation reduced by 50 after approvalauthority: same policy owner | 50 | 50 returns only after a governed state transition. The prior claim is not deleted; it is superseded. |
Without shared commitment state, Hospital A and Customer B may both believe they own the same units. With the ledger, Hospital A's allocation reduces the quantity available to Customer B before the promise is accepted.
The uncovered 200 is evidence, not friction. It shows where the organization must add supply, move a date, use a substitute, increase capacity, or make an exception.
When the supporting supply changes
A receipt may arrive late, arrive partially, fail inspection, or disappear. A production line may lose capacity.
A commitment should retain the supply, capacity, or assumption expected to support it. If that support changes, the system can identify which commitments are exposed and which decisions must be revisited.
What goes wrong without it
Without a governed commitment record:
- Availability and reservation records disagree.
- A scenario leaks into the approved plan.
- Released orders are still treated as optional.
- Supply is reallocated without notifying its owner.
- Cancellations restore supply in one system but not another.
- Two users promise the same receipt.
- One promise is counted several times across systems.
- The audit trail shows a change but not its planning meaning.
The failure test is simple:
High-consequence commitments
A claim may belong to a named patient, a clinical-trial site, a donor-funded country program, a military mission, or a grid-restoration site. Reassignment may have clinical, ethical, contractual, or mission consequences.
The ledger must therefore preserve more than quantity. It must preserve identity, eligibility, priority, authority, supporting supply, and the claim that would be displaced. A consequential cancellation should create a visible, reasoned transition, not delete history.
What a commitment ledger is not
| General ledger | An accounting record. A commitment ledger records claims on future supply, not financial postings. |
|---|---|
| Audit table | An audit table shows that a record changed; a commitment ledger records the planning meaning, authority, and affected claim. |
| Reservation | A reservation is one state within a history that may also include proposals, holds, allocations, promises, releases, consumption, cancellations, and replacements. |
| Forecast | A forecast is evidence of possible demand. It should not consume supply unless policy turns it into a protected claim. |
The design question is:
Vista's point of view
Promises consume the future. Planning platforms should therefore treat commitment state as fundamental, alongside demand and supply.
Vista connects each claim to five things: the demand that owns it, the supply or capacity expected to support it, the policy that protects it, the authority that approved it, and the decision history by which it changed.
That lets a planner see not only that supply is committed, but why, who may change it, what would be displaced, and which promises become exposed when the underlying supply changes.
The planning engine calculates what remains possible. The commitment ledger records which possibilities have become protected claims.
Agents may identify an exposed commitment, compare reallocation options, and prepare an approval package. They should not quietly release Hospital A's allocation so that Customer B's order can pass.
A calculation can recommend what should happen. Only an authorized commitment transition makes that decision binding in the plan.
Supply describes the future the organization expects. Commitments describe the future it has already given away.
The commitment ledger is a Vista proposal built on established reservation, allocation, concurrency, and audit practice. It is not yet an industry standard.
Sources Reviewed 14 July 2026
- Microsoft preview documentation describes preserving supply, routes, capacity reservations, and pegging for confirmed demand as an implementation pattern: Keep supply for confirmed demand.
- Oracle documents reservations as planning-relevant supply and demand relationships: Reservations in Supply Chain Planning.
- Secure, time-stamped audit-trail principles in regulated electronic records support append-only decision history where applicable: 21 CFR Part 11.
- The unified commitment ledger is a Vista design proposition requiring cross-sector validation, not an established industry standard.