From Supply-Chain Recommendations to Authorized Order Changes

Choose an enforceable boundary for AI-assisted supply-chain exceptions, with explicit stock semantics, scoped approval and independently settled order effects.

audience="Engineering leaders working with inventory, planning and procurement owners on exception workflows." decision="Choose where a proposed order change becomes enforceable and how independently owned effects are reconciled." position="Keep recommendation, feasibility, approval and execution evidence separate. Enforce allocation at its owning authority and settle each downstream effect independently." scope="A proposed design using a synthetic distributor, illustrative quantities and inert integration fixtures. No actual orders, supplier instructions, model experiments or inventory changes are represented." outputs={['A stock-semantics contract', 'A comparison of commitment boundaries', 'An exact proposal difference view', 'An action-specific authority map', 'A per-effect reconciliation record', 'Independent acceptance fixtures']} />

Executive summary

An AI-assisted supply-chain exception should become an order change only when the organization can establish four separate facts: the proposal is supported, the change is operationally feasible, the actor is authorized and the destination has applied the intended effect. A good explanation establishes none of these automatically. Nor does a single approval make several independent systems change together. The useful architecture decision is where commitments become enforceable, not which model can produce the most persuasive recommendation.

Consider a hypothetical distributor. Order O42 needs 50 units of item K17 at site A. A synthetic warehouse record shows 120 on-hand units: 30 quality-held, 40 already reserved and 50 free. These categories are mutually exclusive only by the fixture's explicit assumption. The assistant proposes reserving the free units, changing the dispatch date and requesting expedited freight. It has prepared three different effects, with different decision owners and possible failures. An inventory reservation cannot silently authorize a changed customer commitment or an extra freight charge.

This paper recommends starting with the existing commitment authority. If an ERP already enforces the required stock and order invariants, keep those controls there and use AI for a bounded review task. If several sources inform a decision, a case projection can assemble evidence without becoming a second inventory authority. If independent systems must change, preserve identifiable effects, prerequisite ordering and unknown outcomes. Select the least complex design that can enforce the actual business contract, not the smallest diagram or the most elaborate orchestration platform.

The proposed artifacts are a stock-semantics contract, attributable case packet, exact difference view, scoped authorization and per-effect settlement record. They should help operators see what can proceed, what is held and what may already have happened. The synthetic counterexamples are independently specified expectations, not measured results. No actual inventory, supplier, payment, customer or model experiment is used. A real deployment needs its own operating policy, integration guarantees and evidence that these boundaries survive concurrency and failure.

Establish stock semantics before designing the workflow

Start with the meaning of each quantity, not the assistant's input schema. On-hand, available, allocated, reserved, picked, quality-held and incoming can refer to different states in different systems. A warehouse count can include stock already promised to another order. A planning export can exclude a location or reflect an earlier counting cycle. Adding fields to one prompt does not resolve these differences. Inventory owners must explain the source definitions and relationships before an engineer computes an allocatable balance.

In the illustrative partition, subtracting 30 held and 40 reserved from 120 on hand gives 50 free units. In a real system, held and reserved stock might overlap. Subtracting both could understate availability; ignoring both could overstate it. A correction could supersede an earlier count rather than represent additional movement. Record whether quantities describe disjoint categories, transactions or independent observations. The arithmetic rule needs an explicit semantic basis, not merely a plausible field name.

Resolve item identity and units with the same care. Five cases cannot become fifty individual units without an applicable conversion. A supplier's product identifier may denote a different package or substitute specification. Keep the conversion source and revision with the normalized quantity. Do not let the model choose a convenient conversion because the rest of the proposal requires it. If the mapping is missing or ambiguous, the proposal can describe the gap, but feasibility remains unresolved.

Also identify who owns the right to allocate. A consolidated dashboard may display stock from several legal entities or sites without permitting one planner to transfer it. A record's visibility is not an ownership decision. Define stock owner, site, lot where relevant, unit, source revision and applicable exclusions. The resulting semantic contract should be readable by operations and implementable by engineering. Without it, a more accurate language model can still produce a confidently wrong commitment from correctly retrieved but misunderstood data.

