Dr. Estera Kot

From Events to Answers · Part 3 of 7

What an ontology is, and why a data agent needs one

A worked example in Microsoft Fabric IQ: six entity types, four relationships, and one rule that changes what a data agent answers.

By Dr. Estera Kot, Microsoft MVP, CTO at Clouds on Mars, and former Microsoft Principal Product Manager for the Apache Spark runtime in Fabric. Published . Product facts checked against Microsoft Learn on November 3, 2026.

A person asks a data agent: which formulas are winners? No table has a column called winner. The word belongs to the business. The data holds a column called first_choice_pct.

An ontology in Microsoft Fabric IQ is the dictionary of the business. It names the things a business talks about, how they connect, and what its words mean. It also binds each thing to the tables that hold its data, without copying them. A data agent reads that dictionary before it writes a query.

This is Part 3 of From Events to Answers. Part 1 tells the whole story of the session. All demo data is synthetic. This post makes one claim. Without an ontology, a data agent guesses what a word means from column names. With one, you change a definition, and the answer changes. The agent and the data stay as they are. Business meaning moves out of prompts and into a governed item.

In short

  1. An ontology in Fabric IQ holds entity types, properties, relationships, bindings to data, and rules written in plain language. It copies no data, and it is in preview.
  2. A data agent without an ontology maps business words to column names by itself. In the demo, no item defined winner, so the expected answer was five formulas or “not defined.”
  3. One rule linked to the Trial entity type, winner means first choice above 60, changed the expected answer to OB-104 and OB-105. No table and no agent instruction changed.
  4. Plan for preview limits. The demo dropped one entity because its key had two columns. Learn states that a data agent picks up ontology changes within 10 minutes unless you refresh it.
  5. Dr. Kot's position: build an ontology when several tools or teams must agree on one word. For one table and one report, a good column description is enough.
The demo ontology as built: six entity types, four relationships, seven tables Seven nodes in a row. Six are entity types: Ingredient, Formula, OptimizationResult, Trial, Study, and Document. One dashed node, Inclusion, was designed but not built because its key had two columns. Arcs above the row show four relationships: Trial tests Formula, OptimizationResult optimizes Formula, Trial belongs to Study, and Document reports Study. Dashed arcs show the two relationships that were dropped with Inclusion. Lines below each node lead to the lakehouse table it is bound to. The table formula_ingredients is in the definition but has no entity. Three more lakehouse tables are not in the ontology: formula_metrics, formula_overview, and study_recommendations. Oud_RnD_Ontology, as built Six entity types, four relationships, seven tables in the definition Entity type Designed, not built Relationship Bound to a table Inclusion was in the design. Its key had two columns, and the API rejected it. tests optimizes belongs to reports contains uses Ingredient Inclusion Formula OptimizationResult Trial Study Document key ingredient_id two-column key key formula_id key formula_id key trial_id key study_id key chunk_id ingredients formulas preference_trials doc_chunks formula_ingredients formula_optimization documents Also in the lakehouse, not in the ontology: formula_metrics formula_overview study_recommendations The agent reads these three as plain tables. The ontology gives them no business meaning. The demo ontology as built: six entity types, four relationships, seven tables Seven entity types in a column with the table each one is bound to. Inclusion is dashed because it was designed but not built: its key had two columns. Lines between the nodes show the relationships: Trial tests Formula, Trial belongs to Study, Document reports Study, and OptimizationResult optimizes Formula. Three lakehouse tables are not in the ontology. Oud_RnD_Ontology, as built 6 entity types, 4 relationships, 7 tables Ingredient Inclusion Formula Trial Study Document OptimizationResult bound to ingredients formula_ingredients, two-column key bound to formulas bound to preference_trials bound to documents bound to doc_chunks bound to formula_optimization Inclusion uses Ingredient (not built) Formula contains Inclusion (not built) Trial tests Formula Trial belongs to Study Document reports Study OptimizationResult optimizes Formula Not in the ontology: formula_metrics, formula_overview, study_recommendations
Figure 1. The demo ontology as built. Six entity types sit on six lakehouse tables, and four relationships connect five of them. Inclusion was designed but not built, so formula_ingredients sits in the definition with no entity, and Ingredient has no relationship.

Why a data agent needs business meaning

A data agent reads table words, and people ask in business words. Wrong answers start in the gap between the two.

