GA AI Case Study – Building an ontology and context control plane for enterprise AI
At a glance
Global Advisors built a semantic and context architecture so that applications, data services and AI agents could use the same organisational concepts without granting a model authority over the underlying facts. The work combines a versioned enterprise ontology, generated machine-readable contracts, bounded context projections, deterministic entity matching and privacy-safe evidence receipts.
This is the layer between raw enterprise data and a useful AI interaction. It answers four questions: what a concept means, which source owns a fact, what information is safe and relevant for the current request, and what evidence shows how that context was assembled.
Maturity: the core ontology, generation pipeline, institutional projection and runtime context path are implemented and in active internal use; source coverage, catalogue synchronisation and selected identity integrations continue to mature.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
The situation
Enterprise AI systems rarely fail because an organisation has no data. They fail because meaning, ownership and access are inconsistent.
A person, client, project or document may appear under different identifiers in several systems. A service may have a public address, an administrative endpoint and a direct machine interface. A capability may be installed without being authorised or operational. A model may retrieve a plausible statement but have no basis for deciding whether it is current, sensitive or authoritative.
Simply sending more data to the model would have made these problems worse. Global Advisors needed a controlled meaning layer that could connect knowledge across systems while preserving source ownership, privacy and uncertainty. Runtime enrichment also had to be fast, bounded and optional. An unavailable context component could not be allowed to break ordinary model access.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
The architectural response
We separated semantic definition from operational fact and request-time context.
The ontology defines stable entities, relationships, vocabularies and mappings. Operational systems continue to own the facts they create and maintain. A compilation pipeline validates the semantic source and produces different projections for different consumers. The context service loads an immutable, privacy-scanned read model and uses deterministic matching to assemble a small source-backed digest for the current request.
The resulting architecture has several layers:
- canonical meaning: reviewed definitions with stable identifiers and explicit lifecycle;
- source mapping: links from provider-specific records to provider-neutral concepts;
- validation and generation: repeatable compilation into graph, schema, catalogue, policy and context artefacts;
- institutional projection: approved facts with provenance and sensitivity controls;
- request-time assessment: a decision to skip, enrich or preserve ambiguity;
- bounded assembly: only the relevant subgraph and safe facts enter the model request; and
- receipt: metadata identifies the selected entities, source descriptions and release without retaining the raw prompt.
This separation prevents the graph, model gateway or agent from becoming a new system of record by accident.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
What we implemented
The canonical semantic model covers identity, organisations, commercial relationships, work, evidence, investigation, artefacts, action, state, policy, provenance and publication. At the time of this study it contained 47 entity definitions, 66 relationship definitions and 27 controlled vocabularies with 124 terms.
The delivery pipeline generates multiple consumer contracts from the same reviewed source, including graph representations, linked-data records, constraint shapes, application schemas, catalogue payloads, deterministic policy packages and bounded context artefacts. Generated files carry release identity and can be rebuilt rather than edited by hand.
The institutional release has been proven at meaningful operating scale: more than 430 000 graph statements feed a compiled projection representing over 12 000 governed entities. A separate capability projection connects the semantic layer to the firm's reusable AI skills without merging action routing, identity and authorisation into one graph.
The runtime context implementation adds:
- an immutable read model compiled before requests arrive;
- no network or source-system calls on the normal request path;
- allowlisted entity types, aliases and short source-backed facts;
- precision-first alias matching with stable graph identities;
- current-turn priority so old assistant text cannot outweigh a new request;
- bounded conversation state for follow-up references such as pronouns;
- explicit available, skipped, ambiguous, unavailable, stale, conflicting and redacted states;
- separate treatment of human-facing and machine-facing endpoints;
- metadata-only receipts without raw prompts or protected source content;
- ordinary-model negative controls that receive no institutional enrichment; and
- independent rollback of context enrichment without changing the underlying model route.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
Difficult problems we had to solve
Meaning and source ownership are different
An ontology can define what a project or person means across the firm, but it should not seize ownership of operational records. We made source authority explicit and required provenance for derived facts. This lets consumers share meaning while retaining a defensible path back to the system responsible for the record.
Identity matching can create false confidence
Names, email addresses and fuzzy similarity are evidence, not authority. Silent merges can expose information or attribute work to the wrong person. The architecture keeps unresolved records separate unless a source-owned assertion or reviewed crosswalk supports reconciliation. Ambiguous aliases cause abstention or clarification.
A useful graph can still be unsafe context
Graph reachability does not imply permission or relevance. The context compiler admits only approved types and fields, rejects protected attributes and limits the size of the projection. Principal-scoped memory remains outside the shared institutional graph. The model sees a small digest, not unrestricted access to enterprise data.
Request-time enrichment must not become a fragile dependency
Querying multiple source systems or a remote graph during every model request would add latency and new failure modes. We compile reviewed snapshots offline and load them once into worker memory. If the read model is invalid or unavailable, the model request continues without enrichment. If permission or execution policy fails, the action remains denied.
Current intent must outrank conversational residue
Long conversations contain prior user requests, model statements and tool output. Treating all of that as equal evidence can inject irrelevant context. The evaluator anchors on the latest human request, uses strong recent mentions and allows only bounded principal-scoped continuity for follow-ups.
Installed capability is not authorised capability
Service catalogues, routes and application extensions provide discovery evidence, but their presence does not prove access, health or fitness for a task. The semantic model represents endpoint roles and capability state explicitly. Authorisation and side-effect gates remain separate from discovery and model selection.
Semantic change has a long blast radius
Renaming an identifier can break graph queries, application contracts, policies, catalogue entries and context compilation. Stable identifiers therefore outlive changing labels. Concepts are deprecated before removal, compatibility impact is reviewed and every release is validated across its generated outputs.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
Controls and assurance
- Versioned, reviewable semantic definitions;
- stable identifiers and explicit deprecation rules;
- required ownership, lifecycle, sensitivity and provenance metadata;
- deterministic builds and machine-readable release manifests;
- relationship, vocabulary, reference and constraint validation;
- privacy scans before context projection;
- bounded entity and conversation matching with deliberate abstention;
- separate permission, approval and execution controls;
- dry-run publication, backup, scoped replacement and exact read-back;
- positive, negative and ambiguity canaries; and
- rollback paths for both graph publication and runtime context.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
Results
Applications and agents can now work from a shared definition of core organisational concepts. The same semantic source can support graph query, application validation, catalogue discovery, policy evaluation, capability routing and AI context without forcing every consumer to implement its own interpretation.
For users, the practical result is more relevant institutional context with less prompt stuffing. The system can recognise a governed entity in the current request, supply a compact set of source-backed facts and identify the release and sources used. When it lacks a strong match or safe evidence, it can say so through its status rather than inventing certainty.
For operators, the architecture provides a reproducible path from reviewed meaning to deployed projection. Counts, digests, snapshots and canaries make it possible to test whether the runtime is using the intended release. The model remains replaceable because the organisation's semantics and controls live outside it.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
What we learned
Enterprise context is an information-governance problem before it is a prompt-engineering problem. More tokens do not resolve unclear ownership, conflicting identities or protected data.
We also learned that a context service must know when to do nothing. Skipping enrichment on a weak match protects both quality and privacy. Preserving ambiguity is better than presenting a confident but wrongly reconciled institutional fact.
The ontology becomes useful when it produces contracts and operating evidence. A conceptual diagram alone does not align applications. Stable identifiers, source mappings, validation, generated artefacts and release discipline turn shared meaning into working infrastructure.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
Why this matters for leaders
Leaders planning enterprise AI should ask:
- Which system owns each class of fact, and where is shared meaning defined?
- How are identities reconciled without treating similarity as proof?
- What prevents graph reachability from becoming automatic disclosure?
- Can the context layer abstain when evidence is weak, ambiguous or stale?
- Does a model response carry enough metadata to explain which institutional context was used?
- Can semantic changes be validated across applications, policies and agents before release?
- Would organisational meaning and governance survive a change of model provider or application platform?
The strategic goal is not to place every enterprise record into a model's context window. It is to give AI systems the smallest trustworthy slice of institutional meaning needed for the work at hand.
GA AI Case Study – Building an ontology and context control plane for enterprise AI
Note
Global Advisors does not perform technical AI implementation or systems integration for clients. However, we have worked on architecting and implementing AI at a deep level in our own business since the beginning of 2024. This allows us to provide grounded AI strategic and architectural advice based on a deep hands-on knowledge of AI. We work with clients to build strategies, business and operating models to win in an AI enabled world. We help them make architectural and partner choices for implementation and work with them to change their businesses in response.
