Commitment ledger

A proposed planning record that preserves every event by which future supply or capacity is reserved, allocated, promised, released, consumed, cancelled, or superseded.

Operator definition

The future can be double-booked long before physical inventory leaves a warehouse.

A sales promise, production slot, transfer reservation, hospital allocation, patient assignment, country quota, or mission reserve can all consume the same future option. If those claims live in different systems or spreadsheets, each team can appear correct while the enterprise has promised more than it can deliver.

A commitment ledger is Vista's proposed core object for preventing that failure. It records the dated quantity or capacity claimed, the demand that owns the claim, the state of the claim, the authority behind it, and every later transition. It does not replace ERP orders or warehouse reservations. It joins their planning meaning into one governed history.

Why it matters

Planning answers what should happen. Commitments determine what the organization has already obligated itself to do.

A commitment ledger lets a planner distinguish supply that is physically usable from supply that is still free. It lets an order-promising service transact atomically rather than reading availability from one moment and writing the promise later after another user has consumed it. It also gives teams a shared language for proposed, approved, firmed, released, reserved, allocated, promised, consumed, cancelled, and superseded states.

The result is not merely defensive. Reliable commitment state lets the business say yes faster because it knows which future options remain open.

The planning physics

Epistemic status: Vista architecture proposal synthesized from established reservation, allocation, order, and audit practices. "Commitment ledger" is not presented as a universally standardized supply-chain object.

A minimal append-only event might contain:

commitment_event_id
item / capacity / resource
quantity and unit
location or path
required or promise date
demand owner and priority
prior state -> new state
authority and policy version
source plan run and pegging
transaction time and effective time
reason, evidence, supersession link

Free promiseable supply
  = usable supply
  - active reservations
  - active allocations
  - accepted promises
  - protected claims

The relationship is demand-relative. A reservation is unavailable to competing demand but remains usable for the demand that owns it. Cancellation or supersession returns the quantity only after the governed state change succeeds.

validate availability + create commitment = one transaction

A read-then-write sequence without protection creates a race condition.

Simple example - commitment-state timeline

An inbound receipt of 500 units is expected on July 15. Without a governed commitment state, Hospital A and Customer B can both believe they own the same future units.

Receipt R-500, due July 15state timeline

All events

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 admitted as usable supplysource: 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 resultAccept 200; reject 200 from ATPstate: 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 the ledger, the organization can carry 700 units of claims against 500 units of supply. With the ledger, the allocation event reduces the free quantity before the promise transaction is accepted.

What goes wrong without it

ATP displays and reservation records disagree.
Scenario allocations leak into the baseline.
Released orders are treated as if they were still optional.
A planner reallocates supply without notifying the owner of the prior claim.
Cancellation restores supply in one system but not another.
Concurrent users promise the same receipt.
Audit history shows transactions but not the planning decision that created them.

How it shows up in high-consequence supply chains

A commitment may belong to a named patient, a blood type and procedure, a clinical-trial site, a donor-funded country program, a military mission, a protected customer class, or a grid-restoration site. Reassignment can have ethical, clinical, contractual, or mission consequences.

The ledger should therefore preserve not only quantity but identity, priority, eligibility, authority, and the displaced claim. A high-consequence cancellation should not simply delete a row. It should create a reasoned and reviewable state transition.

Common confusion

A commitment ledger is not an accounting general ledger, a generic audit table, or a synonym for reservations. It is a planning-level event model for future claims and their authority states.

It also does not imply that every tentative signal should consume supply. Forecasts, scenarios, recommendations, soft reservations, and firm promises need distinct states. The design question is exactly when an option becomes protected and who may change it.

General ledger	An accounting record. A commitment ledger is about future planning claims, not financial postings.
Audit table	A generic change log. A commitment ledger records the planning meaning, authority, and displaced claim.
Reservation	One possible commitment state. The ledger joins reservations, allocations, promises, releases, cancellations, and supersessions.
Forecast	A demand signal. It should not consume supply unless policy turns it into a protected claim.

Vista interpretation

Vista point of view

Promises consume the future. Planning platforms should therefore make commitment state as fundamental as demand and supply. The system computes what remains possible; the ledger records which possibility became an obligation.

Vista's view is that this is not just a control to prevent duplicate promises. It is how an organization knows which commitments are binding, which options are still negotiable, and which tradeoffs have already been accepted. In high-consequence planning, a ledger lets teams act earlier because the state of obligation is visible: who owns the claim, what authority created it, what policy protects it, and what would be displaced by changing it.

The operational upside is as important as the guardrail. A reliable ledger helps enforce service promises, donor restrictions, patient or mission priorities, and commercial contracts; improves CTP and allocation decisions by exposing truly free capacity; supports root-cause review when commitments fail; and lets leaders tune policy without reconstructing the history from messages and spreadsheets.

Agents may investigate, propose, or draft a transition, but consequential claims should change only through explicit, authorized, idempotent actions. A commitment ledger makes the boundary visible: calculation can recommend an action, but only a governed state transition turns future supply into an obligation.

Sources Reviewed 22 June 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.