The demo lakehouse has a trial table called preference_trials. Its columns include formula_id, n_testers, first_choice_pct, and dwell_ratio. First choice is the share of testers who reached for one blotter first in a paired test. The business calls a formula a winner when that share is above 60.

That sentence is in no table and in no column name. If no item defines it, the agent must choose a meaning. It can pick above 50, because the Trial description says above 50 means preferred over the reference. It can pick the highest value. It answers either way, and the answer sounds sure.

Dr. Kot's view, from data platform work: the most important rule often lives in the worst place. It sits in a spreadsheet, in a macro inside one report, or in one person's head. The platform works. The definition has no home.

What is an ontology in Microsoft Fabric IQ

An ontology in Microsoft Fabric IQ is a Fabric item that defines business concepts, their properties, how they relate, and the rules that give them meaning. It binds those definitions to data in Fabric, and the data stays in its source. People, applications, and AI agents then share one vocabulary. The ontology item is in preview Preview. Learn states that the old experience retires on January 31, 2027.

IDTerm on LearnPlain wordsIn the demo
O1Entity typeA business thing, with a name, a description, and propertiesFormula, Trial, Study
O2PropertyOne characteristic of an entity type, with a data typefirst_choice_pct on Trial
O3RelationshipHow two entity types connectTrial tests Formula
O4Data bindingWhich table and columns supply the values of an entity typeTrial is bound to preference_trials
O5Entity type keyThe property that identifies one instancetrial_id
O6RuleBusiness logic in natural language, linked to entity types and propertiesA formula is called a winner only when first choice is above 60
O7MetricA DAX measure from a semantic model, kept with its sourceNot used

Two facts from Learn help beginners most. First, the ontology stores definitions and bindings. It is not a query engine. The agent or dashboard that uses it sends the query to the bound source. Second, a rule is text. Learn states that the ontology does not run a rule against data. A consumer, such as an agent, reads the rule and applies it.

Supported binding sources are eventhouses, KQL databases, lakehouses, mirrored databases, semantic models, SQL databases, and warehouses. The overview also names OneLake shortcuts, views, and materialized views. The demo bound lakehouse tables only. For the new ontology experience as shown at FabCon Europe 2026, see the post on the ontology in Fabric IQ.

What a Fabric data agent is, and what Fabric IQ includes

A Fabric data agent is a chat on your data. You ask in plain language. The agent picks a source, writes a read-only SQL, DAX, or KQL query, runs it with your permissions, and writes the answer. Learn lists the data agent as generally available GA. It needs a paid F2 or higher capacity, or Power BI Premium P1 or higher with Fabric enabled.

One agent takes up to five sources: lakehouses, warehouses, KQL databases, semantic models, ontologies, and Microsoft Graph. An ontology as an agent source is in preview Preview. Learn calls it a context source. It gives meaning, and the lakehouse or warehouse behind it runs the query.

Fabric IQ is the wider name. Learn places it in Microsoft IQ, next to Work IQ, Foundry IQ, and Web IQ. Fabric IQ gives context on business entities and data. Inside Fabric, the IQ workload Preview groups six items: ontology, Power BI semantic model, planning, graph, data agent, and operations agent.

One question is bigger than this post: how do you stop an agent from inventing numbers? Part 4 answers it with the same demo. For a data agent over a lakehouse as shown at FabCon, see the post on the Fabric data agent.

The demo ontology: six entities, four relationships

The demo ontology, Oud_RnD_Ontology, has six entity types: Formula, Ingredient, Study, Trial, Document, and OptimizationResult. Four relationships connect them. Trial tests Formula. Trial belongs to Study. Document reports Study. OptimizationResult optimizes Formula. The definition names seven lakehouse tables, and six of them back an entity, as Figure 1 shows.

Each entity type has one key. Formula uses formula_id, Trial uses trial_id, and Study uses study_id on the documents table. Document is one passage of a study report, keyed by chunk_id on doc_chunks. Each entity type also carries a description and synonyms. Trial has the synonym Paired Blotter Test, for example, and Formula has Blend.

The ontology was written as a definition file and pushed through the Fabric REST API. The ontology agent did not generate it. The winner rule was left out on purpose, so the live edit could add it.

Why the design had seven entities and the build has six

