Check payment, production and shipment before a handoff
An order can appear paid in one place and unfinished in another. This kit brings three supplied statuses into a reviewable snapshot so a coordinator can confirm the next owner and step.
Free, stateless starter kit. Real connections and actions require a separately agreed implementation.
The job
When this check is useful
Review one order when work moves between billing, production and shipping. The kit does not poll those systems, reserve inventory, create shipments or change fulfillment.
Start with these source facts
orderId
A short identifier for the source order. Keep the link to its original records in your own system.
paymentStatus
paid, unpaid or unknown. The sample policy expects payment before production; confirm whether that policy fits your operation.
productionStatus
queued, in_progress, complete, failed or unknown. Failed or unknown production needs review.
shipmentStatus
not_created, in_transit, delivered or unknown. The sample policy expects completed production before shipping.
asOf, observedAt
Explicit UTC evaluation and observation timestamps for the reconciled snapshot. Future or more-than-seven-day-old snapshots need review.
Computed examples
See what passes and what needs review
These are fictional records evaluated at their stated asOf time, not live business data. Results below come from the same rules as the free kit. A ready state permits preparing an unsent draft; it does not authorize an action.
Known source facts
Result: ready
Known, consistent source statuses can be included in an internal handoff draft.
Unpaid but production started or shipment created: review the conflicting state under the sample policy.
In transit or delivered while production is incomplete: reconcile the sources.
Any unknown status or failed production: no draft. A delivered order, or unpaid queued order with no shipment: no action.
What a useful result must do
Paid, production complete and no shipment yet produces a ready internal handoff result.
A delivered order with failed production cannot produce a ready handoff.
The reviewer confirms the next owner and step; repeating the check never creates a second shipment or updates a record.
Check what you already have
Your existing tool may cover this
Does your order system already display these three statuses and their last update times together?
Can existing workflow rules block or flag inconsistent transitions?
Are deposits, production before final payment and partial shipments part of your process? Those require a different agreed rule set.
A scoped implementation would map the systems of record, status meanings, allowable exceptions and handoff owner. We would test delayed updates and failure recovery before proposing any action that changes an order.
Run the free kit yourself
Use an AI client that supports local MCP tools and Node.js 20 or later. This pinned command starts the order-handoff kit over standard input/output:
npx -y mainstreet-mcp@0.1.4 kit order-handoff
The two tools analyze a supplied record and prepare an unsent draft. The kit makes no provider calls and does not persist the input. Review your chosen AI client’s data handling before supplying business records; that client may require its own subscription or model charges.
Start with the workflow, current tools and the person who reviews exceptions. We agree the scope and fee in writing before paid work. Connections, sending, record updates, ongoing monitoring and maintenance are outside the free kit and must be scoped explicitly.