Separate recorded stock, allocatable stock and future promises

A current observation is useful, but it is not a reservation. Suppose another accepted operation consumes 20 of the fixture's 50 free units after the packet is assembled. Only 30 remain free under the stated rule. The earlier proposal for 50 is no longer admissible. Repeating a lookup may reveal the change; it does not prevent another writer from changing the balance between lookup and reservation. The allocation authority must enforce the invariant at the actual commitment boundary.

DynamoDB's read-consistency documentation explicitly distinguishes read consistency from protection against a subsequent modification. Strong reads are supported on tables and local secondary indexes, not global secondary indexes or streams. Applied to a proposed implementation, choose the appropriate observation route, then use the owning write contract to enforce allocation. A strongly consistent read is not a stock lock.

Future availability needs a separate representation. A supplier estimate, expected receipt or planned production run can inform an option without establishing goods are present and usable. Keep the source, uncertainty and conditions visible. A promised receipt could depend on an unresolved quality acceptance or transport event. Do not merge future supply into free stock solely because the proposed dispatch date lies after the estimate. That comparison may be one planning assumption, not an enforceable operational fact.

Define what the organization permits before a receipt. It may accept a conditional customer promise, require a confirmed reservation or forbid the commitment until physical acceptance. Those are business policy choices, not universal AI thresholds. Preserve the policy and the kind of evidence that satisfied it. The inventory-freshness review explains why newly generated prose can still contain old or incomplete evidence. This paper extends that concern to the authority that decides whether an observed quantity can become a commitment.

Build an attributable case without claiming a universal snapshot

Give the exception a stable identity that links the affected order lines, item, sites and proposed effects. Keep the evidence packet separate from the mutable case workspace. A reviewer should be able to reconstruct what supported proposal revision P3 even after the warehouse balance or supplier estimate changes. Retain controlled source references, collection status and transformation details rather than copying every commercial document into a broadly accessible log or model context.

Observation time, collection time and source revision answer different questions. A newly collected export can contain an old count. A supplier estimate can be recent but unconfirmed. A successful API lookup can cover one site while the proposal assumes several. Record missing coverage explicitly. An empty result should distinguish a verified absence from a failed query, unauthorized scope or incomplete scan. Silence in the packet must not become evidence that there are no reservations or conflicting commitments.

The W3C PROV primer supplies a useful vocabulary for entities, activities, derivation and responsibility. A stock observation, normalized quantity and generated recommendation are different entities connected through transformations. Provenance describes their origin and relationships; it does not prove physical stock truth or grant allocation rights. Use attributable lineage alongside the domain checks, not as a substitute for them.

Avoid presenting separately retrieved systems as one transactionally consistent snapshot. The warehouse, order and supplier records may have different revision clocks. Where the design cannot obtain a common atomic view, retain the mismatch and revalidate significant conditions at their owning boundaries. The historical packet remains useful for explaining why an earlier option was considered. It should not be reused as current authorization merely because its references are complete. A case projection supports review; it does not own inventory.

The map separates information used to understand an exception from the authority that can reserve stock. The two review inputs remain distinct. The proposed gate is a responsibility boundary, not a claim that an existing warehouse exposes a particular transaction API.

Compare native control, reservation boundaries and orchestration

The first alternative is ERP-native change control. AI prepares a read-only review packet, while the existing ERP owns feasibility, permission and commitment. This is a strong candidate when that system already enforces the needed invariants and exposes usable review or change interfaces. It can reduce the number of independently settled effects. Its limitations may include restricted integration options, incomplete evidence presentation or an approval workflow that does not show all affected commitments. Establish these limitations from the actual system rather than assuming every existing ERP is inadequate.