The design sheet listed seven entities and seven relationships. The seventh entity was Inclusion: the share of one ingredient in one formula. It sat on the bridge table formula_ingredients, with a key of two columns, formula_id and ingredient_id. On October 14, 2026, the API rejected that key. The build dropped Inclusion and its two relationships, contains and uses. The design's seventh relationship, Formula evaluated in Study through Trial, never became a binding of its own.

Learn today explains the rejection. In the definition format of the new experience, the entity type key is a single property. A repeated key line or a comma-separated list is rejected. The key must be a string or an integer. One Learn tutorial still shows a key of two columns picked in the editor. Test your own path before you design around it TBC.

The cost shows in Figure 1. Ingredient has no relationship at all. The ontology cannot walk from a formula to its raw materials. The agent can still join the tables in SQL, but the ontology adds no meaning to that join. A smaller gap sits on Formula. Cost per kg lives in formula_metrics and formula_overview, and the ontology binds neither. In the demo, the agent read cost straight from the lakehouse.

Three ways out fit what Learn documents today. First, add one key column to the bridge table, for example an inclusion_id, and keep Inclusion as an entity. Second, make Inclusion a keyless entity type, which the updated ontology model now supports. Learn requires a key for graph projection, so a keyless entity stays out of a materialized graph. Third, drop the entity and model a relationship with a mapping table: Formula uses Ingredient, through formula_ingredients. That junction table must not also back an entity, and the share in percent stays outside the ontology.

How a data agent answers one question

Take one question from the session: for winners, what is the cost per kg, and what did the study recommend? Five steps answer it, and each step has one owner. The ontology resolves the word winner. The agent writes SQL for the numbers and for the report text. A cost reduction question takes a fixed route to an optimizer table, and the stored row comes back unchanged. The language model writes the sentence.

The path of one question through four lanes A swimlane diagram with four lanes: ontology, SQL by the agent, deterministic route, and language model. Step Q1 sits in the ontology lane and resolves winner as first choice above 60. Steps Q2 and Q3 sit in the SQL lane: cost and first choice from formula_overview, and the recommendation from doc_chunks. Step Q4 sits in the deterministic lane and runs only for cost reduction questions: it returns the optimizer row as stored. Step Q5 sits in the language model lane and writes the sentence. A solid line runs from Q1 through Q3 to Q5. A dashed detour runs through Q4. For winners, what is the cost per kg, and what did the study recommend? Q1 Resolve winner Q2 Get the numbers Q3 Get the reason Q4 Cost cuts only Q5 Write the answer first choiceabove 60 cost, first choiceformula_overview recommendationfrom doc_chunks row returned as isoptimizer table a sentence aroundthe returned values Ontology the business meaning SQL by the agent run on the lakehouse Deterministic route stored result, as is Language model the words only Q1 Q2 Q3 Q4 Q5 The ontology gives the meaning. Tables give the numbers. The model writes the words. Q4 runs only when a question asks to cut cost. Other questions go from Q3 to Q5. The path of one question, step by step Five steps from top to bottom. Each step sits in the column of its owner. Q1, ontology, resolves winner as first choice above 60. Q2 and Q3, SQL by the agent, get cost and first choice from formula_overview and the recommendation from doc_chunks. Q4, deterministic route, runs only for cost reduction questions. Q5, language model, writes the sentence. For winners, what is the cost per kg, and what did the study recommend? 1 2 3 4 5 Q1 Ontology Resolves winner as first choice above 60. Q2 SQL by the agent Cost and first choice from formula_overview. Q3 SQL by the agent Recommendation and file name from doc_chunks. Q4 Deterministic route Cost cuts only: the optimizer row, as stored. Q5 Language model Writes the sentence. Adds no numbers. The ontology gives the meaning. Tables give the numbers. The model writes the words.
Figure 2. The path of one question. Each lane is one owner. The dashed detour through Q4 runs only when a question asks to reduce cost.

The expected answer comes from the session's answer sheet. OB-104 has 68% first choice and costs 14,353 QAR per kg, from study ST-12. OB-105 has 61% and costs 13,273 QAR per kg, from study ST-14. ST-12 recommends the industrial pilot for OB-104, with the material S-7 kept at or above 1.5%. ST-14 says the maceration step drives acceptance and approves OB-105 for a wear test at home.

