The canonical knowledge graph for your enterprise.
VISEON: Enterprise builds one governed ontology of your organisation, covering its entities, relationships, rules and the documents that explain them, over the data estate you already run. People query it through VISEON Ask. AI agents query it through MCP. Both get the same answer, with its provenance.
1
canonical graph of your organisation, defined once and referenced everywhere.
<10 ms
for exact graph answers, served from the edge.
0
access policies rewritten. Your existing permissions still decide who sees what.
8 weeks
from audit to a working pilot on one business function, or location.
The problem
Every platform has its own model of your business. None of them is the record.
Your data platform has a semantic model. So do your warehouse, your BI tool, your metrics layer and your data catalogue. Each is right within its own boundary, and each describes the same customers, products, contracts and policies slightly differently.
Your procedures, SLAs and approval chains mostly live in none of them. They sit in documents and wikis. An AI agent asked to act across all of this has to reconcile it on the fly, and a probabilistic reconciliation of conflicting definitions is exactly how plausible, wrong answers happen.
Illustration: one entity, five definitions
What VISEON: Enterprise does about it
It gives each entity in your organisation one canonical definition and one identifier, links every system’s version of it to that identifier, and attaches the rules and documents that govern it. Nothing is migrated: the existing models keep doing their jobs and become sources for the canonical graph. Agents and people then query one place, and every answer says where it came from.
The ontology
What your enterprise knowledge graph holds
Structured and unstructured knowledge in one graph: the facts in your systems and the rules in your documents, tied to the same entities.
Entities
Your organisation, business units, products, services, customers, suppliers, sites, systems and people, each with one identifier.
Relationships
Who owns what, what depends on what, which contract covers which service, which system is the source for which figure.
Rules
Policies, SLA thresholds, approval chains and permission scopes, encoded as machine-readable statements an agent can check before it acts.
Evidence and provenance
The documents, wikis and records behind each fact, linked to the entities they describe, so every answer can cite its source.
Built on open standards (Schema.org, JSON-LD, RDF and the Model Context Protocol), so the graph is portable, inspectable and yours.
Your existing investments
Keep every platform. Give them one ontology.
Platform semantic models, metrics layers and catalogues each describe part of the business well. VISEON: Enterprise federates them: each becomes a source for, and an endpoint of, the canonical entity map.
VISEON: EnterpriseCanonical entity map and ontologyAsk for people · MCP for agentsNames are examples of common platforms, not integrations VISEON claims with each.
Portable by default
Open by design
Most enterprise ontologies are defined and run inside a vendor’s platform. Even where they reach data in place, the model itself stays in that platform, and so does your organisation’s definition of itself.
VISEON: Enterprise writes the ontology in open standards, so the model is portable and yours. And because it is built from the same vocabulary the web uses, the graph that governs your internal agents can also publish, deliberately and selectively, to your website, AI search and agentic commerce.
One graph, two interfaces
VISEON Ask for people. MCP for agents.
VISEON Ask is the human interface to the graph: plain-English questions, answered from governed data. The MCP endpoint is the same graph for AI agents, in Claude, ChatGPT, Copilot or your own. Because both read one source, a person and an agent asking the same question get the same answer.
- Who approves a supplier contract over £250k?
- Which services does this SLA cover?
- What is our definition of an active customer?
- Which systems hold this product’s price?
- Exact answers first. A Semantic Behaviour Tree routes each question: a direct graph answer where one exists, evidence retrieval where it does not, and a language model only to phrase what the evidence supports.
- Provenance with every answer. Each response carries the entities and sources it was built from, and says plainly when the graph does not know.
- Your permissions, unchanged. The MCP mesh sits behind your existing RBAC, ABAC and zero-trust controls. It does not bypass or re-implement them.
- Answers from the edge. The graph is served at the edge, so exact graph answers return in under 10 milliseconds, to people and agents alike.
- Context that carries over. A stateful conversation keeps the subject and the evidence already established, so follow-up questions are not fresh guesses.
Inside and outside
The graph that runs your agents can also represent you to the world.
Internal ontologies usually stop at the firewall, and public structured data is usually maintained separately, by a different team, from different definitions. VISEON uses one vocabulary for both.
You choose what is published. The public part of the graph describes your organisation, products and services to AI search engines and to other companies’ agents; the private part governs your own. Where they overlap, they are the same entity, defined once.
Read: the enterprise semantic layer, internal and external context
Private
Operations, policies, SLAs and approval chains, served to your own people and agents over MCP, inside your permissions.
Public
Organisation, products, services and expertise, published as structured data for discovery, discussion and agentic commerce.
Proof, in public
This website runs on the same infrastructure.
VISEON.IO is built as a knowledge graph first: every page, product, service, person, glossary term and FAQ is an entity with one identifier. That graph is served to people through VISEON Ask and to agents through MCP and NLWeb, exactly as it would be inside your organisation.
Try it. Ask it who founded Differentia Consulting, or whether VISEON Data Assurance moves your data, and look at where the answer comes from.
150+
pages, each with its own governed graph.
145
glossary terms, each a defined entity.
75
questions, each with its own page and answer.
0
unresolved references across the site.
The data underneath
An ontology is only as trustworthy as the data it points to.
VISEON Data Assurance scores every row of the data behind the graph, where it lives, against the nine DAMA quality dimensions. So when an agent relies on a figure, you know how far that figure can be trusted, and since when.
Deployment
One function first, in eight weeks
Start where the value is clearest, prove it, then extend the same graph function by function.
Audit
Weeks 1–2
Map the entities, rules, approval chains and sources for one pilot function, and where their definitions conflict.
Model
Weeks 3–4
Establish canonical definitions and identifiers, encode the rules, and set permission scopes and guardrails.
Connect
Weeks 5–8
Deploy the MCP endpoint and VISEON Ask, connect the first agents, and test answers against known cases.
Govern
Ongoing
Detect drift as systems and procedures change, and keep the graph aligned with how the business actually works.
Questions
What architects ask first
How is this different from a data catalogue or a semantic layer?
A catalogue inventories data assets; a semantic layer defines metrics for analytics. VISEON: Enterprise models the business itself: its entities, their relationships, the rules that govern them and the documents that explain them. Catalogues and semantic layers become sources for that model, not replacements for it.
We already have an ontology in our data platform. Why add another?
You would not be adding a competing one. A platform’s ontology describes the data inside that platform. VISEON federates it with the definitions in your other systems and documents, so there is one canonical identifier per entity across all of them. The platform ontology keeps working and is linked, not replaced.
How does it compare with Palantir?
Both model the enterprise as an ontology across structured and unstructured data, and both can work with data where it lives. The difference is where the ontology itself lives. Palantir’s is defined and run inside Palantir’s platform. VISEON’s is written in open standards (Schema.org, JSON-LD and RDF-compatible identifiers), so the model is portable, and selected parts of it can be published externally for AI search and agentic commerce.
Does our data move?
No. The graph holds definitions, relationships, rules and references to your sources. Queries are answered through MCP behind your existing access controls.
What is the difference between VISEON Ask and the MCP endpoint?
They are two interfaces to the same graph. VISEON Ask is for people: a conversational interface that answers in plain English with its sources. The MCP endpoint is for AI agents and assistants. Because both read one source, they give the same answer.
Which standards is it built on?
Schema.org and JSON-LD for the entities and relationships, RDF-compatible identifiers, the Model Context Protocol for agent access, and NLWeb for natural-language access to published content. Metric definitions can align with the Open Semantic Interchange specification.
Give your AI one version of the truth
Start with an architecture review of one function: where your definitions conflict, what your agents need, and what an eight-week pilot would prove.
Or email [email protected] · Built by Differentia Consulting, enterprise data specialists since 2002.