Why Aren’t Semantic Models Alone Enough for AI?

Semantic models give AI a trusted way to understand measures, dimensions, relationships, and business terminology. They can tell an AI system what Net Revenue means, how Customer relates to Order, and which calculation should be used when someone asks about quarterly performance.

But that is only part of what enterprise AI needs.

An AI assistant may need to answer a reporting question, connect information across business domains, interpret a policy, understand what is happening right now, or recommend an action. A Power BI semantic model is extremely useful for governed analytics, but it does not automatically provide all of that context on its own.

To make enterprise data genuinely useful to Copilot and AI agents, organizations need to build beyond the model. That means preparing semantic models specifically for AI, connecting them to trusted data, adding cross-domain business context, enforcing permissions, and continuously testing the answers and actions those systems produce.

Quick Answer

Semantic models alone are not enough for every AI use case because they are primarily designed to organize analytical data for reporting.

A Power BI semantic model can provide trusted measures, relationships, hierarchies, security, and business-friendly terminology. With Microsoft’s Prep data for AI capabilities, it can also guide Copilot and Fabric data agents through AI data schemas, verified answers, and AI instructions.

However, more advanced AI scenarios may also require:

• Governed, high-quality data in OneLake

• Context spanning several systems or business domains

• A shared definition of business entities and their relationships

• Current operational or real-time information

• Policies, documents, emails, and other unstructured knowledge

• An agent that can select the correct data source and query method

• Permissions and governance that follow the user

• Testing, evaluation, and human oversight

• Clearly defined rules and actions for agent-based workflows

In Microsoft Fabric, semantic models can work alongside Fabric data agents and Fabric IQ ontologies. The semantic model remains the trusted analytical layer, while the ontology can add cross-domain entities, relationships, rules, and operational context. The correct architecture depends on what the AI system is expected to understand and do. Learn more in Microsoft’s Fabric IQ overview.

In This Blog

• What Do Semantic Models Give AI?

• Why Isn’t a Well-Designed Semantic Model Automatically AI-Ready?

• Where Do Semantic Models Start to Fall Short?

• How Does Prep for AI Improve a Semantic Model?

• What Is the Difference Between a Semantic Model and an Ontology?

• When Is a Semantic Model Enough for an AI Use Case?

• When Does AI Need More Than a Semantic Model?

• How Do Fabric Data Agents Fit into the Architecture?

• How Does Fabric IQ Add Business Context?

• What Other Context Might an Enterprise Agent Need?

• What Does an AI-Ready Data Architecture Look Like?

• How Should Organizations Prepare Their Semantic Layer for AI?

• Which Mistakes Should Organizations Avoid?

• Build Beyond the Model

• Frequently Asked Questions

What Do Semantic Models Give AI?

A Power BI semantic model creates a curated analytical layer over business data.

It can organize data into facts and dimensions, define relationships, provide reusable DAX measures, establish hierarchies, and present technical data through business-friendly names. In Microsoft Fabric, semantic models can be built over Warehouses, Lakehouses, SQL analytics endpoints, mirrored data, and other supported sources.

For reporting, that layer is essential.

Without it, every report author may interpret the source data differently. One person might define revenue before returns, while another uses revenue after returns. A third person might exclude a particular business unit without documenting the decision.

The semantic model gives those teams one reviewed place to define:

• Revenue

• Gross margin

• Active customer

• On-time delivery

• Fiscal year

• Product hierarchy

• Territory

• Budget variance

• Customer retention

• Reporting security

That same structure is useful to AI.

When a Fabric data agent queries a semantic model, it can use a DAX-generation tool to interpret the model’s schema, metadata, measures, synonyms, and other available context. It then generates and executes a DAX query rather than asking the language model to calculate an answer from raw text. Microsoft explains these preparation practices in its semantic model best practices for Fabric data agents.

Semantic models reduce analytical ambiguity

Consider a user asking:

What were sales last quarter?

A source database might contain Gross Sales, Net Sales, Sales Before Returns, and Sales After Discounts.

A governed semantic model can identify the approved metric, connect it to the correct calendar, and apply the appropriate filters. That is much safer than giving an AI system several similar columns and hoping it chooses correctly.

Still, even a technically strong model may leave room for ambiguity. Microsoft’s guidance uses a similar sales example to explain why AI data schemas should focus the model on the measures that the AI is expected to use.