Learn describes the same split of work. The ontology provides meaning, the data agent orchestrates, and the underlying source runs the query under the user's permissions. Learn also states that the data agent does not read PDF files. In the demo, the report passages were prepared in advance and loaded into the doc_chunks table.

The language model writes the query and the sentence. It does not produce the numbers. Part 4 shows how the demo enforced that rule for the optimizer.

Change one rule, change the answer

The session asked the agent the same question twice: which formulas are winners? Before the edit, no item defined winner. The Trial description said only that above 50 means preferred. The expected answer was five formulas, OB-102, OB-103, OB-104, OB-105, and OB-106, or “winner is not defined.” Then one rule went into the ontology. The expected answer became OB-104 and OB-105 only.

Which formulas are winners, before and after one rule Two strips on the same scale of first choice, from 40 to 70 percent. Each strip shows seven trials: OB-105 at 44 in study ST-13, OB-101 at 48, OB-103 at 51, OB-106 at 53, OB-102 at 57, OB-105 at 61 in study ST-14, and OB-104 at 68. Before the edit, the line sits at 50 and five formulas are in the expected answer: OB-102, OB-103, OB-104, OB-105, and OB-106, or winner is not defined. Between the strips sits the one change: a rule that a formula is called a winner only when first choice is above 60. After the edit, the line sits at 60 and the expected answer is OB-104 and OB-105. Which formulas are winners? Expected answers from the session script. Same tables, same agent instructions. Before the edit Trial description says above 50 means preferred 50 OB-10544 (ST-13) OB-10351 OB-10257 OB-10468 48OB-101 53OB-106 61 (ST-14)OB-105 Expected answer OB-102, OB-103, OB-104, OB-105, OB-106 or “winner is not defined” The one change: a rule linked to Trial A formula is called a winner only when first choice is above 60. After the edit Rule on Trial says winner means above 60 60 OB-10544 (ST-13) OB-10351 OB-10257 OB-10468 48OB-101 53OB-106 61 (ST-14)OB-105 Expected answer OB-104, OB-105 40%50%60%70% First choice: share of testers who picked the blotter first In the expected answer Not in the answer Seven trials, six formulas. OB-105 was tested twice. Which formulas are winners, before and after one rule Seven trials sorted by first choice: OB-104 68, OB-105 61, OB-102 57, OB-106 53, OB-103 51, OB-101 48, OB-105 44. A line at 60 marks the rule. A line at 50 marks the Trial description. Before the edit, the five trials above 50 are in the expected answer. After the edit, only OB-104 and OB-105 are. Which formulas are winners? Seven trials, sorted by first choice Trial First choice Before After OB-104ST-1268% OB-105ST-1461% OB-102ST-1157% OB-106ST-1553% OB-103ST-1251% OB-101ST-1148% OB-105ST-1344% 60: the rule 50: the Trial description The one change: a rule on Trial A formula is called a winner only when first choice is above 60. Before:OB-102, OB-103, OB-104, OB-105, OB-106, or not defined After:OB-104, OB-105 In the answer Not in the answer
Figure 3. The same question before and after one rule. Filled dots are trials in the expected answer. The tables and the agent instructions did not change. Values come from the session's answer sheet.

The rule text on the deck read: “A formula is called a winner only when first choice is above 60.” Nothing else changed between the two questions. The tables and the agent instructions stayed the same.

Three details that decide whether the edit works

  1. E1. Remove the word everywhere else first. Before the session, winner was taken out of the agent instructions and the topic rules. With the rule in two places, the first answer is already two formulas, and the edit shows nothing.
  2. E2. Put the rule where Learn puts it. In the new experience, rules live on their own page: Explorer, Overview, Rules. Link the rule to the Trial entity type and the first_choice_pct property. The session script expected a rules panel on the entity type, so check the editor you have.
  3. E3. Refresh before you ask again. Learn states that a data agent retrieves ontology context every 10 minutes. Refresh the ontology context in the agent after you save, or the old answer can return.

One gap remains open on Learn. The data agent page lists what the agent receives from an ontology: entities, properties, relationships, definitions, synonyms, mappings, and bindings. It does not name rules. Learn's rules page says that consumers such as AI agents can use rules, and the overview says support varies by agent. Before you depend on a rule, download the ontology context from the agent and check that the rule is in it TBC.

