When Average Order Value Is a Guess: Business Context in Oracle AI Lakehouse

At the Oracle AI Lakehouse Summit in London on 11 November, one theme stood out to me: giving AI access to enterprise data also means giving it access to the business meaning behind that data.

The sessions covered open data access, catalogues, semantic enrichment and AI agents. What interested me most was how these capabilities might help with a familiar analytics problem: two people ask the same question and receive different answers because their calculations use different definitions.

An AI agent can encounter exactly the same problem. It may find the right tables, generate valid SQL and return a convincing result while making an assumption that the business would never have approved.

Consider a simple question:

What was our average order value in October, by customer region?

Customers, orders and an average. It sounds straightforward. The difficulty is deciding what those words mean in this particular business.

One question, several possible calculations

Imagine a fictional retailer with customer, order, order-line and refund data. Its order records include dates, statuses and amounts. Its customer records include a region.

An agent sees a column called GROSS_ORDER_VALUE and generates this illustrative Oracle SQL:

SELECT
    c.region,
    AVG(o.gross_order_value) AS average_order_value
FROM orders o
JOIN customers c
    ON c.customer_id = o.customer_id
WHERE o.order_date >= DATE '2026-10-01'
  AND o.order_date <  DATE '2026-11-01'
GROUP BY c.region;

The query can execute successfully. The names are plausible. There need not be an invented table or a syntax error anywhere in sight.

Yet it has already selected a date, an amount, an order population and a regional attribution rule. Those are business decisions.

Should cancelled orders count? What about orders awaiting payment? Is the value before or after discounts? Do refunds reduce it? Are tax and delivery included? Does October refer to placement or completion? Should an order use the customer's region today or the region recorded when it was placed?

Without an authoritative definition, the agent might infer answers from column names, examples or conventions. A better response would be to retrieve the approved definition or ask for clarification. Confident SQL is not evidence that those choices were correct.

The difference between £300 and £125

Take these four fictional orders, all placed in October and attributed to the same customer region. The first two also completed in October. Amounts are in GBP; gross merchandise value excludes tax and delivery. Refunds are merchandise refunds after discounts, recorded by the reporting cut-off.

Order	Status at cut-off	Gross merchandise value	Discount	Refund
A1001	Completed	£120	£20	£0
A1002	Completed	£240	£40	£50
A1003	Cancelled	£360	£60	£0
A1004	Awaiting payment	£480	£80	£0

The query above averages gross value across all four orders:

£1,200 ÷ 4 = £300.

For this retailer, “average order value” in management reporting defaults to the approved metric Net Average Order Value:

Net merchandise value after discounts and qualifying refunds, divided by the number of completed orders in the reporting cohort. Tax and delivery are excluded.

For this retailer, the cohort is selected by completion date. Refunds are attributed back to the original order and included up to a stated reporting cut-off. A fully refunded completed order remains in the denominator. All values are reported in GBP, and region is the customer region captured when the order was placed.

Applying that policy:

• A1001 contributes £120 − £20 = £100.
• A1002 contributes £240 − £40 − £50 = £150.
• A1003 and A1004 are excluded because they are not completed orders.

The approved result is therefore:

£250 ÷ 2 = £125.

Both £300 and £125 can be produced from the same underlying records. The difference comes from the rules used to select and interpret them.

This is an illustrative policy, not a universal definition of average order value. Another retailer might legitimately use placed orders, exclude fully refunded orders or recognise refunds in the month they occur. The requirement is to make the chosen policy explicit and reusable.

What business context needs to contain

A description saying “average value of an order” would leave most of the problem unresolved. For this example, useful context needs to be specific enough to guide both query generation and validation.

Definition element	Agreed rule for the fictional retailer
Metric	Net Average Order Value
Numerator	Merchandise value less discounts and qualifying refunds
Denominator	Count of completed orders, including fully refunded completed orders
Period	Order completion date, interpreted in the agreed business time zone
Refund timing	Refunds known by the stated reporting cut-off, attributed to the original order
Exclusions	Tax, delivery, cancelled orders and orders awaiting payment
Currency	GBP; any foreign-currency values converted using the approved rate policy
Region	Customer region captured when the order was placed
Grain	One record per eligible order before calculating the ratio

The grain matters. Joining orders directly to several order lines and several refunds can multiply rows and inflate amounts. The definition therefore needs an implementation that aggregates those details correctly before combining them.

The reporting cut-off matters too. A refund arriving later can change a previously reported result under this policy. Reproducing last month's published figure requires retaining the relevant state or snapshot, together with the definition version and cut-off used.

These are ordinary analytics engineering concerns. Introducing an agent makes them more visible because a user can ask a question without seeing the assumptions hidden in its generated query.

Where the summit announcements fit

One summit slide grouped business semantic enrichment into three capabilities: intelligent annotations, Analytic Views and AI-driven self-enrichment. I see a practical role for each in this example.

