Know why an order cannot ship
An order is due today. Sales wants it released, the warehouse sees enough stock, and the quality team has placed a hold. Give everyone the same policy answer, with the fact and rule that explain it.
This example uses an original, illustrative shipping policy and structured facts. Its outcomes were checked through the existing policy runtime. It is a walkthrough of a decision control, not a customer deployment or a measured cost saving.
The decision your team needs#
A customer-service agent opens a selected order and chooses Check shipment readiness. The question is narrow: can this order ship from stock under the approved policy? The answer is release, hold, or a blocked check that names missing information.
The intended benefit is less time reconciling contradictory answers across teams. The warehouse sees why an order is held; customer service can explain the same reason; the policy owner can inspect the rule that produced it. Your application still controls who may release a shipment.
Start with a policy the owner can read#
Illustrative shipping policy
If a quality hold is present, hold the order. If usable stock is less than order quantity plus required reserve, hold the order. Otherwise release it for the shipment process. Quantity, usable stock, quality-hold status and reserve must all be supplied; missing information blocks the check.
These clauses become a reviewed playbook. The ontology gives “usable stock,” “order quantity” and “reserve” agreed meanings and units. A number described as stock on hand must not silently replace usable stock if the two mean different things in your business.
Follow one order from facts to answer#
| Fact for the selected order | Example value | Source your integration must establish |
|---|---|---|
| Quantity ordered | 100 units | The selected order record |
| Usable stock | 150 units | The inventory record with agreed stock semantics |
| Quality hold | Present | The quality system's current status |
| Protected reserve | 30 units | The approved fulfillment policy |
Result: hold. There is enough stock for the order and reserve, but the quality_hold rule takes priority. A useful application message is “Held: quality clearance is required.” That message is an illustrative presentation of the returned rule, not generated model output.
The downloaded example supplies these facts directly. Connecting inventory and quality systems, checking freshness and applying access permissions are deployment work; this example does not include ready-made connectors.
See exactly what changes the answer#
Keep order quantity at 100 and reserve at 30. Change one fact at a time:
| Usable stock | Quality status | Recorded result | What the business learns |
|---|---|---|---|
| 150 | Clear | Release | The declared stock and quality conditions are satisfied. |
| 150 | Hold present | Hold: quality_hold | More stock will not resolve a quality hold. |
| 120 | Clear | Hold: stock_reserve | Shipping would leave 20 units, below the reserve of 30. |
| 130 | Clear | Release | Exactly the required reserve remains. |
| 150 | Missing | Blocked: VALUE_MISSING | Obtain quality status; absence is not clearance. |
These are recorded checks of the illustrated rules, not a model-accuracy benchmark. Inspect the input cases and runtime results and file hashes.
Try the review in Studio#
- Import the example draft.
Download the shipping proposal. In a provisioned source-integration Studio, open Policy Studio and import its JSON through Import an existing source-backed proposal. It contains the policy text, typed input specification, rule citations and draft.
- Review the business meanings.
Confirm that quality holds take priority, the reserve rule matches the written policy, and usable stock is the field your team intends. Resolve each field's source binding for your deployment.
- Enter the cases above and run the tests.
The exact-boundary and missing-status cases matter as much as the routine release. A changed rule requires a new saved revision and fresh test evidence.
- Review and release the version.
Use the Studio release walkthrough to record a review, obtain separate administrator approval and install the immutable version. Importing a draft alone does not approve it.
Where English helps#
A future qualified interpreter could map “Can we send this order from stock?” to this assessment after the application selects the order. It would select the question; inventory and policy would still determine the answer. The recorded native model has not qualified for admission, so this example uses explicit decision selection and structured facts. The rule-review workflow is useful independently of that model.
Measure value in a pilot#
Run the pack beside your existing process first. Track time spent finding the reason for a hold, disagreements with the policy owner, missing-data cases, and shipments that would have breached a quality or reserve rule. Review every disagreement. Those observations can establish whether the integration is useful; this example does not claim a reduction in cost, errors or handling time.
Next, see how a different team uses the same approach to route purchases and review a threshold change.