The second alternative is a case projection with an authoritative reservation boundary. Several sources inform review, but one designated inventory service or ERP still controls allocation. The projection stores attributable observations and proposal revisions, not a competing available-balance truth. It can improve the operator's view of conflicting evidence while retaining one enforceable allocation rule. Its additional responsibilities include packet freshness, source-access controls, revision-bound decisions and a reservation lifecycle that the operator can understand.

The third alternative orchestrates changes across independent authorities. Inventory, customer commitments and freight may belong to separate systems that cannot participate in one local commit. Each effect then needs its own identity, preconditions, permitted action and settlement evidence. This design can make partial outcomes visible, but it adds reconciliation work and operational ownership. Do not choose it simply because a workflow service is available. The organization must be able to manage reservations that succeeded while a later order change was held.

Compare all three against the same exception contract. Where is over-allocation prevented? Which system proves that the intended line changed? What happens when the reviewer is slow or an integration is unavailable? Who can reconcile an unknown result? How much additional review and integration work does each choice require? There is no general winner independent of those answers. Prefer a native boundary when it already provides the evidence and control required. Add projection or orchestration only for a demonstrated gap, and include the cost of operating its held and partially applied cases.

Give AI a bounded role that remains useful without writes

Security controls must protect the same stock, entity and evidence scope across review and execution. Access leakage and excessive write permission are separate failures; a correct feasibility answer does not compensate for either.

The assistant's useful job is to help a reviewer understand an exception: summarize permitted observations, identify missing support, compare already feasible alternatives and draft a question for an accountable owner. A structured response can link each material statement to a source or mark it unresolved. Deterministic logic should still check units, exclusions, quantity relationships and the scope of available actions. A syntactically valid response with a citation can remain operationally wrong.

Keep the assistant away from broad operational credentials. Preparing an option does not require a supplier-message endpoint or permission to amend every order visible in a dashboard. Separate read, prepare and commit interfaces. External supplier text is evidence, not a policy instruction. A message asking the model to waive a quality hold should not be able to change the feasibility rule or disclose another customer's terms. Validate access and action boundaries, not just the politeness of the answer.

Bedrock return control is one provider-specific way to return action inputs and an invocation identifier to the application instead of directly fulfilling through Lambda. It offers an interception point. The application still needs to validate the actual proposal and permission before calling an operational interface. Return control does not establish stock ownership or meaningful business approval.

Preserve a non-AI path. If the model times out, returns unsupported options or is unavailable, the reviewer should still see the evidence packet, deterministic checks and missing conditions. Record the assistance failure without making the case disappear. Do not silently switch to broader permissions or a different unreviewed model. Evaluate whether assistance improves accepted resolution quality and effort compared with this complete baseline, not compared with an artificially empty screen. The architecture should remain safe and usable when AI contributes nothing to a particular case.

Make affected commitments visible to the reviewer

Present the selected change as a difference, not only as a narrative. For O42, show the original and proposed quantity, site, dispatch date and any changed customer obligation. Show the existing reservations that must remain protected, even if they are not being modified. Unchanged identity fields matter because they establish what the review covers. A short summary saying “protect the delivery” can hide a change in destination, stock ownership or incremental expenditure.

Distinguish supported facts from assumptions and estimates in the same view. A supplier's likely receipt date should not appear visually identical to a confirmed reservation. A missing unit conversion should remain a visible hold, not a footnote beneath a confident recommendation. Give authorized reviewers a controlled way to inspect source records. The goal is not to force them to open every record on every case, but to make significant evidence accessible and its limitations hard to miss.

Do not hide rejected effects by substituting a nearby acceptable option. If reserving 50 units fails after the competing allocation, the system must not quietly reserve 30 and retain the original approval. Partial fulfillment changes the business meaning. It may be a useful new option, but it requires whatever review that changed commitment demands. Keep the original rejection reason and create a new proposal revision with the smaller quantity and its consequences.

Design the review around the actual operator's work. A planner may need to compare alternatives; a procurement owner may need the charge and supplier terms; an inventory owner may need lot restrictions and displacement risks. Role-specific presentation must preserve a common proposal identity and significant details. Avoid a single ambiguous approve button for effects that belong to different owners. The interface should expose whether the case is waiting for evidence, authority or destination settlement, since those conditions require different next actions and different people.