Why Isn’t a Well-Designed Semantic Model Automatically AI-Ready?

A semantic model may be perfectly usable for an experienced report developer while still being confusing to an AI system.

A human analyst may already know that:

• “Sales” means Net Sales internally

• “Territory” refers to a sales region, not a product grouping

• The fiscal year begins in July

• Cancelled orders should be excluded

• Delivery performance uses the shipment date

• A “high-risk account” follows a company-specific threshold

An AI system does not automatically know those rules.

It interprets the metadata, names, measures, relationships, instructions, and examples the organization provides. If the model contains vague labels, overlapping measures, undocumented calculations, or several possible date fields, the AI may generate a valid query that answers the wrong interpretation of the question.

Microsoft recommends preparing semantic models specifically for AI rather than assuming that a model created for conventional reporting will automatically produce the best Copilot or data-agent answers.

AI behavior is not fully deterministic

Even with preparation, a generative AI system does not guarantee the exact same response every time.

Microsoft notes that Prep data for AI can improve grounding, relevance, and accuracy, but it cannot ensure a specific output for every prompt. Consequently, organizations still need testing, diagnostics, evaluation, and ongoing validation.

That changes the operating model.

A report calculation can be tested against a known result and then reused consistently. An AI experience adds another interpretive layer between the user and the analytical model. Teams must test not only whether the underlying measure is correct, but also whether the AI consistently selects and explains it correctly.

Where Do Semantic Models Start to Fall Short?

Semantic models are optimized for analytical questions. Enterprise AI may need to answer a much broader set of questions.

The limits become clearer when an AI system needs context beyond measures, dimensions, and reporting relationships.

A semantic model does not automatically unify the entire business

A semantic model usually represents a defined analytical domain, such as sales, finance, inventory, or customer support.

An enterprise AI agent may need to reason across several of those domains at once.

For example:

Which late customer orders are connected to suppliers with unresolved quality issues, and which account managers should be notified?

Answering that question may require:

• Order data

• Shipment status

• Supplier quality records

• Customer ownership

• Product relationships

• Current exceptions

• Business rules

• Contact or workflow context

Those concepts may live in separate semantic models, Lakehouses, Eventhouses, operational systems, and Microsoft 365 data.

A semantic model can participate in that architecture, but a single model does not automatically reconcile all of those entities and relationships across the enterprise.

A semantic model describes analytics, not necessarily operations

Semantic models are designed to provide curated measures, hierarchies, dimensions, and relationships for analytical consumption.

An operational AI agent may also need to understand:

• What state an order is currently in

• Which actions are permitted

• What should happen when a threshold is exceeded

• Which dependencies are affected

• Who owns the next step

• Which process rule applies

• Whether an action requires approval

Microsoft positions Fabric IQ ontologies as a complementary layer that can define business entities, properties, relationships, rules, and actions. That is a broader form of context than the reporting-focused structure of a semantic model. See Microsoft’s Fabric IQ overview.

A semantic model does not contain every kind of knowledge

Some enterprise questions depend on information that does not belong in a reporting model.

Examples include:

• Policy documents

• Contracts

• Procedure manuals

• Project files

• Meeting notes

• Emails and chats

• Public web information

• Product documentation

• Regulatory guidance

Microsoft’s current IQ architecture separates these context types across interconnected capabilities. Fabric IQ focuses on business data and entities, Foundry IQ provides curated institutional knowledge, Work IQ provides context about people and collaboration, and Web IQ contributes current external information. Learn more in the Microsoft IQ documentation.

Not every agent needs all four. However, this model reflects an important point: a semantic model is one source of enterprise meaning, not the entire knowledge environment.

How Does Prep for AI Improve a Semantic Model?

Before adding another technology layer, organizations should make the semantic model itself as useful to AI as possible.

Microsoft’s Prep data for AI capabilities currently focus on three areas:

• AI data schemas

• Verified answers

• AI instructions

These settings are saved on the semantic model and can improve the way both Power BI Copilot and Fabric data agents interpret it.

AI data schemas reduce noise

An AI data schema identifies the tables, columns, and measures that the AI should prioritize.

This is useful because a large enterprise model may contain hundreds of objects, including technical fields, helper measures, obsolete columns, and several metrics with similar names.

