Ontology Built: Must AI Auto-Execute? Scoping Safe Procurement Automation
The article argues that building an ontology doesn't mandate full AI automation; instead, procurement automation should be scoped per task across four levels—query, suggest, per-order approval, and pre-authorized auto-execution—with rigorous checks on objects, data, permissions, quotas, idempotency, and exception handling, plus pause/resume procedures and holistic testing that counts rework and maintenance costs.
Context: Replenishment Assistant and the Push for Full Automation
A replenishment assistant reduced manual system-switching and calculation for purchasers. The project manager wanted the next version to auto-create purchase orders, but the procurement lead asked: what if the supplier changes, the amount exceeds limits, or inventory data is stale? Who handles failures after hours?
The previous article defined conditions for a valid purchase order. This article asks which tasks can be safely auto-executed and which still require human approval. It uses a hypothetical Warehouse No.1 bearing replenishment case; the arrangements are discussion material, not an industry standard or field-validated design.
What Does Skipping One Confirmation Actually Save?
Previously, a purchaser opened the warehouse system, then the purchasing system, converted units, and calculated manually. The assistant now queries and calculates, saving time. The next step—auto-creating a purchase order—modifies system records and may send the order to the supplier, adding another impact layer. The ontology clarifies relationships among items, inventory, suggestions, and approvals, but authority, limits, and error ownership must be defined separately.
Whether skipping a click is beneficial depends on what responsibility that click carried. If it merely re-enters approved parameters, automation can be considered; if it involves judging supplier or price, that judgment's ownership must be resolved before removing the button.
The scope of automation depends on what judgment the human operation still contains.
Same Assistant, Multiple Usage Modes
Common bearings and ad-hoc spare parts may need different approaches. Four modes can coexist long-term; not every project must progress linearly through all levels.
Query only: Shows inventory and purchase orders the user is permitted to see, citing source and timestamp. Does not judge quantity or create orders.
Suggest: Calculates quantity per confirmed rules and lists the basis. The suggestion has not received purchasing approval, so no auto-creation.
Per-order approval then execute: Submits the approved item, quantity, etc., to the original system. If parameters change or approval expires, pause for verification.
Pre-authorized auto-execution: Each run checks object, rules, quota; submits only if within scope. Out-of-scope goes to authorized personnel; results still require verification.
Which tasks are query-only, which get suggestions, which can auto-execute—agree per item and task.
Pre-authorization means an authorized person pre-approves tasks, conditions, validity periods, and limits. The program checks every time; past approvals do not justify future auto-approval. For volatile prices or suppliers, keep per-order review. Stable repetitive tasks can be evaluated for auto-execution, but not every step needs an LLM; existing workflows can continue.
Don't Just Say "Small Amount Auto" — Define the Scope Fully
Example: SKU6204, supplier SUP01, validated replenishment rules. This scope is clearer than "common spare parts auto-replenish" but still incomplete. Needed specifics: max per-order quantity and amount, cumulative quota period (day/month), data freshness threshold, allowed time windows. Each enterprise's approval authority and risk differ; no universal amount is prescribed.
Item, warehouse, rule: Verify if the object is approved for auto-execution and which rule version is used. Mismatch → pause; verified records remain viewable.
Data: Are inventory and purchase records complete and fresh enough? Can receipt updates reconcile? If not, re-query; if unclear, note missing data and do not order.
Permissions & approval: Is the execution identity authorized? Is the current approval or pre-authorization still valid? If not, reject and escalate to authorized person.
Quota: Would this order plus used quota within the period exceed the limit? If so, escalate to human; cannot split into smaller orders to bypass.
Duplicate submission & result: Can the system prevent duplicate order creation? Can it retrieve the original system's result? If not, hold auto-create; check submitted requests first, don't re-execute blindly.
Exception handoff: Who handles, within what time, where to view materials and continue? If not arranged, do not enable unattended execution.
Quota must be coordinated during concurrent execution; timeout cannot be treated as no occupancy; verify results before releasing per execution rules.
These checks must be enforced by the program regardless of trigger (chat, scheduled job, human takeover)—not just a prompt like "don't exceed quota." NIST's AI Risk Management Framework also emphasizes context-specific risk management (NIST AI RMF). The table above is discussion material for the replenishment case, not a prescribed procurement grading standard.
After Pause, What About In-Flight Requests?
Before enabling auto-execution, define stop conditions: critical inventory exceeds allowed delay, unit conversion error, batch requests stuck. Degrade by temporarily disabling affected functions and handing to responsible staff. Example: purchasing interface down but inventory interface up → show inventory, note purchase records incomplete, cannot calculate replenishment. One SKU mapping fails → pause that SKU; assess impact on others via shared mappings/services.
Overlooked: in-flight requests. Example: a 60-unit order request times out, then auto-execution stops. The purchasing system may still process that order; cannot mark it failed just because the assistant stopped. Handoff to purchaser must include original request, approval content, and known results. Handoff to human is to let them verify this specific order, not create a new one. First verify where the old request got to, then decide next steps (detailed in article 07).
Recovery: not just interface restored. Root cause fixed? Affected records reconciled? Test cases re-run? Who approves re-opening? Pending tasks must re-validate requirements, data, approvals; not blindly replay backlog.
Pause controls subsequent actions; already-sent requests still need someone to verify results.
Small-Scale Trial: Don't Just Count Auto-Executed Orders
Start with suggestion-only mode; have purchaser independently verify same records/rules. When results meet agreed criteria, trial auto-execution in approved small scope, observe correctness and handoff capability. Example: 60-unit request should succeed when conditions met; when missing approval or over quota, should explain reason and escalate. If all requests are rejected, no wrong orders but also no help.
In test environment: test concurrent quota exceedance, simultaneous quota occupancy, approval expiry, data timeout. After revoking execution permission, test old session or queued task to see if program re-checks.
Record manual verification, approval wait, error rework, maintenance time. If order entry saved but purchaser spends all day chasing errors, consider reverting tasks to manual. Separate test case pass records from live observation notes.
Compare before/after auto-execution by recording whole-task wait, rework, and maintenance effort; diagram shows no actual timing data.
Summary
The click the project manager wants to remove may be just duplicate entry or may include purchaser judgment on supplier, price, or exceptions. The former can consider automation; the latter prepare evidence so purchaser can see clearly and approve quickly. Which purchases to automate is an enterprise decision. The ontology helps the team verify conditions and responsibilities, but whether purchaser workload decreases and errors are handled timely must be seen in trial records. The next article will cover connecting suggestion, approval, and creation to avoid "approved but not executed."
References
NIST, AI Risk Management Framework (AI RMF) official resources and core framework. Used to introduce context-specific risk management thinking; capability divisions, procurement thresholds, and trial steps are author suggestions, not compliance proof.
https://airc.nist.gov/airmf-resources/airmf/Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Data Bricklaying Diary
Records practices, thoughts, and pitfalls on the data grunt-work journey, sharing content on data platforms, data analysis, data processing, data governance, knowledge graphs, and more. Less theory, more hands‑on, making complex data technologies simple.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
