Fabric IQ Ontology gives an Operations Agent a business-level source made of entity types, properties, relationships, and bound data instead of requiring every monitoring instruction to reference raw tables. The generated playbook should use the expected ontology concepts and rules, and Teams recommendations can carry ontology entity context into an approved action.
The abstraction does not remove source risk. Missing keys, stale graph data, incorrect property types, broken bindings, unclear names, wrong relationship direction, and insufficient permissions can all produce plausible rules over incomplete or outdated evidence. Validate the ontology as an executable production dependency before trusting the agent's recommendation.
Can an operator trace every generated rule back to the intended ontology entity, property, relationship, source row, and refresh time? If not, fix semantic evidence before activating monitoring.
Qualify the ontology knowledge source before agent setup
Confirm required Fabric, Graph, Operations Agent, Copilot, Azure OpenAI, and cross-geo tenant settings; supported capacity and region; Teams availability; workspace role; source-data access; ontology preview acceptance; and the exact ontology item. Verify that the ontology can display current entity instances and relationships before adding it to the agent.
Use ontology monitoring when business rules depend on stable concepts and relationships shared across sources. A direct Eventhouse/KQL source can be simpler when one flat table already expresses the monitored object, field, time, and threshold. Do not add a semantic layer unless it removes real ambiguity or cross-domain joins.
Define the entity, binding, freshness, and action contract
| Control | Required evidence | Failure risk | Release decision |
|---|---|---|---|
| Entity type and key | Business definition, unique key, source lineage, lifecycle, grain, duplicates, nulls, and owner. | State fragments across duplicate entities or attaches to the wrong real-world object. | One stable identity per monitored object with tested key quality. |
| Property | Name, description, source column, type, unit, valid range, null behavior, precision, and semantic owner. | A threshold evaluates a missing, incompatible, incorrectly scaled, or ambiguous value. | Use supported types and reconcile ontology values with source records. |
| Relationship | Direction, source and target keys, cardinality, validity, provenance, and required traversal. | The agent associates a condition or action with the wrong store, asset, product, route, or owner. | Replay expected and forbidden paths using known entities. |
| Data binding | Supported OneLake source, table, mapped columns, keys, source mode, accessibility, and schema contract. | The ontology exists but has no current instances, misses entities, or silently returns null properties. | Validate bindings, source permissions, supported modes, and record-level samples. |
| Graph freshness | Refresh method, schedule, last success, source watermark, lag objective, capacity impact, and failure owner. | The Operations Agent monitors a valid semantic model with stale operational facts. | Block or disclose recommendations when freshness exceeds the approved limit. |
| Playbook rule | Expected entity type, property, relationship, threshold, condition, generated query, and source evidence. | The LLM maps a clear goal to a plausible but unintended concept or rule. | Review each concept and rule, then replay deterministic ground truth. |
| Action parameters | Ontology-to-action mapping, identifier, editable values, validation, approver, authority, postcondition, and rollback. | A correct recommendation sends the wrong entity ID or business context downstream. | Prove parameter lineage and least-privilege execution end to end. |
Microsoft notes that ontology upstream updates need refresh before becoming visible in the item and graph. Treat the source watermark and ontology refresh watermark as part of every monitored condition. A technically correct rule over stale entity state is still an operational failure.
Test ontology evidence, generated rules, and recommendations
| Test | Method | Pass condition | Remediation |
|---|---|---|---|
| Entity coverage | Compare expected source objects with ontology instances across active, inactive, missing, duplicate, and recently created records. | All in-scope entities exist once with correct keys and provenance. | Key, binding, source-mode, refresh, or entity-definition fix. |
| Property accuracy | Reconcile threshold fields, units, types, nulls, decimals, dates, and boundary values against source records. | Ontology properties preserve the values required by every rule. | Supported type, mapping, unit normalization, description, or alternate source. |
| Relationship accuracy | Traverse known and forbidden entity paths and verify direction, cardinality, effective time, and ownership. | Each rule and action resolves the intended related entity only. | Relationship keys, direction, binding, cardinality, or model redesign. |
| Freshness and outage | Delay or fail source and graph refresh, update a source record, and observe ontology and agent behavior. | Lag is measured; stale or missing evidence cannot produce an undisclosed current-state recommendation. | Refresh monitoring, heartbeat rule, stop policy, fallback, or explicit warning. |
| Playbook concept mapping | Generate the playbook and inspect summary, glossary, entities, properties, relationships, rules, queries, and bindings. | Every generated concept and rule matches the approved semantic contract. | Rename or document ontology terms, refine instructions, separate rules, or block activation. |
| Known positive and negative | Replay incidents, normal periods, thresholds, transitions, recovery, excluded entities, and missing data. | Required cases trigger and noncases remain quiet within the approved objective. | Ontology, query, rule, threshold, time, state, or suppression correction. |
| Permissions | Test creator, recipient, Viewer, Contributor, source-reader, revoked, and offboarded identities. | Queries and actions use intended authority; access loss is visible and contains impact. | Workspace or source role, identity ownership, recipient, or rollout correction. |
| Action parameter lineage | Trace ontology entity context into Teams values, editable parameters, approved action, downstream record, and postcondition. | The exact intended entity and validated values are acted on once and can be recovered. | Parameter schema, mapping, approval, idempotency, containment, or action removal. |
| Capacity and scale | Refresh representative graph volume while active rules run; observe Graph, agent, source-query, reasoning, Teams, and action load. | Freshness and response objectives hold without unacceptable capacity or message impact. | Refresh schedule, scope, rule set, source choice, capacity, or staged rollout. |
Run shadow mode beside the existing operational control. Measure entity and property coverage, graph lag, rule recall, false positives, duplicate operations, event-to-recommendation latency, relationship errors, action-parameter defects, recommendation acceptance, capacity, and operator utility. Keep ontology quality, rule quality, recommendation quality, and action safety as separate gates.
Govern ontology and agent changes as one release
Version entity types, properties, keys, relationships, descriptions, bindings, source schemas, refresh configuration, business goals, instructions, generated playbook, actions, recipients, and agent state. A source or ontology change can alter monitoring behavior without changing the agent instruction; a playbook regeneration can change rules without changing the ontology.
Alert on failed or delayed graph refresh, source-watermark lag, missing entities, property null spikes, broken relationships, permission failures, unexpected playbook changes, inactive agent state, query errors, rule-volume shifts, action failures, and capacity pressure. Assign one owner to reconcile source, ontology, playbook, and live operation evidence during an incident.
Microsoft documents preview limitations including unsupported combinations of semantic-model modes and bindings, OneLake security constraints for some lakehouse bindings, unsupported Graph behavior for Decimal properties, and required Contributor plus source-read access in parts of the ontology experience. Validate the current tenant and documentation; do not generalize from a demo workspace.
Run a two-to-four-week ontology monitoring assessment
- Select one operational process, ontology domain, Operations Agent, bounded rule set, accountable semantic and process owners, representative history, and response objective.
- Confirm tenant settings, capacity, region, workspace roles, Teams, source access, ontology and Operations Agent support state, and production preview acceptance.
- Inventory entity types, keys, properties, types, units, relationships, bindings, source schemas, refresh, permissions, goals, instructions, actions, and current controls.
- Remediate missing or ambiguous semantics, validate entity and relationship instances, establish freshness monitoring, and build a labeled evaluation set.
- Add the ontology knowledge source, generate the playbook, inspect every concept and rule, and reconcile generated queries with source evidence.
- Replay positive, negative, boundary, transition, stale, missing, permission, relationship, and action-parameter cases; fix defects and rerun regression.
- Operate in shadow mode, measure quality, freshness, alert burden, user value, capacity, and failures, then exercise stop and rollback.
- Deliver the semantic contract, lineage and freshness model, verified playbook, evaluation suite, scorecard, monitoring, runbook, preview risks, and go, limited pilot, direct-source, or stop recommendation.
Frequently asked questions
Can Microsoft Fabric Operations Agent use a Fabric IQ Ontology?
Yes. Microsoft documents a preview integration in which an Operations Agent uses a Fabric IQ Ontology item as its knowledge source, generates a playbook grounded in ontology entity types and properties, monitors matching conditions, and recommends actions through Teams.
Why is my Operations Agent ontology knowledge source not working?
Common causes include missing tenant settings, insufficient workspace or bound-source permissions, missing entity keys or data bindings, unsupported source modes or table features, stale graph refresh, unclear entity and property names, unsupported property types, or a generated playbook that maps the business instruction to the wrong ontology concept.
Does Fabric IQ Ontology update automatically when source data changes?
Not necessarily. Microsoft currently notes that upstream updates must be refreshed before they are visible in the ontology item and its underlying graph. Production monitoring must define refresh ownership, cadence, lag, failure detection, and what the Operations Agent should do when ontology freshness is outside its objective.
What should be tested before starting an ontology-connected Operations Agent?
Test entity keys, properties, units, relationships, validity and time semantics, data bindings, graph freshness, source permissions, known incidents, quiet periods, generated playbook concepts and rules, action parameters, Teams approval, false positives, missed conditions, capacity, audit, and rollback.
How long does an Operations Agent ontology assessment take?
A focused assessment commonly takes two to four weeks for one ontology domain, Operations Agent, bounded rule set, representative history, and accountable owners. More time is required when entity definitions, keys, relationships, bindings, refresh, source permissions, or action contracts must be remediated first.
Official implementation references
- Create an Operations Agent connected to Fabric IQ Ontology
- Fabric IQ Ontology concepts, bindings, graph, refresh, and querying
- Fabric IQ Ontology creation, binding, access, Graph, and source troubleshooting
- Microsoft Fabric Operations Agent setup and playbook generation
- Operations Agent Teams recommendations and actions
Start with one ontology domain and one measurable operational condition. Datrick can validate semantic readiness, implement the agent, reconcile every generated rule, test live bindings and freshness, and establish a defensible rollout decision.