Annotations can explain which assets contain completed orders and how refund values should be interpreted. Analytic Views can express governed measures and dimensional relationships. AI-generated descriptions can help teams document assets, with review before those descriptions become trusted context.

Oracle's accompanying AI Data Catalog article describes these enrichment mechanisms and semantic-view import and export through Apache Ossie’s portable YAML format. Apache Ossie is an incubating Apache project.[1]

My proposed use of these capabilities would be to give an agent a discoverable, approved metric and a tested calculation path. This is a proposed design for the fictional retailer; it has not been tested as an end-to-end Oracle implementation.

For instance, a curated reporting view could expose one record per completed order, with the approved net merchandise amount and historical region already resolved. The semantic definition would link “average order value” to this approved dataset, specify the net-value calculation and completed-order count, and identify the applicable date and regional attributes. A prepared view alone does not tell an agent which business question it answers. With that mapping available, query generation would become much more constrained:

-- Illustrative curated view, not an Oracle-supplied object.
-- Its reporting snapshot and metric version are fixed upstream.
SELECT
    customer_region_at_order,
    SUM(net_merchandise_value_gbp)
        / NULLIF(COUNT(*), 0) AS net_average_order_value_gbp
FROM reporting.completed_order_metrics
WHERE completed_business_date >= DATE '2026-10-01'
  AND completed_business_date <  DATE '2026-11-01'
GROUP BY customer_region_at_order;

The important work sits behind that simple query: agreed eligibility rules, refund aggregation, currency handling, historical attributes and reproducible reporting state.

Finding the relevant context

An enterprise catalogue might contain several order tables, staging copies, regional extracts and abandoned reporting views. The agent also needs help finding the approved assets.

Oracle describes catalogue-side agentic search that narrows discovery using the question, metadata and user permissions. Its semantic enrichment and pruning article explains how focused retrieval can reduce the metadata passed to consuming agents.[2]

In this scenario, I would want retrieval to return the approved metric, its supporting order dataset and the relevant regional relationship. Finding those assets efficiently is useful, but it still needs to be followed by correct execution of their rules.

Why Ossie matters across analytics tools

The portability question becomes interesting when the same measure appears in an Oracle Analytics dashboard, a Power BI report and an agent's response.

Oracle explicitly describes support for Apache Ossie to exchange semantic metadata, including datasets, fields, metrics and relationships.[2] That creates a basis for evaluating how existing definitions can be reused by compatible consumers.

For our retailer, the test would be whether each supported consumption path preserves the completed-order population, refund treatment, date rules and aggregation behaviour. Exchanging a model file is one step. Demonstrating equivalent results is another.

Average order value also exposes a familiar aggregation trap: the overall result must be calculated from total eligible value divided by total eligible orders. Averaging regional averages gives the wrong result when regions have different order counts.

I would therefore validate the metric using cases that include cancelled orders, partial and full refunds, multiple order lines, changing customer regions and unequal regional order counts. Equivalent results also require the same reporting cut-off and access scope. Two users with different permissions may legitimately see different figures.

A clearer platform distinction is still needed

One question I left the summit with concerns the relationship between Oracle AI Data Platform Workbench and Autonomous AI Lakehouse. Having worked with AIDP, I recognised many familiar capabilities in the Lakehouse presentations: notebooks, workflows, catalogues, data transformation and Spark processing.

Similar feature names do not necessarily mean identical implementations, but they make it difficult to understand where a workload should be developed, orchestrated and executed. Oracle’s description of Lakehouse Transform delegating Spark execution to AIDP Workbench illustrates how the environments can work together.

What I would welcome next is a practical reference architecture showing when to use each environment, how their catalogues and security controls interact, and what choosing either path means for deployment, monitoring and cost. That would help customers turn a broad set of capabilities into clear implementation decisions.

The demonstration I would like to see

For me, a convincing demonstration would start with the same customer-and-orders question asked through several supported interfaces. Each answer would identify the approved metric, apply its rules and reconcile to known expected results.

Where the user asks only for “average order value” and several definitions exist, the agent should offer the relevant approved choices or ask which one is intended. Where there is a clear organisational default, it should state that definition alongside the answer.

My main takeaway from the summit is that business context deserves the same engineering attention as ingestion, transformation and query performance. Open access can make the records available. Governed semantics can make their intended interpretation available too.

An answer of £125 becomes useful when the business can see why those two orders count, why £250 belongs in the numerator and which reporting state the calculation represents.

That is the standard I would use to assess an AI agent answering a business question.

---

Sources

1. Oracle, Connect, access, and govern multicloud data estates with Oracle Autonomous AI Lakehouse, 26 October 2026.
2. Oracle, Reduce token usage by over 10x with Oracle Autonomous AI Lakehouse, 26 October 2026.
3. Author's notes and photographs from the Oracle AI Lakehouse Summit, London, 11 November 2026.