A focused AI data schema reduces the number of possible interpretations.

For example, if the company uses Net Sales as the official sales metric, the AI-facing schema may include Net Sales while excluding older or narrower sales calculations that users are not expected to ask about.

Microsoft recommends choosing only the objects relevant to the intended question set because a smaller, focused schema can reduce ambiguity, improve accuracy, and shorten response time.

Verified answers anchor common questions

Verified answers connect approved report logic to common or complex questions.

They can guide the AI toward the intended fields, measures, filters, and query structure when users phrase a question in different ways.

For example, a verified answer could connect these questions to the same approved logic:

• How are we performing by territory?

• Show sales by region.

• Which territories are above quota?

• Break down revenue by sales region.

Microsoft stores verified answers at the semantic-model level, which allows them to influence multiple experiences using the same model.

AI instructions provide business guidance

AI instructions allow model authors to explain terminology, business logic, and analytical preferences that may not be obvious from the schema.

Examples include:

• Use Contribution Margin when users ask about profitability.

• Fiscal year starts on July 1.

• Exclude cancelled orders from fulfillment metrics.

• Use shipment date for delivery-performance questions.

• “Enterprise customer” means an account with annual revenue above the approved threshold.

These instructions can significantly improve interpretation. However, Microsoft describes them as unstructured guidance and notes that the model is not guaranteed to follow every instruction exactly. They support the model but do not replace clear structure, explicit measures, and testing.

What Is the Difference Between a Semantic Model and an Ontology?

A semantic model and an ontology both add meaning to data, but they serve different purposes.

Microsoft describes semantic models as curated analytical models optimized for measures, hierarchies, relationships, trusted KPIs, and interactive reporting. By contrast, an ontology defines a machine-understandable business vocabulary using entities, properties, relationships, constraints, data bindings, and a graph-oriented representation. See Microsoft’s ontology overview.

The ontology does not replace the semantic model

The emergence of ontology does not make semantic models obsolete.

Microsoft explicitly positions the two as complementary. Organizations can generate or align an ontology from semantic models already in production, helping preserve approved terminology and KPIs across reports, agents, and applications.

The semantic model can remain the trusted source for questions such as:

• What was gross margin last quarter?

• Which region missed its target?

• How did revenue compare with budget?

• What is the year-over-year retention rate?

The ontology can provide broader context for questions such as:

• Which delayed shipments affect strategic customers?

• Which plants depend on the same at-risk supplier?

• Which service incidents are connected to a specific product family?

• What action is permitted when an asset reaches a critical condition?

The architecture becomes stronger when each layer handles the job it was designed to do.

When Is a Semantic Model Enough for an AI Use Case?

A well-prepared semantic model may be enough when the use case is focused on analytical Q&A within a clearly defined domain.

Examples include:

• Answering sales-performance questions

• Comparing actuals with budget

• Summarizing customer-service metrics

• Explaining inventory trends

• Analyzing Power BI report visuals

• Generating DAX-based insights

• Creating report pages from governed data

• Supporting departmental self-service analytics

In those scenarios, the semantic model already contains much of the required logic.

The organization may not need an ontology or a broader intelligence architecture when:

• The questions stay within one analytical domain

• Approved measures already exist

• Relationships are clear

• Users need insights rather than operational actions

• The relevant data is available in the model

• The model has been properly prepared and tested for AI

• Security is correctly applied

Microsoft’s Fabric data agent can query semantic models using natural-language-to-DAX tooling, while Power BI Copilot can use prepared models to answer questions and analyze report content.

The key phrase is well prepared.

Connecting a large, undocumented semantic model to an AI experience is not the same as creating a reliable analytical agent.

When Does AI Need More Than a Semantic Model?

The need for additional context usually appears when the AI must reason beyond a single reporting model.

The question crosses business domains

A semantic model may explain sales performance, while another explains supply-chain performance.

An ontology or orchestrated multi-source agent may be needed when the user expects the AI to understand that a Customer placed an Order, the Order contains a Product, the Product depends on a Supplier, and the Supplier is connected to a current quality incident.

The agent needs live operational context

A monthly or daily analytical model may not contain the current state needed for operational decisions.

AI use cases involving live equipment signals, order events, network telemetry, or rapidly changing conditions may need Eventhouse data, Real-Time Intelligence, or other operational sources in addition to the semantic model.

