From Inventory Evidence to an Order You Can Explain
Abstract
Ordering systems must reconcile records that disagree about identity, quantity, and time. Collapsing those records into a single inventory value hides uncertainty at the moment a buyer commits money. This paper develops an architecture for RED that separates source observations, accepted facts, planning proposals, and supplier outcomes. A worked example follows an ambiguous pack quantity through reconciliation and approval. The analysis explains why immutable planning inputs and durable submission receipts address different failure modes, compares alternatives, and specifies tests for replay, concurrency, and partial fulfillment. It is a proposed operating model informed by existing engineering notes; it reports no production benchmark or regulatory assessment.
Intended audience Engineering leads, procurement system designers, and inventory operations teams.
1. The decision hidden inside an import
An inventory import appears to be a data movement task. In practice, it can make several business decisions before a buyer sees a screen. A parser may decide that two item names identify the same product, that a supplier's quantity means individual units, and that a recent file supersedes an earlier count. If those decisions are implicit, the application can produce a precise order from an uncertain premise.
The question addressed here is: how can an ordering system preserve uncertainty until the person or policy entitled to resolve it makes a decision? The proposed answer is to assign separate authority to observations, facts, proposals, and outcomes. Each transition creates a new record with a reason; an import does not silently become accepted inventory.
RED's existing engineering notes discuss retained inventory evidence, provisional candidate reduction, and replay without persistence. Those notes motivate this design. They are documentary evidence of engineering intent, not independent verification of deployed behavior. The model below extends that intent into an ordering lifecycle and identifies the tests needed to evaluate it.
2. Four records, four kinds of authority
A supplier file is evidence of what the supplier reported. It is not necessarily evidence of what a store possesses or can order. A business fact adds an interpretation: this record refers to this product, at this location, in this unit, for this effective time. A proposal applies a policy to facts. An outcome records what an external party actually acknowledged or delivered.
- 1. ObserveRetain source and effective time.
- 2. ReconcileAccept identity and units.
- 3. ProposeFreeze inputs and calculate.
- 4. ConfirmRecord external outcomes.
The source record should remain available when an interpretation changes. Otherwise a correction destroys the explanation for the earlier order. W3C's provenance model distinguishes entities, activities, and agents, providing a vocabulary for expressing this derivation. It does not determine which retail interpretation is correct. [1]
Time requires two fields at minimum: when the source claims the observation was effective, and when the application received it. A delayed delivery can be newly received but operationally old. Overwriting the latest fact by arrival order confuses those clocks. The reconciliation policy must decide whether an observation updates accepted state, remains historical evidence, or requires review.
3. Worked example: an ambiguous pack quantity
Consider a synthetic supplier record containing a product description, a quantity of 12, and an abbreviated pack label. The store's accepted stock is 18 individual units; a planning policy targets 50 units. The example deliberately excludes demand uncertainty so that the identity and unit problem is visible.
If the imported 12 means individual units, the supplier advertises 12 units. If it means cases containing six units each, the same field represents 72 units. Both interpretations are mathematically valid; only a verified mapping can choose between them. A string similarity score cannot establish the unit conversion.
After a reviewer confirms a six-unit case and the relevant product identity, the proposed order is six cases: the shortfall is 32 units, and rounding up to complete cases yields 36. The four-unit excess is a visible consequence of the packaging constraint, not an unexplained adjustment. If the supplier's minimum order were seven cases, the proposal would need to display that additional constraint and its effect.
| Stage | Known information | Permitted result |
|---|---|---|
| Import | Quantity 12; pack meaning unresolved | Observation and review item |
| Reconciliation | Six units per case; product match accepted | Versioned mapping |
| Planning | 18 units held; target 50; complete cases required | Proposal for six cases, or 36 units |
| Supplier response | Only four cases accepted | 24 units confirmed; discrepancy remains open |
The last row matters as much as the calculation. The system should retain the requested six cases alongside the acknowledged four. Replacing the request with the response would erase the shortfall and make it difficult to explain why the original target was not reached.
4. Approval must bind to planning inputs
A reviewable proposal includes the accepted inventory revision, product mapping revision, pack conversion, planning policy, and intended supplier. These references give the approval a concrete subject. An approval of “the current order” has no stable meaning if another import can change its inputs before submission.
The proposed submission boundary checks that the approved proposal is still eligible to execute. Some changes should invalidate approval, such as a different supplier or pack conversion. Other changes may be permitted by a documented tolerance, such as a small demand adjustment. The tolerance itself belongs to the policy that was reviewed; it should not be invented at submission time.
The check and the local transition to an accepted submission must be atomic. PostgreSQL documents that serializable transactions can reject executions that cannot be reconciled with a serial ordering, and that applications must be prepared to retry the transaction. This is one possible concurrency mechanism, not a substitute for defining the approval rule. [2]
A practical alternative is an explicit revision comparison in the write condition. The application attempts to advance only the revision it reviewed; a mismatch returns the proposal for reconsideration. The appropriate mechanism depends on how many records jointly determine eligibility and where those records are stored.
5. Receipts do not make external delivery atomic
A durable local receipt answers whether the application accepted a submission request. It cannot, by itself, prove whether a supplier received that request. A process can fail after sending an order but before persisting the response. Retrying automatically may produce a duplicate; refusing to retry may leave a valid order unresolved.
The design therefore distinguishes three outcomes: confirmed acceptance, confirmed rejection, and unknown external outcome. Unknown is a durable state with a reconciliation path. It should not be rendered as either success or failure merely to simplify the interface.
An idempotency key should be scoped to the business operation and associated with the exact request content. Repeating the same key and content retrieves the existing receipt. Reusing the key with different content returns a conflict. The receiver must participate in deduplication for this to protect an external side effect. Where the supplier offers no such contract, an operator or reconciliation job needs to investigate the unknown outcome before another submission is authorized.
This distinction also protects diagnostic replay. Reprocessing retained source evidence may calculate candidates and differences, but should not enter the submission path. A useful verification is to run replay with mutation capabilities absent, rather than relying entirely on a caller flag that requests read-only behavior.
6. Alternatives and their costs
A mutable inventory table with direct order generation is attractive for a small, consistent source set. It minimizes storage and reduces the number of screens. Its weakness is that interpretation, correction, and planning history must be reconstructed from secondary logs. That may be acceptable where actions are easily reversed and reconciliation costs are low.
Full event sourcing preserves every domain transition and can support detailed reconstruction. It also requires stable event semantics, migration strategy, and projection repair. Retaining raw files does not make a system event sourced; source evidence and business events have different meanings.
The proposed middle course retains source observations and immutable planning proposals while allowing current accepted facts to have conventional queryable representations. It spends storage and review effort at the transitions that explain consequential decisions. Its principal cost is exception handling: ambiguous records remain visible work rather than disappearing into optimistic defaults.
A team should adopt this design when the cost of an unexplained or duplicated order exceeds the cost of preserving lineage and resolving ambiguity. It should first identify which decisions actually need that history, rather than retaining every intermediate value indefinitely.
7. Evaluation and limitations
Evaluation should use a corpus containing duplicate imports, delayed observations, changed pack mappings, partial acknowledgments, and interrupted submissions. Each case needs an expected business outcome before the test runs. A successful parser is not a successful order workflow.
The most important checks are behavioral: a duplicate request creates no additional local submission; a changed request under the same key conflicts; a stale approval does not advance; a partial response preserves both requested and confirmed quantities; diagnostic replay produces no business writes. Interrupting execution around the send boundary should leave an explicit unknown outcome that can be reconciled.
Operational measurements should include unresolved identity cases divided by imported candidates, approval invalidations divided by submission attempts, and unknown external outcomes divided by external submissions. Report the observation window and policy version with each rate. These are proposed measurements, not results from RED.
The worked example establishes arithmetic and state distinctions only. It does not model demand variability, spoilage, lead times, supplier pricing, or jurisdiction-specific obligations. The architecture also depends on retention policies, access controls, and operational ownership that this paper does not validate. No claim of regulatory compliance follows from retaining an audit trail.
8. Conclusion
An explainable order is the end of a chain of authorized interpretations. Preserving a source observation, accepting a product mapping, approving a proposal, and confirming a supplier response are separate decisions. Keeping them separate allows a system to expose a pack mismatch before purchase, reject a stale approval, and investigate an uncertain submission without rewriting history.
For RED, the next engineering milestone suggested by this analysis is an end-to-end demonstration of that chain under interruption and conflicting inputs. Such a demonstration would provide stronger evidence than either a feature inventory or an unqualified promise of automation.
References
- W3C. PROV-Overview, 2013. Provenance vocabulary used in Section 2.
- PostgreSQL Global Development Group. Transaction Isolation. Concurrency behavior discussed in Section 4; consulted September 6, 2026.