Authorize the exact change, not the whole recommendation

Bind an authorization to the selected proposal revision, actor or delegated policy, permitted effect, entity, target and significant conditions. For the synthetic reservation, those include K17, O42, site A, the quantity and the allocation basis. Changing site A to site B changes the proposal. Permission to adjust a dispatch date does not grant permission to purchase substitutes or book freight. An approval badge must not become a transferable token for whichever action the worker later finds convenient.

OWASP's transaction-authorization guidance calls for server-side enforcement, protected significant details, controlled state transitions and a final execution check. Applied here, the server checks the exact attempted delta against the scoped decision. It does not trust a browser-supplied approved flag or allow a queued worker to regenerate a different order from conversational text.

Define the conditions that invalidate execution. A material proposal change, expired decision, withdrawn role, superseded policy or missing prerequisite can require a hold and reassessment. Which prior decisions survive a policy update is an organizational rule to resolve explicitly, not an assumption to bury in code. Time limits should reflect the actual operational process. Do not invent a universal approval lifetime or let a model confidence score extend one.

Some organizations delegate narrow routine changes without individual review. Represent that delegation explicitly: permitted scope, exclusions, aggregate exposure and accountable owner. Splitting one commitment into small operations must not bypass a parent limit. A service credential identifies a technical caller; it does not itself prove the business policy permits that action. Keep manual and delegated routes distinguishable in the record, while subjecting both to the same actual inventory invariant and destination contract.

Enforce allocation invariants where stock is actually owned

The fixture's no-overallocation rule must be enforced by the authority accepting a reservation. If the application owns inventory in its own database, it can design an appropriate conditional update or transactional invariant there. If a warehouse system owns allocation, a local case database cannot establish that external stock was reserved. An application that reads a balance and later writes an unguarded reservation has not closed the race, even if both operations usually complete quickly.

DynamoDB transaction documentation describes same-account, same-Region atomic writes and conditional actions. It also distinguishes downstream index or stream propagation from the transaction itself, and limits client-token idempotency to ten minutes. These guarantees can support a local design; they do not span a warehouse or carrier. Retain durable business operation identity rather than treating a provider token as permanent duplicate protection.

PostgreSQL's isolation documentation, currently for version 18, explains that Serializable committed transactions emulate serial execution and callers must handle serialization failures. Repeatable Read is not an interchangeable guarantee. A local retry should recompute and validate the local transaction as required; it must not replay an external instruction emitted by an earlier attempt. Keep those side effects outside a retryable transaction body unless their actual contract makes repetition safe.

Explain reservation duration and release semantics with the inventory owner. A temporary hold that expires while approval waits is not a durable promise. A confirmed reservation may prevent another order from proceeding, so abandoned cases need a defined disposition. Conversely, cancellation of a UI workflow must not automatically free stock when the external reservation result is unknown. Decide which record owns the balance, which operation consumes it and which evidence proves its release. A correct invariant in one database is insufficient if another authorized route can allocate the same stock without respecting it.

Preserve each destination's effect state

For an orchestrated design, record the intended reservation, order change and freight request as separate effects. Each should identify its original operation, proposal revision, significant parameters and prerequisite evidence. Record intent durably before dispatch under the local contract. A crash between intent and dispatch is different from a lost response after a destination accepted the action. The recovery path needs to distinguish those situations rather than infer both from a pending job.

Use explicit states such as pending, confirmed, rejected and unknown, with their evidence. A transport timeout after a reservation request leaves the effect unknown. A failed reconciliation lookup does not prove the reservation is absent. Do not issue a fresh reservation simply to get a response that the application can display. First reconcile the original operation through a supported lookup or accountable operational process. If the destination cannot provide trustworthy operation-specific evidence, expose that limitation in the design decision.