Microsoft positions operations agents and ontology-grounded context as tools for monitoring real-time data, detecting anomalies, and recommending or triggering governed responses.

The agent needs policies or documentation

A model can calculate the customer’s refund amount. It may not explain whether the company’s policy allows the refund, which exceptions apply, or whether a manager must approve it.

That information may need to come from authoritative documents, a knowledge base, or another managed knowledge source.

The agent needs to act

Answering a question and performing an action are different security and architecture problems.

An agent that only reports an inventory shortage may rely on a semantic model. An agent that creates a purchase request, contacts a supplier, or adjusts a replenishment workflow also needs defined permissions, available actions, validation, approval logic, and monitoring.

A measure does not tell the agent whether it is authorized to act.

How Do Fabric Data Agents Fit into the Architecture?

A Fabric data agent provides a conversational layer over supported Fabric data sources.

A data agent can evaluate a question, determine which configured data source is relevant, and invoke a specialized query tool. Depending on the source, it may generate SQL, DAX, KQL, or an ontology-based query.

Supported source types include:

• Power BI semantic models

• Lakehouses

• Warehouses

• Eventhouse and KQL databases

• Fabric IQ ontologies

• Other supported Fabric sources

This orchestration matters because not every question should be forced through the same model.

A finance question may belong in a Power BI semantic model. A detailed operational query may belong in a Warehouse. A live event question may require KQL. A cross-domain relationship question may be better suited to an ontology.

The agent does not fix the underlying data

A data agent can route and generate queries, but it still depends on the quality of its sources.

Microsoft recommends optimizing semantic models, defining AI data schemas, creating verified answers, adding targeted AI instructions, reviewing generated DAX, and continuously validating responses.

The agent layer should not become an excuse to postpone:

• Data-quality work

• Metric governance

• Clear naming

• Permission design

• Source ownership

• Performance optimization

• Documentation

AI magnifies the value of a good data foundation. It does not remove the need for one.

How Does Fabric IQ Add Business Context?

Fabric IQ is Microsoft’s emerging Fabric workload for connecting unified data, business intelligence, and operational intelligence.

Microsoft describes Fabric IQ as a way to organize OneLake data using the language of the business so people, applications, and agents can interpret information through shared concepts rather than isolated table names.

Its core layers include:

• Unified data through OneLake

• Business intelligence through Power BI semantic models

• Operational intelligence through ontologies

• Data agents for conversational access

• Graph capabilities for relationship-heavy analysis

• Operations agents for monitoring and governed action

Fabric IQ builds from existing semantic work

Organizations do not necessarily need to start over.

Microsoft supports generating an ontology from an existing semantic model. That provides a path for reusing trusted names, measures, and business definitions while extending them into a broader entity-and-relationship model.

For example, a sales semantic model may already include:

• Customer

• Product

• Order

• Revenue

• Sales territory

An ontology can elevate those concepts beyond one model and connect them to:

• Shipment

• Supplier

• Service case

• Manufacturing asset

• Contract

• Business rule

• Operational event

That broader context is useful when an AI system needs to reason across business processes rather than summarize one analytical dataset.

Preview status matters

Fabric IQ ontology capabilities are currently in preview.

Microsoft notes that preview features may have constrained functionality and should be evaluated carefully against production, security, reliability, compliance, and geographic requirements. Organizations should review current documentation because availability and limitations may change as the product evolves.

What Other Context Might an Enterprise Agent Need?

A semantic model and ontology can provide substantial business-data context. However, some agents also need to understand people, documents, and external information.

Microsoft’s broader Microsoft IQ architecture currently describes four interconnected areas:

Microsoft does not require every organization to use every layer. Instead, the framework illustrates the different types of context an enterprise agent may require.

Consider an agent responding to a delayed customer order.

It may need:

• The order value from a semantic model

• The current shipment state from operational data

• The relationship between order, customer, supplier, and product from an ontology

• The service-level agreement from an authoritative document

• The responsible account manager from organizational context

• Current weather or transportation information from the web

• Approval before offering compensation

No single semantic model is likely to contain all of that context, nor should it.

What Does an AI-Ready Data Architecture Look Like?

An AI-ready architecture is layered. Each layer contributes a different kind of trust or context.

