LLM vs Ontology vs Calculation: Who Owns Which Reasoning Step in Procurement?

Reconciling 100 vs 60: The Calculation Breakdown

Assume the procurement lead confirms the target for Warehouse 1's 6204 bearing: current available stock plus eligible incoming purchase orders within the replenishment period must reach 300 units. The query returns 120 units available and 12 boxes (10 units each) of valid, unfulfilled purchase orders expected to arrive within the period. After deduplication:

300 − 120 − 12 × 10 = 60 units.

Additional constraints (minimum order quantity, packaging) allow 60 units. The assistant's 100-unit suggestion likely missed a purchase order, misapplied a "keep extra" heuristic, or used a different period.

Decomposing "Reasoning" to Assign Responsibility

In project discussions, "reasoning" conflates several tasks: understanding the user's question, identifying the correct entities, calculating the quantity, and explaining the result. The article separates these:

Understanding the question (LLM): The large model clarifies the product (SKU 6204), warehouse (Warehouse 1), and replenishment period. It reuses context from the conversation but asks for clarification when ambiguity remains.

Semantic mapping (Ontology): An ontology (e.g., OWL) defines what "bearing," "spare part," "available stock," and "unfulfilled purchase order" mean and how they relate. A reasoner can infer that a bearing is a spare part, but it cannot catch misclassified real-world items.

Querying records: The query service retrieves 120 available units and 12 boxes of valid unfulfilled orders, recording source, cutoff time, validity, and completeness.

Calculating quantity (Calculation service): Units are normalized, the replenishment rule is applied, and the result (60) is checked against MOQ and packaging rules. The rule version, inputs, conversion logic, and output are logged.

Explaining the recommendation (LLM): The model presents the 60-unit figure with its rationale and flags open confirmations. The explanation must match the calculated quantity, unit, and caveats exactly.

Business calculation and formal inference have different inputs; when errors occur, each must be traced to its own evidence.

What the Buyer's "Why" Should Reveal

A table (converted to list) outlines each step, its execution in the example, and what must be auditable:

Understand question: Fixed product, warehouse, period. Auditable: user utterance, clarification results, final parameters.

Identify entities & meanings: Mapped SKU6204 to system ID, distinguished available stock from unfulfilled orders. Auditable: mapping version, inventory definition used.

Query records: Retrieved 120 available + 12 boxes valid unfulfilled. Auditable: data sources, cutoff, validity, completeness.

Calculate quantity: Normalized units, applied rule → 60, verified MOQ/packaging. Auditable: rule version, inputs, conversion, result.

Explain recommendation: Told buyer why 60, what needs confirmation. Auditable: quantity, unit, and explanation consistency with query and calculation.

If the purchase-order query returns cancelled orders or deliveries outside the period, they are excluded per confirmed rules and the calculation is re-run. The result cannot be reused with a "for reference only" disclaimer. A rule mismatch (e.g., applying a replenishment rule to a make-to-order item) also produces a correct calculation for the wrong business case.

Handling Missing Data: Unknown ≠ Zero

If the purchase-order query times out while inventory succeeds, the assistant must state: "Warehouse 1 has 120 available. Purchase query timed out; incoming quantity unknown. Cannot compute replenishment. Retrying..." It must not substitute zero for the missing value, which would incorrectly yield 180 units. The OWL open-world assumption (absence of a statement ≠ false) reinforces this, but the application must explicitly check query success and completeness; the reasoner does not do this automatically.

The formula can compute correctly, but treating unknown purchase quantity as zero still yields a wrong recommendation.

When the Service Returns 60 but the Assistant Writes 100

If the calculation service returns 60 but the generated text says 100, the system must compare the raw tool output with the final answer, block the inconsistent response, and either retry or flag for review. The model may still raise useful hypotheses (e.g., a purchase order might be delayed), but such hypotheses are not grounds for changing the calculated number without re-running the calculation with verified data.

Test Scenarios and Consistency Checks

Normal case (complete data, applicable rules) → return 60 with provenance; purchase still follows approval workflow.

Unclear purchase-order unit → do not merge quantities; report missing unit/conversion.

SKU maps to multiple specifications → escalate to master-data owner.

Purchase interface failure → report missing data, do not default to zero.

Model output (100) ≠ service output (60) → block, reconcile, regenerate.

Two approved rules conflict → list conflict, escalate to rule owner; do not average or pick the larger.

Tests must run with fixed data and rules, varying phrasing and warehouse to ensure the assistant does not inadvertently alter numbers, units, or constraints.

Retain raw tool output, compare with generated explanation, avoid correct calculation but wrong output.

Summary

When faced with conflicting recommendations (100 vs 60), the buyer should not guess. Instead, compare the product, period, purchase orders, and rules used by each side. Missing orders are re-queried; rule discrepancies are escalated; correct calculations with wrong outputs are caught at the generation layer. The next article will cover how the calculated quantity feeds into a "create purchase order" action via MCP, workflows, and business actions.

Reference

W3C, OWL 2 Web Ontology Language Primer (Second Edition) , Sections 2–3 and open-world discussion. Used to illustrate declarative ontologies, formal inference, and the semantics of unrecorded facts; the replenishment rules, responsibility split, and test cases are the author's design. https://www.w3.org/TR/owl2-primer/