Know which purchases need review
A buyer wants to place an order. The supplier may need review, the amount may need a manager's approval, and the policy may have changed since the last purchase. Give the buyer a clear next step under a named policy version.
This original example policy illustrates a review route. Its structured-input outcomes were checked through the existing policy runtime. It does not authorize spending or describe a customer's controls.
Turn a written policy into reviewable decisions#
Illustrative purchasing policy
If the supplier is not approved, route the request to supplier review. For an approved supplier, an amount above 5,000 USD without manager approval goes to manager review. Otherwise use the standard purchasing process. Amount, supplier status and manager-approval status are required. Routing is not permission to place an order or pay.
In Studio, a configured authoring model can propose rules from policy prose, or you can import a prepared draft. The policy owner reviews each clause and its source citation, checks the order in which rules apply, and tests boundary cases. That work happens before the approved rules are used for requests.
Give the buyer an actionable next step#
| Request facts | Recorded route | Meaning for the buyer |
|---|---|---|
| 3,000 USD; approved supplier; manager approval not recorded | standard_process | Continue the existing purchasing process. |
| 5,000 USD; approved supplier; approval not recorded | standard_process | The policy says above 5,000; the exact boundary stays in the standard process. |
| 5,001 USD; approved supplier; approval not recorded | manager_review | Obtain the required manager review. |
| 6,500 USD; approved supplier; manager approval recorded | standard_process | The required approval is present; continue the standard process. |
| 6,500 USD; supplier not approved; approval not recorded | supplier_review | Resolve supplier review first, because that rule takes priority. |
| 6,500 USD; approved supplier; approval status missing | Blocked: VALUE_MISSING | Find the approval status. The system cannot infer whether it exists. |
“Approval not recorded” is an explicit false value from a trusted record. “Status missing” means the integration did not supply the required fact. Keeping those cases separate avoids treating a data gap as a business decision. Your application controls the actual review task, order placement and payment.
See the impact of changing the policy#
The policy owner wants to lower the manager-review threshold from 5,000 to 2,500 USD. A 3,000 USD request from an approved supplier, without manager approval, changes from standard_process to manager_review. That before-and-after result was checked with the two example drafts.
| Review step | Business question it answers |
|---|---|
| Compare the new source clause and proposed rule | Did we change the intended threshold without changing supplier priority? |
| Test just below, at and above the new threshold | Which requests will move into manager review? |
| Replay representative past requests | How much additional review work would this policy create? |
| Approve the exact tested revision | Is the installed policy the one the owner reviewed? |
| Retain the previous runtime version | Can an authorized administrator restore the prior rule if rollout reveals a problem? |
The example verifies the changed route for one request. It does not estimate review volume. That estimate needs your own representative history and review of any newly affected cases.
Try it with the supplied drafts#
- Start with the original policy.
Download the original purchasing draft and import it in Policy Studio using Import an existing source-backed proposal. A provisioned source-integration Studio is required.
- Review and test the original cases.
Use the structured input cases. Check required types, the exact threshold and the supplier rule's priority. The recorded runtime results provide a comparison.
- Review the revised threshold.
Download the 2,500 USD draft as a separate comparison draft. The example uses a different pack ID to keep these offline fixtures separate. In your actual workbook, make the policy change as a new revision of the same pack, save it and rerun its tests.
- Release through the existing review process.
Follow review, separate approval, installation and version selection. Downloaded drafts carry no approval. The recorded comparison does not perform a Studio release or connect to a purchasing system.
What the features contribute#
| Feature | Practical use in this example |
|---|---|
| Ontology and typed inputs | Make “approved supplier,” amount currency and approval status mean the same thing across teams and source systems. |
| Source-linked rule drafts | Let a policy owner compare the proposed rule with the written clause. |
| Tests and immutable review | Show the consequences of a change and bind approval to that reviewed version. |
| Deterministic policy evaluation | Apply the same installed rule to the same facts without asking a model to decide again. |
| Explicit missing-data results | Tell the integration to retrieve a fact or send the case for human handling. |
A conventional rule engine can evaluate these conditions. The value to assess here is the surrounding process: getting a written policy into a cited, tested proposal; connecting its terms to your data; and controlling which reviewed version runs. If your existing system already does that well, compare the effort to maintain it before replacing it.
Start a pilot by measuring time to find the right review route, avoidable handoffs, disagreements with the policy owner and effort to approve a policy change. No native purchasing-language model is supplied or qualified by this example. You can begin with an explicit form or application-selected decision and evaluate language interpretation separately.