AWS's saga-orchestration guidance discusses coordinating local transactions and compensating work, including concurrency and absent transaction isolation. That pattern helps organize independent effects; it does not make an external instruction atomic with the application's ledger. A proposed compensation here remains a separately permitted business operation with its own result.

Choose prerequisite ordering according to actual obligations. The illustrative sequence reserves stock before an order-date change, then permits a freight request only after the required predecessors are confirmed. That ordering is not universally correct; some operations require different commercial prerequisites. When R42 is confirmed but the order change is refused, keep both facts. Do not report the case as safely untouched or wholly completed. A state-machine execution completing proves only what its states and observations actually checked, not that goods were collected, delivered or accepted.

The sequence shows one proposed prerequisite order and a lost-response branch. Its receipts establish specific effects, not a fulfilled shipment. The mobile composition preserves the same ownership and uncertainty distinctions without shrinking the desktop lanes.

Treat cancellation and compensation as different decisions

Canceling future dispatch does not undo an effect already accepted. The system can stop unattempted freight work while preserving a confirmed reservation or an unknown order change. Show which work was prevented and which obligations remain. A canceled parent case should not remove the operation ledger from recovery, hide it from the accountable owner or make the original stock appear free again without evidence.

Compensation means a new action intended to address a prior effect. Releasing an unused reservation may be permitted under one contract. Reversing an order amendment, canceling a carrier booking or withdrawing a supplier instruction may have different rights and consequences. Do not assume each has a symmetric undo API. Physical collection cannot be rolled back by deleting a row, and an accepted instruction can create obligations that remain after the application marks a workflow failed.

Authorize and identify a compensation separately. Preserve the original receipt, reason for the new action, scope and resulting evidence. If stock was picked after reservation, a release request may no longer mean what it meant before picking. Revalidate the relevant conditions. An earlier approval to reserve stock does not necessarily authorize every later cancellation, and a model-generated recovery suggestion must not grant itself that permission.

Define how long unresolved effects can remain, who investigates them and when dependent work must stop. These are operating choices, not universal numeric thresholds. Escalation should mean an accountable review route, not an automatic expansion of technical access. Preserve uncertainty until supported evidence resolves it, while making the operational burden visible. A technically cautious system that accumulates unowned reservations indefinitely is not a usable exception process. Recovery needs both correct state and people or established procedures capable of resolving the remaining obligations.

Test independently specified counterexamples

Write the expected outcomes before evaluating the assistant or workflow. The five fixtures below describe the synthetic contract, not measured production performance. Their purpose is to detect plausible but incorrect decisions that a happy-path demonstration would miss. Use inert destination adapters with inspectable ledgers so the observer can distinguish accepted effects from application status. A model-generated answer key would not be independent evidence that the model met the intended rule.

| Changed condition | Expected disposition | Evidence to inspect | | --- | --- | --- | | Competing allocation consumes 20 of the 50 free units | Hold the old 50-unit proposal; only 30 remain free under the fixture partition | Accepted competing reservation, current revision and rejected old delta | | Supplier offers 5 cases without a K17 conversion | Hold feasibility; do not guess individual units | Applicable item conversion or recorded missing-conversion condition | | Approved site A becomes site B in the queued payload | Reject the changed payload and obtain a new scoped decision | Approved significant fields compared with attempted effect | | Reservation R42 is accepted but its response is lost | Preserve unknown and reconcile R42; do not create a new reservation | Original-operation readback, trustworthy receipt or unresolved investigation | | R42 is confirmed and the order-date change is refused | Retain the confirmed reservation and held order effect; do not dispatch freight | Per-effect ledger, prerequisite check and separately permitted release decision |

Include a deliberately unsafe candidate that performs a current read followed by an unguarded reservation. The observer should reject it under competing allocation. Likewise, a candidate that treats a timeout as a failed reservation should fail the lost-response fixture. Otherwise the evaluation can pass while preserving the very behavior it was intended to prevent. Retain original attempts and destination effect counts rather than only the final successful-looking case.

