The analytics bias
Semantic technology is good at describing the world. It models customers, contracts, materials, assets, systems, policies, locations, events and the relationships between them. It connects records across source systems without forcing every domain into one database. It makes data more interoperable, more reusable and easier to explain.
That is valuable, and it has shaped the market's center of gravity. Most enterprise knowledge graph programs are framed as analytics, reporting, cataloguing or read-only integration. The graph is a better warehouse, or a semantic layer on top of one: richer questions, longer traversals, better dashboards.
A graph that only supports reading stays outside the flow of business change. It describes the operation. It does not help govern how the operation changes.
The missing link is business intent. Not only "what data do we have?" and "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 checks decide whether the work is acceptable?
When those answers live outside the graph, the graph is a description of data. When they become part of it, semantic technology becomes operational infrastructure.
Digital twins need context
"Digital twin" usually means a physical asset, a factory, a supply chain or a city. The more useful reading is broader: a working model of the business that can be inspected, tested, changed and governed.
Data definitions alone cannot build that. A supplier node and a component node are useful. A relationship saying the supplier provides the component is more useful. An operational scenario needs more:
- 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 may evaluate alternative suppliers.
- A compliance persona must review whether substitution changes certification.
- The expected outcome is not "find another supplier" but "protect delivery within regulatory and contractual limits."
A read-only graph supports impact analysis. A twin that supports work also needs to know what the business is trying to do with that information.
Open world, many views
One strength of semantic technology is its open-world nature. The enterprise does not have to collapse everything into one canonical model before useful work begins.
There is no single correct view of a business. Finance sees legal entities and contracts. Operations sees plants, suppliers and work orders. Risk sees obligations, controls and evidence.
All of these are legitimate at once. Making one canonical throws away context. Letting them coexist is not chaos, provided every claim is explicit: who says this, in which context, by which model, backed by what evidence, useful for which work.
Business intent supplies the orientation. It says which viewpoint matters for a task, which persona acts, which constraints apply and what success looks like.
What does the business want?
Most data programs describe supply well: which datasets, systems, reports and data products exist. Demand matters as much. Demand is not a wish list. It is the structured expression of what the business must accomplish: the use case, the personas, the stories they may perform, the outcomes they pursue, and the concepts and rules that make the context specific. On Legra, use cases describe demand and data products describe supply.
"Supplier risk" is too broad to act on. A usable use case is specific:
As a procurement risk analyst, assess whether a delayed shipment threatens committed delivery dates, identify viable substitutions, and route any regulated-product impact to compliance review before the sourcing decision is promoted.
That sentence has structure: a persona, a situation, actions, constraints, handoffs and outcomes. It points at graph resources: suppliers, shipments, products, customers, contracts, controls and certifications. It also says what must not happen. The analyst does not edit production product data directly. A substitution does not skip certification review. A change does not merge while its rules fail.
This is why intent belongs in the graph. Left in slide decks, tickets and prompts, it cannot be reasoned over, tested against or used to constrain automation.
Use case trees put intent in the graph
A use case tree models that intent as knowledge, in the same semantic environment as the domain data. It connects:
- use cases, which describe the business context;
- personas, which describe viewpoints, responsibilities and language;
- stories, which describe permitted units of work;
- outcomes, which describe measurable results;
- concepts, which define the vocabulary of the work;
- rules and tests, which decide whether a change is acceptable.
The move that matters is not nicer labels in a requirements tool. It is that these become graph resources. A use case points at the concepts it depends on. Each story points at exactly one persona. An outcome points at the evidence that measures it. A rule points at the shape it enforces.
Each team defines what its part of the business wants while its language stays connected to the shared graph. As Knowledge Graphs for AI argues, structure gives models context; use case trees add why it matters, who is acting and which work is allowed.
Intent needs logistics
If intent is to become operational, the graph needs logistics. Storing statements and running queries is not enough. Work needs to branch, stage, validate, diff, review, merge and keep its history.
Versioning makes semantic change like software change. The ideas in Versioned Knowledge and GitHub for Data apply directly: branches let people work in parallel, commits make history explicit, review and merge make promotion visible, and provenance shows which state supported a decision.
Once intent is in the graph, a use case tree stops being documentation and becomes the context for governed work. A story describes a small permitted task. A staging branch holds the proposal. Validation checks the proposal against shapes and rules before it merges.
Where agents fit
Agents do not only need more text. They need scoped context, allowed actions, provenance, testable outcomes and a place to propose change without harming production. A vector index retrieves documents; it does not know which persona is acting, which story is permitted or which branch receives the change.
On Legra those boundaries are explicit. Each agent gets a job description: one use case, one persona, permitted stories, a budget. It works on its own branch, its changes are checked against declared rules, its provenance is kept, and nothing reaches the shared branch until the rules pass.
Semantic technology does not become agent-ready by connecting a graph to a model. It becomes agent-ready when intent, domain context, permitted actions, validation and logistics share one graph-native operating model.
The first step is to model what the business wants.
Try it in Legra
For the practical review cycle behind this model, read working with AI in Legra.