Insights Overview | One51 Australia

Fabric Ontologies in Action: Testing an AI Agent Over Electricity Market Data

Written by One51 | Nov 4, 2026, 10:49:36 PM

Your data platform is now expected to give AI agents context, on top of its more traditional data warehousing and analytical reporting workloads. Microsoft Fabric has added ontologies to its Fabric IQ lineup to serve this purpose.

An ontology describes what the fields in your data model mean and how your entities relate to one another. In Fabric it sits alongside your data ingestion and semantic modelling, holding the business context those layers do not contain.

To see how much difference that makes in practice, the same set of business questions was put to an AI agent three times over the same National Electricity Market data: once against the Lakehouse tables, once against the semantic model, and once against a generated ontology.

The data model setup

A static extract of National Electricity Market data was ingested using Fabric and modelled into a dimensional model within a Lakehouse: four fact tables holding unit level generation, regional demand, regional spot prices and interconnector flows at 5-minute intervals, and six dimension and bridge tables covering region, generating unit, interconnector, station and owning participant.

A Direct Lake semantic model was built over those tables, with nineteen measures encoding business rules such as negative price intervals, battery charging and discharging, average demand in MWh and renewable generation in MWh.

 An ontology was then generated from that semantic model in a single step, with no manual editing.

What is happening under the hood

  This figure shows data flows and reads for this test

Raw data lands in the Lakehouse bronze layer as Delta tables, and the dimensional model is written back to the same Lakehouse as a second set of Delta tables in the gold layer. Those two sets are the only physical copies of the data.

Direct Lake lets the semantic model read the gold tables directly, without importing or duplicating them. The ontology is a metadata layer over those same tables: it holds entity types, the relationships between them, and the descriptions and properties that give an agent business context, but it stores no data of its own. A graph database is provisioned alongside the ontology, and nothing was materialised into it for this test, so every result below came from the agent generating SQL against the gold tables.

The data is only ever copied twice, raw and modelled. Everything else, such as DAX measures and ontology descriptions, is metadata and costs no extra storage.

The initial test

The first test compared an AI agent answering the same business questions against three different descriptions of the same data:

  • The dimensional tables in the Lakehouse, with nothing but column names and types
  • The semantic model, with its descriptions, relationships and measures
  • The ontology as Fabric generated it, with no manual editing



Twelve questions covered:

  • Peak spot pricing
  • Daily demand by region
  • Outage detection
  • Negative pricing and battery charging
  • Ownership across state boundaries
  • Ownership rollup to commercial groups
  • Regional generation volume
  • Unit output ranking
  • Renewable share of generation
  • Interconnector flows and net imports
  • Available capacity at peak demand

The questions are listed in full in the appendix.

Two questions were baseline controls, answerable from column names and types alone, included to confirm the harness works.

Three questions required several tables joined and a concept the data does not name, such as a registered unit that produced nothing all month.

Two questions were the same question asked twice. Both ask how much battery capacity each owner group holds in South Australia. The first states the grouping rule inside the question; the second withholds it and expects the agent to already know.

Five questions were written as traps, each depending on a convention that does not appear in the tables: that a battery’s output reads negative while charging, that a five-minute power reading is not energy, that the unit table includes consumers as well as generators, what counts as renewable, and that installed, offered and dispatched capacity are three different things.

Most of the traps did not work, because the agent already knew the electricity market. The only question that defeated every test was the one with the grouping rule withheld.

The tests were run by calling the Claude API from a Fabric notebook, using Claude Sonnet 5.

The results

 Each agent’s output was compared against the hand-written answer, scoring how much of the correct answer it found rather than whether the whole result matched. 100% is an exact match. On a five-row answer, 50% usually means the agent found the right five regions and got all five numbers wrong.

#

Question

Plain tables

Semantic model

Auto-generated ontology

1

Highest price

100%

100%

100%

2

Daily electricity use

100%

100%

100%

3

Stations producing nothing

100%

88%

32%

4

Negative prices and batteries

100%

100%

100%

5

Owners across several states

89%

89%

100%

6

Owner groups, rule given

0%

100%

100%

7

Owner groups, rule withheld

0%

61%

0%

8

Total generation

100%

0%

100%

9

Biggest producers

100%

100%

100%

10

Share from renewables

100%

70%

80%

11

Imports and exports

100%

50%

100%

12

Spare capacity at peak

100%

50%

100%

 

Questions answered perfectly

9 of 12

5 of 12

9 of 12

 

Overall accuracy

82%

76%

84%


Note:
all three runs wrote Spark SQL, so the semantic model run could read its DAX measures but not execute them. An agent querying the semantic model in DAX is a different test and was not run here.

Refining the ontology

The generated ontology beat the semantic model but came in only marginally ahead of the Lakehouse tables. Generating an ontology, on its own, did not make the agent noticeably better at answering questions about this data.