Microsoft’s AI-readiness training for the Fabric semantic layer brings these concepts together by covering gold-layer design, semantic-model preparation, enterprise ontology, and iterative validation.

Not every use case needs every layer

A departmental reporting assistant may need only:

• A trusted semantic model

• Prep data for AI

• Correct permissions

• Testing

A cross-functional operations agent may require:

• Several data sources

• A shared ontology

• Real-time events

• Policies

• Agent orchestration

• Action controls

• Human approval

The architecture should match the actual question and risk, not the longest possible list of Microsoft services.

How Should Organizations Prepare Their Semantic Layer for AI?

The safest approach is to build outward from trusted analytical foundations.

Phase 1: Fix the data foundation

Before tuning an AI prompt, confirm that the underlying data is accurate and governed.

Document:

• Data ownership

• Source-of-truth systems

• Refresh or latency expectations

• Data-quality rules

• Business definitions

• Security classifications

• Lineage

• Known limitations

AI cannot resolve conflicting source data through better wording alone.

Phase 2: Improve the semantic model

Review the model from both a human and AI perspective.

Focus on:

• Clear star-schema design

• Explicit measures

• Business-friendly names

• Useful descriptions

• Consistent date handling

• Fewer duplicate objects

• Appropriate security

• Efficient DAX

• Strong query performance

Microsoft notes that bloated models and inefficient calculations can reduce both agent accuracy and response performance.

Phase 3: Configure Prep data for AI

Define the intended question set first.

Then:

• Limit the AI data schema to relevant objects

• Create verified answers for common or ambiguous questions

• Add concise AI instructions for business terminology

• Test the model through Copilot

• Review how the answer was generated

• Inspect the generated DAX

• Refine the configuration

Microsoft recommends an iterative workflow rather than treating AI preparation as a one-time publishing step.

Phase 4: Determine whether broader context is required

Ask:

• Does the use case cross business domains?

• Does it depend on live operational state?

• Does the agent need to understand connected entities?

• Does it require policies or documents?

• Will the agent recommend or take action?

• Does the workflow require human approval?

• Are several query languages or sources involved?

Those answers determine whether the architecture also needs an ontology, data agent, Real-Time Intelligence, Foundry knowledge, or another contextual source.

Phase 5: Validate with real questions

Create a test set based on how employees actually speak.

Include:

• Common questions

• Ambiguous terminology

• Follow-up questions

• Questions the agent should refuse

• Questions outside the intended scope

• Similar metrics with different definitions

• Requests involving restricted data

• Edge cases and unusual filters

Compare results with approved ground truth. Do not rely on a successful product demo as evidence that the experience is ready for broad use.

Phase 6: Monitor and govern the experience

Once users begin asking questions, review:

• Incorrect answers

• Unanswered questions

• Misrouted sources

• Slow queries

• Permission failures

• Frequently requested metrics

• New terminology

• Changes to source models

• Questions that require escalation

The semantic layer and agent configuration should evolve as the business changes.

Which Mistakes Should Organizations Avoid?

Assuming good reporting automatically means good AI

A report developer may understand a complicated model because they know its history.

An AI system sees the metadata and configuration it is given. Undocumented tribal knowledge will not reliably carry into the agent experience.

Giving the AI the entire model

More data does not always produce better answers.

Large schemas with duplicate measures, technical fields, and overlapping terms can make source selection and query generation harder. Start with the smallest reliable schema that supports the intended questions.

Treating instructions as enforceable logic

AI instructions can guide interpretation, but they are not deterministic security or business-rule enforcement.

Critical calculations should remain in governed measures. Critical permissions should remain in the identity and data platforms. High-impact actions should be validated outside the language model.

Skipping verified answers

Some business questions are too important or too ambiguous to leave completely open-ended.

Verified answers can guide the system toward approved calculations and filters for recurring questions. They are especially useful when users employ terms differently across departments.

Building an ontology before defining the business concepts

An ontology is not valuable simply because it contains many entities.

Teams still need to agree on:

• What a customer is

• Which identifier is authoritative

• How orders and shipments relate

• Which properties matter

• Who owns the definition

• Which sources bind to the concept

• Which rules and actions are valid

Technology cannot settle unresolved business definitions by itself.

Adding an agent before establishing governance

An agent can make unclear ownership and inconsistent data more visible, but it cannot make those problems disappear.