Extend the harness with overlapping stock categories, duplicate callbacks, expired reservations, withdrawn permission and failed readback. Keep calibration cases separate from retained acceptance cases. When a prompt or policy changes after a failure, record the new candidate and rerun the relevant expectations. The supply-chain exception pilot gives the owner-led execution procedure. Passing these local fixtures would still not prove a real ERP or warehouse integration has the same transaction, identity or receipt guarantees.

Measure resolution quality and operational capacity together

Measure accepted case resolutions against the supplied business contract. A well-written recommendation rejected for missing evidence is not an accepted resolution. A permitted order change with an unknown reservation is not a settled case. Keep assistance quality, reviewer decisions, destination effects and eventual operational outcomes separate. Otherwise the dashboard can report high recommendation acceptance while operators carry an expanding inventory of unresolved commitments.

Track the effort needed to assemble evidence, inspect significant differences, make the decision and reconcile exceptions. Include held-case age and unresolved-effect age, with explicit denominators and observation windows. Do not count repeated attempts as new business cases or quietly exclude difficult cases from the baseline. Compare assisted review with the complete manual path, including the same evidence and deterministic controls. The proposed design offers no measured time-saving percentage or throughput improvement.

Calculate total operating cost, not only tokens. Source integrations, authoritative checks, model calls, retries, reviewer time, reconciliation and retained evidence all contribute. A cheaper model path that creates more unsupported options can consume more operator capacity. Conversely, an existing native transaction workflow may already resolve the common case efficiently. Separate one-time integration work from recurring cost and state any assumptions used in a local estimate. Synthetic cost inputs must not appear as a provider quote or customer result.

Set the review and recovery service expectations with operational owners. If the assistant can prepare cases faster than reviewers can resolve them, the backlog can make reservations expire or evidence stale. Use admission limits, prioritization and clear hold reasons where the actual process needs them. Do not solve capacity pressure by quietly broadening autonomous authority. AI assistance is useful only if the organization can sustain the resulting decision workload and identify the unresolved obligations that still require attention.

Define acceptance evidence, limitations and the next decision

Use this acceptance checklist with the accountable owners: verify stock semantics, exact proposal identity, execution permission, allocation enforcement, per-effect receipts and the unresolved-state runbook. Mark missing evidence as open rather than treating document completion as operational acceptance.

Before release, the team should be able to demonstrate the stock semantics and owning allocation rule, an attributable packet, a readable exact-difference view and server-enforced effect permission. It should produce receipts for confirmed effects and preserve unknown ones without issuing untracked duplicates. A changed proposal should not inherit an old decision. A rejected later effect should leave earlier accepted effects visible, with any release or compensation separately permitted.

The review artifacts are practical: a semantic contract, alternative comparison, authority map, proposal manifest, per-effect ledger and reconciliation runbook. Include independent fixture expectations and evidence that the observer detects unsafe candidates. Inspect the operator experience on a phone as well as a large screen. A narrow layout must still show site, quantity, revision, affected commitments and unresolved state. An export should retain those distinctions rather than flatten them into a polished narrative with no actionable evidence.

This paper intentionally does not prescribe supplier qualification, quality policy, legal retention, accounting treatment or a universal promise rule. It does not establish the behavior of any unnamed ERP or warehouse. The synthetic partition is not a general inventory formula. A local transaction guarantee applies only within its actual scope, and a provider receipt proves only the specific fact that receipt represents. Physical counts, commercial decisions and fulfilled delivery require their own authoritative evidence and operating owners.

Start by choosing one exception and documenting where its commitments are currently enforced. If the existing system covers the invariant, keep it and improve the review evidence. If it does not, identify whether the gap is attribution, allocation authority or independent effect settlement before adding technology. The decision-rights article helps separate the hidden authorities. For implementation, agentic workflow engineering and backend/API engineering are relevant where these boundaries need to be designed and tested. Agree scope and acceptance evidence for the actual environment rather than treating this illustrative design as a ready-made production guarantee.