The script had a fallback for this beat. If the preview would not attach the ontology to the agent, the same sentence went into the agent instructions, with a plain statement to the room. On stage, the first version ran: the ontology was attached to the agent, and the answer changed after the edit. Both versions give the same expected answer. Only the first one moves the meaning out of a prompt.

Sixty, twice

The same 60 drives the first half of the session. There, an Activator rule watches the live trial in the Eventhouse. It fires when the running first-choice share becomes greater than 60. Part 2 follows that event from the booth to the alert. Learn states that the new ontology experience has no direct integration with Activator. So in this build, 60 is written in two places. Dr. Kot's position: give both places one owner, and change both in the same change request.

Generate an ontology from a semantic model

At FabCon Europe 2026, Microsoft announced agentic ontology creation: an ontology drafted from semantic models, OneLake data, and context documents. On Learn today, that is two preview features Preview. Generate Ontology builds an ontology from a Power BI semantic model. The ontology agent drafts definitions and bindings in a chat, from lakehouses, eventhouses, and semantic models.

Generation from a semantic model creates entity types from tables, properties and bindings from columns, relationship types from model relationships, and metrics from DAX measures. Some work stays manual. You bind time series data and relationship types, and you review entity type keys, especially for multi-key scenarios. You need Read and Build permissions on each semantic model.

The ontology agent has two modes. Plan mode drafts, validates, and previews. Act mode writes the definition. You can attach up to 10 files of up to 5 MB each, such as a data dictionary. The agent follows Copilot regional processing. Outside the US and the EU Data Boundary, it stays off until an admin allows cross-region processing.

One known issue matters if you want both features. Learn states that a data agent does not work with an ontology that uses semantic models for binding. If you plan to generate from a semantic model and then attach a data agent, test that path first. The demo ontology was bound to lakehouse tables, so this issue did not apply to it.

Tenant settings a Fabric IQ ontology needs

An ontology needs two tenant settings: Users can create Fabric items, and Users can create ontology (preview) items. A data agent on top needs its own settings. The first is Users can use Copilot and other features powered by Azure OpenAI. The second is Capacities can be designated as Fabric Copilot capacities.

Two more settings apply when the capacity sits outside the EU Data Boundary and the US. They allow data sent to Azure OpenAI to be processed and stored outside the capacity's region. Admins find all of them under OneLake catalog, Govern, Configurations, Tenant settings. Learn notes that tenant settings can take up to one hour to take effect. Set them the day before a demo.

For the session, the dedicated workshop tenant had Copilot, data agents, and ontology enabled before the build started. The demo ran on an F32 capacity, a paid F SKU as the data agent requires.

When an ontology is worth the work

This section is Dr. Kot's position, not Microsoft guidance.

An ontology pays off when a definition has more than one reader. It costs work when the data is messy. The demo shows both: one rule changed an answer, and one bridge table cost an entity.

An ontology helps when

  • Several tools must agree on one word. Two agents, a report, and a dashboard all need the same meaning of winner, active customer, or late shipment.
  • The definition changes. The business moves the threshold for winner. One edit reaches every consumer, and version history keeps the old state.
  • The owner sits in the business. A rule written as a sentence can be read and reviewed by the person who owns the word.
  • The path between things matters. A trial leads to a study, and the study leads to a report. Relationships make that path explicit.

An ontology adds work when

  • One table serves one team and one report. A good column description and one agent instruction cost less.
  • The keys are messy. If bridge tables have no single key column, fix the data first. The demo lost an entity to this.
  • The deadline is fixed. The ontology, its rules, and the agent link are all preview. Keep them off the critical path, as Part 5 explains.
  • Nobody owns the rule. An unowned rule goes stale, and the agent repeats it with confidence.

The session kit, with the ontology sheet, is public on GitHub. Daily Fabric lessons are in the Fabric Falcons community. To review an ontology design with Dr. Kot, book a slot. For the wider platform, see the Microsoft Fabric implementation guide.

Key facts at a glance

Product facts from Microsoft Learn, checked on November 3, 2026. Demo facts from the session record.