Security, data classification, permissions, source ownership, and support processes should be established before the agent reaches a broad audience.

Treating preview capabilities as finished architecture

Fabric IQ and ontology capabilities are evolving.

Organizations should verify current regional availability, support, limitations, security behavior, licensing, and production guidance before making them a critical dependency. Microsoft also documents current Fabric IQ agent-tool considerations in Microsoft Foundry documentation.

Build Beyond the Model

Semantic models remain one of the most important parts of an AI-ready data strategy.

They turn technical data into governed business measures, relationships, hierarchies, and terminology. They give Power BI reports a consistent analytical foundation, and they give Copilot and Fabric data agents a safer way to answer data questions.

But enterprise AI often needs more than an analytical answer.

It may need to connect several business domains, understand the current state of an operation, interpret an authoritative document, follow the user’s permissions, or recommend the next approved action. Those requirements extend beyond what a semantic model was designed to represent by itself.

The right goal is not to replace semantic models. It is to build on them.

A trusted semantic model can become the analytical foundation. Prep data for AI can make that foundation clearer to Copilot and data agents. Fabric IQ ontology can add shared entities and cross-domain relationships. Other knowledge and operational sources can provide the context required for the specific use case.

Emergent Software helps organizations design Microsoft Fabric data platforms and semantic layers that support both trusted reporting and practical enterprise AI. By connecting governed data, reusable business definitions, AI-ready models, and the right contextual architecture, teams can move from impressive demonstrations to AI experiences people can actually trust.

Frequently Asked Questions

Why aren’t semantic models alone enough for AI?

Semantic models are primarily designed to provide trusted analytical measures, dimensions, relationships, and reporting logic. Some AI use cases also require cross-domain entities, real-time operational state, policies, documents, workflows, rules, and approved actions. Those needs may require additional data sources, a Fabric data agent, an ontology, or another knowledge layer.

Can Copilot use a Power BI semantic model?

Yes. Copilot in Power BI can use semantic models to answer questions about data, analyze report visuals, and support report creation. Microsoft recommends preparing the model with AI data schemas, verified answers, and AI instructions before broad use. See Microsoft’s Prep data for AI guidance.

Can a Fabric data agent query a semantic model?

Yes. Fabric data agents can use semantic models as data sources and generate DAX queries from natural-language questions. They can also query other supported sources using SQL, KQL, or ontology-based tooling. See Microsoft’s Fabric data agent overview.

What is Prep data for AI in Power BI?

Prep data for AI is a set of Power BI capabilities that helps model authors improve AI interpretation. It includes AI data schemas, verified answers, and AI instructions. These settings are stored on the semantic model and can influence Copilot and Fabric data-agent responses.

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

A semantic model organizes data for analytics using measures, dimensions, hierarchies, and relationships. A Fabric IQ ontology defines business entities, properties, relationships, constraints, rules, and data bindings across domains. They can work together, and Microsoft supports generating an ontology from an existing semantic model.

Does every AI use case need an ontology?

No. A well-prepared semantic model may be sufficient for focused analytical Q&A within one business domain. An ontology becomes more useful when the AI must reason across several domains, understand relationship-heavy business concepts, or support operational decisions and actions.

Does an ontology replace a Power BI semantic model?

No. Microsoft positions semantic models and ontologies as complementary. Semantic models remain optimized for trusted KPIs and interactive reporting, while ontologies provide cross-domain business context for agents, applications, and operational workflows.

Is Fabric IQ generally available?

Fabric IQ ontology and several related capabilities are currently in preview. Organizations should review Microsoft’s latest documentation, regional availability, limitations, licensing, and production guidance before adoption. See Microsoft’s Fabric IQ ontology overview.

How should an organization make a semantic model AI-ready?

Start with clear data and model design. Use explicit measures, business-friendly names, descriptions, consistent relationships, and good performance. Then configure an AI data schema, verified answers, and AI instructions. Finally, test real questions, review generated queries, compare answers with approved results, and continue refining the experience.

What should organizations build first: a semantic model or an ontology?

Start with the business problem and the trusted data foundation. For analytical reporting and KPI questions, a semantic model is usually the logical starting point. When the use case requires cross-domain entities, relationships, operational context, or governed actions, the organization can extend that foundation through an ontology and other Fabric IQ capabilities.