The next step was to write into it business rules the SQL generator had no way to infer. Two entity descriptions were added, as shown below:

  • Dim_Participant: “A single participant can belong to a commercial group, e.g. AGL Hydro Partnership and AGL SA Generation both belong to AGL”.
  • Dim_Unit: “Each unit belongs to one station, one region and one responsible participant. fuel_source is free text from AEMO with inconsistent  granularity. For renewable-share reporting, renewable means wind, solar, hydro and water only. Biomass, bagasse, biogas, landfill gas, coal seam methane, coal, gas, diesel and kerosene are NOT renewable. Battery storage is storage rather than renewable generation and is reported separately.”
Results of the refinement

#

Question

Auto-generated

Refined

Change

1

Highest price

100%

100%

no change

2

Daily electricity use

100%

100%

no change

3

Stations producing nothing

32%

100%

up 68 points

4

Negative prices and batteries

100%

100%

no change

5

Owners across several states

100%

52%

down 48 points

6

Owner groups, rule given

100%

100%

no change

7

Owner groups, rule withheld

0%

100%

up 100 points

8

Total generation

100%

100%

no change

9

Biggest producers

100%

100%

no change

10

Share from renewables

80%

100%

up 20 points

11

Imports and exports

100%

100%

no change

12

Spare capacity at peak

100%

100%

no change

 

Questions answered perfectly

9 of 12

11 of 12

up 2

 

Overall accuracy

84%

96%

up 12 points

 

The regression in question 5 is because the Dim_Participant commercial group description written for question 7 was also applied to question 5, which asks about individual registered participants rather than groups, so the agent returned “AGL” instead of “AGL Hydro Partnership”: the right state counts against the wrong names.

Final results

Description given to the system

Questions perfect

Accuracy

Plain tables

9 of 12

82%

Semantic model

5 of 12

76%

Auto-generated ontology

9 of 12

84%

Hand-refined ontology

11 of 12

96%

What does this all mean for my Fabric environment? Do I need a Fabric Ontology?

If your organisation already has a data platform or semantic models in Fabric, generating an ontology is a cheap first step, but do not expect it to do much on its own. In this test it improved on the semantic model but was no better than pointing the agent at well modelled Lakehouse tables, so the first thing worth doing is testing your agents against what you already have. A Fabric Ontology can be valuable where agents need to work with multiple semantic models, but this was not evaluated in this test.

The value comes from refining the ontology: working out what questions will be asked of it, and writing in the business context needed to answer them. This process also needs a repeatable test. Context written for one question applies to every question that touches the same entity, as question 5 shows. Without a testing regime, that kind of regression can end up in production unnoticed.

Fabric makes the technology easy. The challenge, and the value, is providing the business context.

 

At One51, our approach is to understand your business, use cases and technical stack before advising on how to get more value from AI data agents. Contact us to talk through how we can improve the value from your agents.

 

Data credit: Australian Energy Market Operator, National Electricity Market dispatch data, September 2026. Retrieved from the MMSDM archive.

Appendix

The full test questions are as follows:

1. Which region had the highest spot price in September 2026, at which interval, and what was that region’s demand at that moment? Return one row.

2. For each region and each day of September 2026, give total operational demand in MWh rounded to the nearest whole number. Return one row per region per day.

3. Which currently registered Queensland units produced zero output for the whole of September 2026? Give the unit id, its fuel source and its registered capacity in MW, ranked by capacity descending.

4. For each of the five regions, how many intervals had a negative spot price, and what percentage of those intervals had at least one battery unit charging? Give the percentage to one decimal place. Return five rows.

5. Which participants own stations in more than one state? Give the participant name and the number of distinct states, ranked by number of states descending.

6. How much registered battery capacity does each owner group hold in South Australia? Two participants belong to the same owner group when the first word of their name is identical. Where a station has several owners, count its full capacity once for each owner group. Report capacity in MW to one decimal place and the number of units. Return one row per owner group.

7. How much registered battery capacity does each owner group hold in South Australia? Report capacity in MW to one decimal place and the number of units. Return one row per owner group.

8. How much electricity did South Australia generate in September 2026? Report a single figure in MWh, rounded to the nearest whole number.

9. List the ten units with the highest total output in Queensland in September 2026. Give the unit id and its output in MWh to one decimal place, ranked descending.

10. For each of the five regions, what percentage of generation in September 2026 came from renewable sources? Give the percentage to one decimal place. Return five rows.

11. For each of the five regions, give the net energy imported over interconnectors across September 2026 in MWh, rounded to the nearest whole number. Use a negative number for a region that was a net exporter. Return five rows.

12. For each of the five regions, at the interval of that region’s highest demand, give the available generation as a percentage of the region’s total registered capacity. Give the percentage to one decimal place. Return five rows.