ReturnPath /
A clearer path from return to resolution.
Evaluate return eligibility against versioned policies, reserve quantities and track received goods without duplicate processing.
- Practice
- AI & automation
- Built by
- Lumia Digital
- Application
- Independent source & workspace
- Current release
- Local / September 2026
A more considered returns operation.
A warm burgundy control centre follows review, authorization and physical receipt. State filters lead into saved return records and a queue of next decisions.
XState return lifecycleSee how ReturnPath thinks.
Every Lumia system earns its own operating language. This view shows the decision surface, evidence trail and human checkpoint built around this workflow.
Damaged on arrival
Corner crush detected in two images. Item and packaging are held for review.
Policy R-04 allows a replacement after the receiving note is attached.
Interface study / controlled local workspace / human review remains in the loop.
The problem worth solving.
A return request is a sequence of decisions, not a single yes-or-no answer. The team must know what was fulfilled, what has already come back, what another case has reserved and which policy version applies. Two operators can each approve a reasonable-looking request while their combined authorisations exceed the units that remain returnable. ReturnPath centres the workflow on that shared quantity and policy evidence.
An operator records an order and a versioned return policy, opens a case for a specific order line, reviews the eligibility evidence and obtains approval. Authorisation creates a local RMA reference. Receipt is a separate step that updates the returned quantity. Keeping those states distinct would help a support and warehouse team avoid treating a promised return as a physically received item.
The implementation has been exercised with synthetic orders, timed expiry and competing authorisations. The intended operational benefit is a traceable decision with quantities that remain consistent across cases. No reduction in return costs, resolution time or customer complaints is claimed. Real commerce, carrier and refund integrations would require additional work and operational evaluation.
Designed for: Small commerce and operations teams that need a controlled internal return-authorisation process before connecting a store, warehouse or carrier. A support operator can prepare the case while an owner reviews the policy evidence and records the authorisation or receipt decision.
From input to a useful result.
Record the order and applicable policy
Enter the customer reference, actual fulfilment time and unique order lines with fulfilled and already-returned quantities. Create a policy with a meaningful version name and return window. Future fulfilment timestamps, duplicate line identifiers and returned quantities exceeding fulfilment are rejected before they become the basis for a case.
Open a case against one order line
Select the order, policy and line, then state the requested quantity and reason. Inspect the evidence: fulfilment time, policy deadline, previously returned units, active authorised quantities and remaining availability. An ineligible request can still appear for review with reasons; its existence does not mean that a return has been approved.
Approve and authorise the reviewed request
The owner approves the current case version and digest. Authorisation checks eligibility again, including competing cases and approval expiry, before issuing a local RMA. An approval lasts no longer than twenty-four hours and cannot extend beyond the policy deadline. Waiting between approval and authorisation can therefore change the permitted action.
Receive the item or release the reservation
After a human checks the arriving goods, record receipt. The server updates the case and order quantity together. If the authorised return will not proceed, cancellation releases its reserved quantity. A received case cannot be cancelled through that path. Exported authorisation paperwork is an internal record, not a prepaid shipping label or refund confirmation.
What the software actually did.
These results come from internal workflow testing of the local product. The records are controlled test inputs; customer deployments and commercial impact have not been measured.
Nine acceptance groups passed
The local ReturnPath HTTP run passed nine groups spanning authentication, order validation, versioned policies, concurrent authorisation, receipt replay, cancellation, policy expiry, approval expiry and workspace isolation. The combined Dispatch and ReturnPath report contains 120 requests. It does not provide an independent request count for ReturnPath.
Competing requests respected the remaining units
A fixture had three units still available and two cases each requesting two units. Concurrent authorisation allowed one case and rejected the other as ineligible. A subsequent receipt moved the order's already-returned quantity from one to three exactly once. Repeating the successful receipt did not add another two units, and cancellation of the received case was blocked.
Expiry was observed over elapsed time
The harness tested an already-expired policy and also waited for a short-lived approval to expire before attempting authorisation. The later action was rejected. This checks that a stale review state cannot authorise a return after the deadline, rather than merely checking that an expiry field exists in the record.
Make the boundary clear.
- Orders and policies in the evaluated flow are entered locally. There is no verified live commerce sync, so an operator must establish how fulfilment and historical returns are kept accurate before using real data.
- The RMA is a local authorisation reference. Carrier-label generation is blocked without a provider; a PDF export does not buy postage, arrange collection or communicate with the customer.
- Receipt records that an authorised quantity arrived. The tested flow does not automate condition grading, restocking, disposal, replacement shipment, payment reversal or a refund decision.
- The tests cover policy and quantity rules with synthetic cases. They do not establish fraud-detection performance, consumer-law compliance, production load or a complete team administration and recovery process.
Questions before you start.
Why is an ineligible case still visible?
Creating a case captures a request for review. The eligibility evidence explains why it cannot currently proceed, such as an expired window or insufficient unreturned quantity. Keeping that record is different from approving or authorising it, and the later actions enforce their own preconditions.
What stops two operators authorising the same units?
Active authorised cases reserve quantity against the order line. The server recalculates availability during the coordinated write. In the concurrency test, two requests for two units could not both authorise when only three units remained available.
Can I use the RMA PDF as a shipping label?
No. It is internal return-authorisation paperwork. The tested carrier-label action is explicitly unavailable without a configured provider. Postage, collection arrangements and the delivery of instructions to a customer are separate actions.
Does receiving a return issue a refund?
Receipt advances the local case and increments the order's returned quantity. It does not initiate a payment reversal. A real operation still needs an explicit condition-review and refund process, with its own evidence and integration checks.