Semantic Tech Has an Analytics Bias
Semantic technology is very good at describing the world. It can model customers, contracts, materials, assets, systems, policies, locations, events, and the relationships between them. It can connect records across source systems without forcing every domain into the same physical database. It can make data more interoperable, more reusable, and more explainable.
That is already valuable. But it has also shaped the market’s center of gravity. Many enterprise knowledge graph programs are framed as advanced analytics, reporting, data cataloguing, or read-only integration. The graph is treated as a better warehouse, or a better semantic layer on top of a warehouse: ask richer questions, traverse more relationships, and build better dashboards.
Those uses matter, but they do not exhaust what semantic infrastructure can do. A graph that only supports read-only analysis is still outside the real flow of business change. It can describe the operation, but it does not yet help govern how the operation changes.
The missing link is business intent.
Not just “what data do we have?” or “what does this entity mean?”, but:
- What does the business want to achieve?
- In which context does the question matter?
- Which person or role is asking?
- Which action is allowed?
- Which outcome should improve?
- Which domain knowledge and constraints apply?
- Which checks decide whether the work is acceptable?
When those answers live outside the graph, the graph is only a description of enterprise data. When those answers become part of the graph, semantic technology starts to become operational infrastructure.
Digital Twins Need Operational Context
The phrase “digital twin” is often used for physical assets, factories, supply chains, or cities. The more useful enterprise reading is broader: a digital twin is a working model of the business that can be inspected, tested, changed, and governed.
That kind of twin cannot be built from data definitions alone. A supplier node and a component node are useful. A relationship saying that the supplier provides the component is more useful. But an operational scenario needs more context:
- The component is used in three regulated products.
- One product is committed to a high-priority customer order.
- The supplier has a shipment delay.
- A procurement persona is allowed to evaluate alternative suppliers.
- A compliance persona must review whether substitution changes certification status.
- The expected outcome is not simply “find another supplier”; it is “protect delivery while staying within regulatory and contractual constraints.”
A read-only graph can support impact analysis. It can show affected products, orders, customers, plants, and controls. But a digital twin that supports operational work also needs to know what the business is trying to do with that information.
This is where many analytics-centered graph programs stop too early. They model domain facts, but they do not model the intent that turns those facts into governed work.
Open World Does Not Mean One Canonical Model
One of the most important strengths of semantic technology is its open-world nature. It does not require the enterprise to collapse everything into one firm-wide canonical model before useful work can begin.
That matters because there is no single correct way to view a business.
Finance may see the enterprise through legal entities, cost centers, and contracts. Operations may see plants, materials, suppliers, work orders, and constraints. Strategy may use Porter value chains, capability maps, product lines, or market segments. Risk may care about obligations, controls, and evidence. Process teams may use business process architectures. Data teams may use data products and ownership boundaries.
All of these views can be legitimate at the same time. Forcing one of them to be the canonical model usually throws away context. Letting them coexist does not mean accepting chaos. It means making claims explicit: who says this, in which context, according to which model, backed by which evidence, and useful for which work.
That is a natural fit for semantic technology. The hard part is not only linking many views of the enterprise. The hard part is making those views actionable without pretending that one of them is the universal truth.
Business intent provides the missing orientation. It tells the system which viewpoint matters for a task, which persona is acting, which constraints are relevant, and what success looks like.
What Does the Business Want?
Most enterprise data programs are good at describing supply: what datasets, systems, reports, APIs, domains, or data products exist. That is necessary. But demand is just as important.
Demand is not a vague stakeholder wish list. It is the structured expression of what the business needs to accomplish. It includes the use case, the people or personas involved, the stories they are allowed to perform, the outcomes they are pursuing, and the concepts and rules that make the context specific.
For example, “supplier risk” is too broad to be operational. A useful use case is more specific:
As a procurement risk analyst, assess whether a delayed supplier shipment threatens committed customer delivery dates, identify viable substitutions, and route any regulated-product impact to compliance review before the sourcing decision is promoted.
That statement contains structure. It has a persona, a situation, actions, constraints, handoffs, and outcomes. It can point to the graph resources that matter: suppliers, shipments, materials, products, customers, contracts, controls, certifications, and delivery commitments.
It can also define what must not happen. An analyst should not directly mutate production product data. A substitution recommendation should not bypass certification review. A graph update should not be merged if required validation rules fail.
This is why business intent belongs in the graph. If it remains in slide decks, tickets, meeting notes, and prompts, the operational system cannot reason over it, test against it, or use it to constrain future automation.
Use Case Trees Put Intent in the Graph
Use Case Trees are a way to model that intent as structured knowledge. They make business requirements part of the same semantic environment as domain data, rather than treating requirements as separate project artifacts.
A Use Case Tree can connect:
- use cases that describe the business context;
- personas that describe viewpoints, responsibilities, language, and skills;
- stories that describe permitted units of work;
- outcomes that describe measurable business results;
- concepts that define the domain vocabulary used in the work;
- governance rules and tests that decide whether a change is acceptable.
The important move is not that these objects receive nicer labels in a requirements tool. The important move is that they become graph resources. A use case can point to the concepts it depends on. A story can point to the persona that performs it. An outcome can point to the evidence used to measure it. A validation rule can point to the graph shape or policy it enforces.
That gives the enterprise a much richer context model than a dashboard filter or a document search query. It lets different teams define what their part of the business wants, while still connecting their language to the broader knowledge graph.
This also changes the role of knowledge graph infrastructure in AI programs. The point is not simply to retrieve better chunks for an LLM. As described in Knowledge Graphs for AI, graph structure can give models relationship-rich context. Use Case Trees add another layer: they tell the system why that context matters, who is acting, and which work is allowed.
WWKG as Data Logistics Infrastructure
If business intent is going to become operational, the graph needs logistics. It is not enough to store triples and run queries. Enterprise work needs a way to branch, stage, validate, diff, review, merge, replicate, and preserve history.
That is the role WWKG is designed to play: semantic data logistics infrastructure.
The logistics metaphor matters. In a warehouse-style system, data is often loaded, transformed, queried, and overwritten as the live state changes. In an operational semantic system, change itself needs a governed path. A team may need to test a supplier substitution, update a capability model, enrich a product taxonomy, add a compliance control, or reconcile conflicting domain claims. Those changes should not all land directly in the same production graph.
WWKG’s versioning model makes semantic change more like software change. The ideas in Versioned Knowledge and GitHub for Data are directly relevant here: branches let people work in parallel; commits create explicit history; review and merge make promotion visible; provenance makes it possible to understand which graph state supported a decision.
That model is especially important once business intent is part of the graph. A Use Case Tree is not just documentation. It can become the context for governed work. A story can describe a small, permitted task. A staging branch can hold the proposed change. Validation can check whether the proposal still conforms to declared shapes, policies, or business rules before it is merged.
This is the difference between a graph used for analytics and a graph used as operational infrastructure.
Where Agents Fit
WWKG should not be described as an AI agent platform today. That would overstate what has been implemented. The better and more defensible claim is that WWKG is the kind of data logistics layer that large-scale agentic use cases will need.
LLM agents do not only need more text. They need scoped context, allowed actions, provenance, testable outcomes, and a place to propose change without damaging production data. A vector index can retrieve relevant documents, but it does not by itself know which persona is acting, which story is permitted, which branch should receive the change, or which validation gates should apply.
The future direction is to make those boundaries explicit:
- bind an agent session to a workspace, use case, and persona;
- expose only the stories that are valid in that context;
- execute small targeted tasks against a staging branch;
- validate the proposed graph changes against declared rules and outcomes;
- preserve provenance so people can inspect what happened;
- merge only after the change has passed the required review path.
In that model, the agent is not given arbitrary write access to an enterprise knowledge graph. It acts through named stories, as a declared persona, inside a specific business context, against a branch that can be tested before it affects the shared graph.
That is the missing link: semantic technology does not become agent-ready merely by connecting a knowledge graph to an LLM. It becomes agent-ready when business intent, domain context, permitted actions, validation, and data logistics are part of the same graph-native operating model.
The first step is to model what the business wants.
This article is part of the WWKG article series on semantic data logistics, business intent, and knowledge graph infrastructure for future agentic enterprise systems.