IDFactSource
K1The ontology item in Fabric IQ is in preview, and its old experience retires on January 31, 2027.What is ontology (preview)?
K2The Fabric data agent is generally available and needs a paid F2 or higher capacity, or Power BI Premium P1 or higher.Fabric data agent concepts
K3One data agent takes up to five sources, and an ontology is one of the supported source types.Fabric data agent concepts
K4A data agent retrieves the latest ontology context every 10 minutes unless you refresh it by hand.Use Ontology as context in Fabric data agent
K5In the definition format, the entity type key is a single property, and a comma-separated list is rejected.Ontology definition (TMDL, new experience)
K6An entity type key must be a string or an integer property.Create entity types in ontology
K7A business rule is natural language, and the ontology does not run it against data or execute actions.Create and manage business rules
K8An ontology needs the tenant settings Users can create Fabric items and Users can create ontology (preview) items.Required tenant settings for ontology
K9The ontology agent accepts up to 10 attached files of up to 5 MB each per conversation.Use the ontology agent
K10A data agent does not work with an ontology that uses semantic models for binding, as a current known issue.Create a data agent grounded in an ontology
K11The demo ontology had six entity types, four relationships, and seven tables in its definition, with no Inclusion entity.Session build record, October 14, 2026
K12The expected answer to “Which formulas are winners?” went from five formulas or “not defined” to OB-104 and OB-105 after one rule.Session script and answer sheet

Frequently asked questions

What is an ontology in Microsoft Fabric?

An ontology is a Fabric IQ item that defines the business concepts of a domain as entity types, with properties, relationships, data bindings, and rules written in natural language. It binds those definitions to data in Fabric without copying it, so people, applications, and AI agents use one vocabulary. The ontology item is in preview.

Is the Fabric IQ ontology generally available?

No. As of November 3, 2026, Microsoft Learn marks the ontology item, business rules, generation from semantic models, the ontology agent, and the ontology as a data agent source as preview. The Fabric data agent itself is generally available. The old ontology experience retires on January 31, 2027.

What is the difference between a semantic model and an ontology in Fabric?

A Power BI semantic model is a curated analytics layer with measures, hierarchies, and dimensions for reports. An ontology defines business concepts, relationships, and rules across sources such as lakehouses, eventhouses, warehouses, and semantic models. You can generate an ontology from a semantic model, and its DAX measures become metrics in the ontology.

Does a Fabric data agent need an ontology?

No. A data agent can answer from lakehouses, warehouses, KQL databases, semantic models, and Microsoft Graph without an ontology. An ontology adds shared definitions, so a business word such as winner means the same thing in every agent that uses it. Without one, definitions go into agent instructions, and each agent keeps its own copy.

Can an entity type in a Fabric ontology have a composite key?

Plan for one key column. Microsoft Learn's definition reference says the entity type key is a single property, and a comma-separated list is rejected. One Learn tutorial shows a two-column key picked in the editor. In Dr. Kot's demo, a two-column key failed through the API. Add a single key column, use a keyless entity type, or model the bridge table as a relationship.

Which tenant settings does a Fabric ontology need?

Two settings are required: Users can create Fabric items, and Users can create ontology (preview) items. A data agent that uses the ontology also needs the Copilot and Azure OpenAI settings. Capacities outside the EU Data Boundary and the US also need the cross-region processing and storage settings. Changes can take up to one hour.

Why does a data agent still give the old answer after an ontology edit?

Microsoft Learn states that a data agent retrieves the latest ontology context every 10 minutes. Refresh the ontology context in the data agent, then ask again. If the answer still does not change, download the ontology context and check that your change, for example a business rule, is in it.

Can you generate a Fabric ontology from a Power BI semantic model?

Yes, in preview. Select Generate Ontology on the semantic model. Fabric creates entity types from tables, properties from columns, relationships from model relationships, and metrics from DAX measures. You need Read and Build permissions. Review the keys, and bind time series and relationships yourself. A data agent does not yet work with an ontology bound to semantic models.

About the author

Dr. Estera Kot is CTO at Clouds on Mars, a Microsoft and Databricks partner for data and AI in Europe and the Middle East. At Microsoft she was Principal Product Manager for the Apache Spark runtime in Azure Synapse Analytics and Microsoft Fabric, and she created the Native Execution Engine. She is a Microsoft MVP and holds a Ph.D. in Computer Science from the Warsaw University of Technology. She presented this series as the community session "From Events to Answers" at Microsoft Qatar HQ in Lusail, Doha, on October 14, 2026.

Sources

Microsoft Learn, checked on November 3, 2026.