Fast Decisions Still Need Enterprise Context
By Connie Yang, Co-founder and CEO, Nth AI. Published 2026-09-21.
What experimenting with Jev is teaching us about building business AI on Azure and Fabric.
What experimenting with Jev is teaching us about building business AI on Azure and Fabric.
Consider a hypothetical business question: “Why is partner revenue down this quarter?”
The data is connected. The query executes. The system reports that partner revenue is lower than last quarter and begins explaining the decline.
But the current quarter is incomplete, one business unit is missing from its coverage, and the channel definition changed six weeks ago.
The calculation can be accurate for the rows selected while the conclusion is misleading. A query can execute successfully and still answer the wrong business question.
That distinction is central to our work on Nexus. As more decisions move into software, business meaning needs to travel with the data.
What Jev brings into focus
TypeSafe AI introduced Jev as a model designed for fast, structured decisions that software can consume directly.
This gives us a concrete reason to examine a design choice: which decisions can be bounded clearly enough for a specialized model, and which require broader investigation? The distinction matters for how we allocate reasoning, evaluate results, and handle uncertainty.
We have integrated Jev into an Azure and Fabric application prototype that combines dashboards, drill-downs, proactive monitoring, and conversational analysis over a Fabric lakehouse, using Azure OpenAI and Azure AI Search.
Enterprise context complements that capability by defining what the options mean and when they apply. Type safety governs an output's form. Business context helps establish whether the judgment behind it is valid.
The missing information is often business meaning
In our implementation work, recurring challenges include reporting periods, channel definitions, historical coverage, and attribution boundaries. These issues often remain invisible to the database.
Returning to the revenue example, SQL execution establishes that a query ran, not that it compared equivalent populations or periods. A valid comparison requires an approved revenue definition, comparable reporting windows, consistent business-unit coverage, and an explicit treatment of the channel change.
The system also needs to respect what evidence the user can access. Even a comparable decline does not, by itself, explain its cause. Observing a change and explaining one are different analytical tasks.
Enterprise context captures those definitions, relationships, rules, and constraints so applications can interpret data consistently.
Evidence must remain attached to the answer
Our design principle is that current numerical claims need query evidence, interpreted against the relevant business definitions.
Azure AI Search supports retrieval-augmented generation, helping applications retrieve relevant knowledge. That knowledge can explain a metric, a policy, or a business process. For a current revenue figure, our approach requires evidence from the governed data itself.
Semantic models provide measures and analytical relationships. Ontologies describe business entities and their relationships. Access policies constrain which information a user or application may use. These elements need to work together.
We have implemented freshness indicators, evidence checks, and evaluation tooling to make those dependencies visible. The experience should communicate when data is stale, a comparison is unsupported, or the evidence cannot explain an observed change.
In the revenue example, “the reported total is lower” and “partner performance has deteriorated” are not interchangeable answers.
Maintain shared context. Reuse it across workflows.
When each application separately defines metrics, relationships, and permissions, implementation work repeats and interpretations can diverge.
If a dashboard, an alert, and a conversational answer each define partner revenue independently, a business change requires three separate updates. A shared context layer gives those workflows a maintained definition to reference, including its applicable period and access constraints.
Nexus's product thesis is to automate the creation and maintenance of context that multiple applications can share. The opportunity is to reduce duplicated implementation work while keeping business meaning consistent across workflows.
That is how we aim to help customers operationalize their Azure and Fabric investments: by turning fragmented data, metrics, policies, and business logic into governed context AI can run on.
As more business decisions become automated, maintaining the context behind them becomes core enterprise infrastructure.