Forvis Mazars × TPO Management Services
Building AIN (عين): an Autonomous Intelligence Network for executive operations, facilities, logistics, and decision support. AIN means "the Eye" in Arabic, the intelligence layer of TPO.
×
How this deck is structured
A direct brief, not a vendor pitch
Everything here, Forvis Mazars runs internally today. This is our position, our evidence, and a concrete proposal, not a sales deck.
Position, evidence, and proposal
- A clear framing of the opportunity and why the moment is right.
- The platform we run today: ABI as the open-source AI backbone, GAIA for sovereign AI infrastructure, BOB for operational intelligence.
- A concrete engagement model and commercial structure ready to discuss.
Our principles
- We only share architectures and patterns we run ourselves or with clients today.
- We will not claim sovereignty where vendor constraints undermine it.
- We present trade-offs honestly, including where open-source has limits.
- The appendix holds the full evidence pack for any claim made in the main deck.
This portal is a live demonstration of what we build
These slides are part of a portal you are looking at right now, produced using BOB, our own AI system, its structured codebase, and agent-driven workflows. Every slide, every knowledge graph, every section was generated from formally organised content.
Built inside BOB
- The portal is a module created inside BOB, Forvis Mazars' own AI platform.
- The engagement content, slides, and ontology were produced directly from that module.
- It includes the AIN Ontology Draft, deployed on a dedicated virtual private server.
How it was produced
- Content structured as semantic modules, not slide text.
- Feedback from this call translated into code changes in real time.
- Every change tracked: pull requests, review, version history.
- This is the delivery model we propose for your process ledger.
TPO Management Services: the operational context
The Private Office is a private executive office, not a government body. It manages the affairs and movements of VIPs in close proximity to UAE leadership, with the highest standards of discretion, operational continuity, and strategic alignment.
The AI mandate
- Information Technology Section Head of The Private Office, a private executive function (not a government body), serving VIPs in close proximity to UAE leadership.
- Mandate: ensure all AI systems remain sovereign, with full control over data, infrastructure, and governance.
- Data residency, governance, and semantic control are baseline requirements.
- Looking for a partner who stays, not one who delivers and exits.
The strategic frame
- TPO operates in close proximity to UAE leadership, aligned with national objectives: knowledge-based economy, human capital, resilience through self-reliance.
- AI sovereignty is the operational expression of those priorities: own your data, your models, your governance.
- Education, sustainability, national identity. AI infrastructure serving these missions must be auditable and domestically controlled.
A process ledger for a sovereign organisation operating at the highest level of discretion
The Private Office orchestrates a complex portfolio across staff, intelligence, operations, logistics, communications, and finance. These map directly onto six standard subsystems already used in high-assurance environments.
Nine subsystems Military Staff System ↗
- S1 · Personnel: manpower, HR, access, rotations.
- S2 · Intelligence: signals, analysis, security, context.
- S3 · Operations: facility, fleet, scheduling, maintenance.
- S4 · Logistics: supply, procurement, assets.
- S5 · Plans: strategy, planning, programmes.
- S6 · Signal: communications, IT, infrastructure.
- S7 · Training: education, capability development.
- S8 · Finance: budget, contracts, resource management.
- S9 · External Affairs: civil-military cooperation, stakeholder relations.
From documents to intelligence
- Each process has a formal definition: inputs, outputs, temporal region, responsible agent.
- Processes become queryable. The system knows what is happening and when.
- Unknown zones surface automatically: if a temporal region is missing, the system flags it.
- Interoperability by design: every process speaks the same language as every other.
Once AI is handed full autonomy, what is left? The trusted third party.
Forvis Mazars is building the supply chain of experts that will control, audit, and govern AI systems. The same role it plays in financial audit today, applied to AI.
AI Assurance & Semantic Governance
Investing in the foundation for trusted and auditable AI
- Knowledge Management. Design and governance of enterprise semantic models to ensure consistency, traceability, and interoperability.
- Ontology Vetting & Certification. Independent ontology review, semantic quality assessment, governance framework, AI readiness assessment.
- Semantic AI & Executable Ontology. Grounding AI on business concepts, agent orchestration through semantic models, human-in-the-loop decision.
Ecosystem partnerships
Led by John Beverley. Ontology standards development and certification (BFO ISO/IEC 21838-2:2021)
Led by Jeremy Ravenel. Opensource Agentic AI Platform, alternative to Palantir
Led by Yann Chauvelle. Opensource. Track experiments, validate models, and collaborate with confidence
Led by Dave McComb. Knowledge graph design and ontology consulting. Pioneers of gist, the minimalist enterprise ontology.
Your terms. Your definitions. Your rules. Forever.
Forvis Mazars encodes your process catalogue in open standards (BFO/CCO), not proprietary formats. Every AI system and every future vendor plugs into it. You own the meaning; we bring the expertise to build it.
Your sovereign layer
- Terms and definitions: in your language, your context, your jurisdiction.
- Process catalogue: formally encoded, not locked in slide decks.
- Governance rules: auditable, versioned, machine-readable.
- Open standards: BFO/CCO, same baseline as NATO, NIH and DoD.
Everything else
- Compute vendors: on-prem, colocation, cloud, hybrid.
- AI platforms: open-source or proprietary, today and in 10 years.
- Analytics and reporting tools.
- Integration partners and implementation vendors.
This is how we already work in accounting and financial regulation. We are now applying the same discipline to AI, building the chart of accounts for intelligent systems.
The first private office in the world with a self-improving operating system
The end state is a semi-autonomous cybernetic system: sensors everywhere, agents handling routine operations, humans escalated only when the system hits a genuine unknown.
How it improves
- Each process execution is logged against its formal definition.
- Deviations from the baseline surface as signals, not noise.
- Positive deviations update the process definition. The system learns.
- Unknown zones trigger targeted research agents until resolved.
- Human escalation only when the system cannot resolve the unknown.
Proactive, not reactive
- Weather, events, and external signals feed into operational planning automatically.
- Staff schedules, fleet availability, and facility status are always current.
- Procurement agents surface vendor anomalies before they become problems.
- The system asks what it does not know. It does not wait to be asked.
This is built on the process ledger. Without formally encoded processes, there is nothing to improve. The semantic spine is not the end product: it is what makes the end product possible.
Search interest for ontology AI is moving from niche to visible demand.
Executive readout
- Both terms stayed near zero through 2024, then accelerated sharply from mid-2025.
- By May 2026, forward deployed engineer reaches the Trends maximum of 100, while ontology AI reaches 66.
- The signal is not mature adoption. It is market attention moving toward ontology-backed AI delivery and embedded implementation roles.
Implication: semantic infrastructure is becoming part of the AI operating model, not a specialist data architecture topic. The strategic insight is that while many use ontology and AI as buzzwords, the craft is already being applied in the most demanding environments: NATO, NIH, and the US Department of Defense all operate on BFO (ISO/IEC 21838-2:2021), a formal ISO standard for information technology. That is where the signal is real.
AI makes knowledge easier to generate, but harder to organize.
More output, less coherence
Organizations are accumulating documents, reports, dashboards, copilots, agents, vector indexes, and generated summaries without a shared model of the things those systems talk about.
Systems need shared entities
AI workflows need stable understanding of people, products, locations, processes, regulations, assets, events, evidence, and decisions.
What increases
- Content volume.
- Model experimentation.
- Platform choices.
- Agent workflows.
What does not automatically increase
- Shared definitions.
- Decision traceability.
- Governed mappings.
- Cross-platform meaning.
Result
More AI does not necessarily create more coherence. Semantic infrastructure is the control layer that keeps AI grounded in the same reality as operations.
The most advanced organizations are converging toward the same pattern: models change, platforms change, but semantic assets become durable.
Systems do not converge by themselves
Operational systems, documents, dashboards, copilots, and data platforms keep multiplying. The result is more access to data, not necessarily more shared understanding.
Meaning becomes reusable infrastructure
Healthcare, defense, finance, retail, cloud, and energy examples show the same move: controlled terms become ontologies, then knowledge graphs, then governed workflows.
Representation may beat model choice
The next advantage may not come from having a better AI model. It may come from having a better representation of operational reality.
Core message
Strategic semantic infrastructure lets an enterprise change AI models, platforms, and applications while preserving the governed meaning those systems depend on.
The organization evidence points to the same architecture pattern.
Palantir TechnologiesEnterprise, defense, operations
OBO FoundryLife sciences ontology ecosystem
Department of War / DoD and ICDefense ontology standards
U.S. Customs and Border Protection / CBPBorder operations ontology
National Institutes of Health / NCBO BioPortalBiomedical infrastructure
NATO research communityDefense interoperability
GoogleSearch and AI infrastructure
MicrosoftEnterprise data and AI
Amazon Web ServicesCloud graph infrastructure
IKEAConsumer goods, retail, and digital experience
EDM Council FIBOFinance
Goldman Sachs / FINOS LegendFinance
JPMorgan ChaseFinance
Gene Ontology ConsortiumLife sciences
Open PHACTSLife sciences / pharma
AstraZenecaLife sciences / pharma
RocheLife sciences / pharma
NovartisLife sciences / pharma
PfizerLife sciences / pharma
DARPADefense research
BoeingAerospace
Airbus SkywiseAerospace
The Open Group OSDUEnergy
EquinorEnergyThe same lesson appears across sectors: durable meaning outlasts systems.
SNOMED
Clinical interoperability requires shared definitions. The ontology becomes infrastructure, not an application.
OBO Foundry
Federated ontologies let research organizations collaborate without redesigning meaning.
Mission models
Interoperability starts with common operational understanding, not APIs alone.
Entity-centric systems outperform document-centric systems for search, assistants, and recommendations.
AWS / Linux
Standard infrastructure layers become reusable foundations. Semantic assets may follow the same path.
Strategic lesson
Organizations that control their semantic infrastructure are better positioned to change models, adopt platforms, integrate acquisitions, comply with regulation, and preserve institutional knowledge.
Semantic infrastructure connects systems, data, meaning, graph memory, and AI execution.
How to read it
- Data products make evidence reusable, but the ontology defines what that evidence means.
- The knowledge graph connects approved meaning to operational memory: entities, events, provenance, and context.
- Agents consume governed context, execute workflows, and leave an audit trail back to operations.
Strategic point: platform choice matters less than control of the semantic contract.
The same pattern that works for defense, finance, and healthcare applies directly to VIP and hospitality operations.
One definition, every system
A VIP, a site, a movement, an asset, an event: define these once in a governed semantic layer and every system, every agent, and every report works from the same reality. No more conflicting records across Odoo, spreadsheets, and briefing documents.
Decisions, not data models
The entry point is operational: who is moving, when, with what support, under what protocol, at what risk level. Semantic structure follows from those questions, not the other way around.
Every action traceable
Hospitality and VIP operations require full accountability: who approved what, when, based on which briefing. A governed semantic layer makes every decision traceable by design, not by manual reconstruction.
The layer belongs to TPO
Encoded in open standards (BFO/CCO), the semantic spine is not tied to any platform. Systems change; the meaning stays.
One AI operating system across your operations.
The meta-grid that connects intent to outcome, commitment to fulfilment. One system where your people and AI agents work side by side on the same semantic spine, human and machine collaboration designed in, not bolted on.
How to read it
- One operating system, not a sprawl of disconnected tools to manage.
- Your people and AI agents work on the same semantic spine: agents handle the volume, people keep the judgment calls.
- For The Private Office, facilities, procurement, logistics, and intelligence all run on one system you own and control, with no data crossing the perimeter unless you allow it.
Services, modules, components: a disciplined stack
Shared platform services abstract infrastructure; modules and components carry domain logic.
Platform services
- Relational, document, vector, and graph databases.
- Object storage, email, API gateway, secrets store.
- Modules consume services, not raw infrastructure.
Modules and components
Every platform we build follows the same disciplined hierarchy: service → module → component → asset.
We are building the open-source AI operating system stack from which AIN can stem.
Tests · schemas · transformers
hr_recruitment · hr_skills
Metabase · Superset
base_automation
hr_fleet · barcodes
note · project_forecast
Mattermost
gamification
hr_expense · account_edi
partner · community
Apache Jena
MinIO
Headscale
Mistral
Qwen
vLLM
DeepSeek · Gemma
Kubernetes
no vendor access
Not all AI requests are equal. Routing by use case is what makes the difference between a sovereign system and a liability.
What routing unlocks
- Sensitive data (intelligence on persons, sites, confidential operations) stays on your sovereign compute. Non-negotiable, by design.
- Public data (market intelligence, research, open signals) does not need to consume your GPU capacity. It can run on cloud, at lower cost and higher speed.
- This creates a natural partnership layer: Forvis Mazars can operate the cloud compute tier for public workloads, giving you access to our knowledge graph and research infrastructure without any sensitive data leaving your perimeter.
- Sovereignty is not about blanket isolation. It is about knowing exactly which data goes where, and why.
The routing decision is about data classification, not model size. You control the boundary.
Redesigned from first principles, a process needs one loop, not fifteen systems.
The OODA loop, extended
Observe, Orient, Decide, Act. John Boyd designed this cycle for fighter pilots in 1976. Jamie Dimon uses it at JPMorgan Chase for scenario evaluation. The logic holds at any scale.
The AI-native extension is the fifth step: LEARN. Each cycle enriches the semantic spine. The loop gets faster and more accurate with every pass, and that is what makes it a flywheel, not just a loop.
Each S-code subsystem feeds events in. The flywheel runs across all of them on the same semantic layer. Applications are views on top.
What everyone is trying to build: AI by design, a system that knows where it stands.
The vision
An autonomous AI system does not just process requests. It continuously observes its own premises: compute, data, network, usage. It classifies those signals the same way it classifies any other input, and it acts.
No human has to notice a GPU node is degraded. The system already knows. It reroutes, scales, or escalates based on what it observes about itself.
This is situational awareness applied to infrastructure. The AI system becomes an agent over its own operating environment.
The stack can be private. What sovereignty means for you still has to be defined.
Air-gap, data residency, vendor access, compute ownership: each is a different commitment. The right answer depends on your workloads, your data class, and your operational risk.
Infrastructure assessment
- Where is compute? Bare metal, colocation, national cloud, hybrid?
- Who operates it? Internal team, managed services, 24/7 SLA?
- What connectivity exists? Cross-border paths can undermine residency claims.
- What attack surface? Risk assessment and isolation per data perimeter.
What we'll cover together
Reference architectures with operating models, transparent sovereign vs. assumed sovereign assessment, and proof from organizations facing similar compliance bars.
With GAIA we know what running your own AI infrastructure actually means.
Forvis Mazars operates its own GPU servers and serves internal and external clients. Here is what that looks like in practice.
Managed GPU servers under the Forvis Mazars domain. Physical compute owned and operated by Forvis Mazars, not rented per token from a hyperscaler.
Open-weight models evolve fast. Running your own infra means owning the upgrade cycle: when to pull new versions, test them, and cut over. Model upgrades shift hardware requirements too. Budget for refreshes alongside software.
Models are exposed via a unified API endpoint. Applications, agents, and workflows call the same endpoint regardless of which model is active underneath.
Requests are routed to the right model based on data classification and use case. Restricted workloads stay on sovereign compute. Lower-sensitivity tasks can use lighter models or fallback tiers. LiteLLM handles the routing layer.
Private architecture is an operating model, not just hardware
Owning the compute stack means every infrastructure event becomes a data point the system can classify, reason about, and act on.
What's now
Internal ops, managed services, or hybrid. Clear ownership for prod workloads.
Runbooks, failover, 24/7 support. The operator knows your applications.
Your alerting stays in your control plane regardless of who operates the hardware.
With autonomous AI system
GPU load, node health, latency: every infra event is a structured data point, not just a log line.
Infra events pass through the same classification layer as any other signal. The system builds a live picture of its own state.
A degraded node triggers automatic rerouting before users see a failure. The infrastructure corrects itself.
Procurement: commitment → governed workflow → fulfilment
Today, a verbal commitment disappears. Encoding procurement as a governed process makes every decision observable, auditable, and improvable. The flywheel closes the loop: each completed order feeds better data into the next cycle.
The seven BFO categories: a chart of accounts for AI
BFO operationalizes ISO/IEC 21838-2:2021 the way auditors operationalize accounting standards, turning a standard into a working guidance framework. The seven categories are not theory: they are the foundation of Trusted Intelligence: a target state where AI Assurance becomes as significant to organisations as Financial Audit Assurance, giving every intelligent system a shared, auditable structure for what it knows, who acts, when, where, and why.
Continuants (analog to assets)
- Material Entity (WHO): organizations, teams, systems
- Site (WHERE): infrastructure locations and zones
- Quality (HOW IT IS): states, levels, classifications
- Information (HOW TO KNOW): knowledge assets, documents
- Role / Realizable (WHY): roles, mandates, dispositions
Occurrents (analog to liabilities)
- Process (WHAT): macro, micro, nano (activities, workflows, engagements)
- Temporal Region (WHEN): timeframes, cycles, deadlines
Governance at scale is built on a proven standard, not a new framework.
Formal ontologies are already the deployed standard in the most demanding environments. The question is not whether to trust them, it is how to build on what already works.
Why a reusable framework
- One controlled delivery chain, not exotic one-off applications.
- Security patches and fixes propagate across all deployments.
- Governance boundaries enforced by design, not after the fact.
- Duplicate and scale without losing control or auditability.
BFO/CCO: already deployed at scale
- Basic Formal Ontology (ISO/IEC 21838-2:2021) and Common Core Ontologies are the existing standard for national security and biomedical research programs.
- Not an emerging approach: adopted by DARPA, NIH, and defense research communities.
- Provides the shared semantic layer that makes AI systems auditable and interoperable across your operations.
- The right foundation for high-assurance AI is what already holds in the most demanding environments.
Segment first, then attribute access.
Access control answers who can reach what. Two layers do the work: isolating perimeters, then mapping permissions to people, roles, and systems.
Segmentation
- Network and logical isolation between prod, maintenance, and dev zones.
- Separate agent sandboxes for code execution before promotion.
- Data perimeters: each workload sees only its authorized datasets.
Attribution
- Map business processes to people, roles, and authorized systems.
- Ontology and graph models for complex enterprise authorization (e.g. JP Morgan pattern).
- Agents verify permissions before querying production data platforms.
Classification and tagging drive model and infrastructure routing.
This is the same routing principle as the platform layer, applied to governance: data sensitivity, not model size, decides where a request can run.
Every file carries a sensitivity tag
- Every file carries a sensitivity tag: public, internal, confidential, restricted.
- Microsoft and enterprise platforms now enforce tagging at ingestion.
- Untagged assets enter an assessment workflow before AI processing.
Where each class can run
- Restricted: full local and sovereign treatment, no external compute fallback.
- Confidential: sovereign GPU or approved private endpoints only.
- Internal and public: may use approved cloud models with audit logging.
- The framework accommodates multiple security typologies by design.
Cyber in the agentic era: red team, blue team, and the ontology layer.
Agentic AI expands the attack surface. Ontology-grounded security frameworks make adversarial behavior and defensive response machine-readable, auditable, and governable at scale.
Adversarial behavior
- Agents introduce new attack vectors: prompt injection, lateral movement through APIs, unauthorized data access.
- MITRE ATT&CK formalizes adversarial tactics as a structured ontology, applicable to AI agent behavior.
- Red team exercises must now include agentic threat models, not just perimeter attacks.
Defensive countermeasures
- D3FEND maps defensive techniques as a formal ontology aligned to ATT&CK.
- Agents can be instructed to monitor, respond to, and escalate using the same vocabulary as the security team.
- Shared ontological language closes the gap between what agents do and what security operators see.
The bridge layer
- ATT&CK and D3FEND are domain vocabularies, not formal ontologies. BFO and CCO provide the semantic layer needed for reasoning, provenance, and AI assurance.
- Aligning the two is work we are close to, with results presented at STIDS 2026 bridging cyber frameworks into the BFO/CCO ecosystem.
- The result: the same semantic spine that governs your data also governs your security, making AI behavior auditable end to end.
Who audits the meaning inside your AI? This is where Forvis Mazars stands apart.
Access control governs who reaches what. The deeper question is whether the AI's semantic foundations are sound. That is an audit problem, and audit is our discipline.
NCOR: the vetting standard
- The National Center for Ontological Research is becoming the authority for vetting semantic structure in AI systems.
- It assesses whether AI is built on sound, interoperable ontological foundations.
- Analogous to financial regulation: independent review of how AI reasons, not just what it outputs.
Audit, consulting, and technology in one
- With NaasAI, we are pioneering a new class of service: vetting semantic knowledge graphs against BFO and standing up an AI platform that supports this auditability by design.
- Jeremy Ravenel, CEO of NaasAI and Senior AI Advisor to Forvis Mazars, is working directly with NCOR to operationalize the standard.
- Forvis Mazars brings audit and advisory rigor; our technology partners deliver it in production.
Pods, long-term commitment, no lock-in
We deploy in pods of three embedded experts: one Forward Deployed Architect, one Forward Deployed Engineer, one Forward Deployed Designer. We start with one pod on a defined perimeter, prove value, then expand scope and pod count at each transition. The audit analogy is our mindset, not a contract clause.
How scope grows
- Package 1: one pod, one process, one perimeter. Prove value.
- Package 2+: scope and pod count re-evaluated at each transition based on delivered outcomes and next priority.
- At scale: multiple pods in parallel, each owning a distinct subsystem or use case.
- You never commit to a team size upfront. The programme grows with confidence.
The audit analogy
- Audit mandates run in long cycles because the subject keeps changing. AI is the same.
- We know how to operate this way: renew, adapt, improve year on year.
- It is our natural operating rhythm, not a constraint we impose on you.
- Duration and scope are negotiated. The mindset is what we bring by default.
No lock-in. You can exit at any time.
The semantic layer we build belongs to you, encoded in open standards (BFO/CCO). You are not buying proprietary software. If you decide to stop, you keep everything: the ontology, the process catalogue, the governance model. The next partner, or your own team, picks up exactly where we left off.
3-month packages: how we start, deliver, and re-assess at every cycle
Guest knowledge modelling
Capture and structure what TPO knows about its guests: likes, preferences, expectations, and dislikes. This forms the guest intelligence layer that feeds every downstream AI use case.
Process knowledge graph
Inventory and map every TPO process discovered during the engagement. A living process cartography used to prioritise tasks, surface gaps, and guide each subsequent package's focus.
Re-assessment and renewal
- Objective review: delivered outcomes are evaluated against the package's stated goals.
- Effort calibration: pod size and composition are re-evaluated based on upcoming priorities.
- Focus re-alignment: a new primary objective is agreed for the next 3-month cycle.
- Built to last: every artefact we produce belongs to TPO, encoded in open standards, ready to grow with the next cycle.
A delivery center approach, proven for air-gapped sovereign environments
Externalized development
- We provision and operate dedicated development mirrored environments on our infrastructure with simulated data.
- All work uses fully sanitized sample data, no production data ever leaves TPO's perimeter.
- Software is built, tested, and validated against agreed specifications before handover.
- Methodology proven through similar sovereign and government engagements.
- Software packages
- Architectural designs
- Deployment runbooks
- Knowledge transfer
Sovereign deployment
- TPO internal teams receive, validate, and deploy all deliverables into the air-gapped environment.
- Sensitive data and production infrastructure remain fully under TPO control at all times.
- No Forvis Mazars access to production systems: clean separation by design.
- Each deployment is verified against the handover specification before going live.
Remote operationalization support
We provide continuous remote support to help TPO teams operationalize each delivered solution: troubleshooting sessions, documentation, configuration guidance, and progressive capability transfer so TPO builds lasting internal expertise alongside each package.
Commercial structure: one delivery pod for the first 3-month package
Outcome based
The pod · 3 embedded experts
- Forward Deployed Architect (DevOps). Models the customer's infrastructure, data flows, and sovereign architecture. Owns the technical blueprint and ensures every component is deployable, observable, and maintainable on the customer's own infrastructure. Covers the technology model.
- Forward Deployed Engineer (Software developer). Builds AI agents, workflows, and integrations. Translates the semantic layer into running systems, connects data sources, and delivers production-ready software handover packages. Covers the operating model.
- Forward Deployed Designer (Product / UX). Designs the customer experience, from project organisation and GitHub workflows to workshops, documentation, and adoption. Ensures the system is understood, adopted, and owned by the customer's teams. Covers the business model.
What we need to align on to move from deck to contract
Six open points that will shape the scope of work and determine the right engagement structure.
Which use case becomes the first 90-day proof point? S2 Intelligence (guest knowledge modelling), S3 Operations, S4 Logistics, or another priority?
Which data perimeter rules apply from day one? What can go to cloud and what must stay on-premise?
What is the current infrastructure posture? Existing GPU, air-gapped environment, Odoo integrations to scope.
Who owns the semantic spine internally? Is there an existing ontology or process catalog to build from?
Who are the internal stakeholders for the pod? IT section, operations, procurement: who is in the room?
What is the decision timeline? Is there a procurement window or internal approval gate we need to work within?
Semantic spine stays yours; vendors accelerate where they fit
Keep terminology, governance, and classification in-house; use vendors when the path aligns.
Semantic spine (yours)
- Your terminology, procedures, process catalog, and governance rules.
- Data classification policy and routing logic.
- How your organization defines roles, access, and audit requirements.
Accelerators (when they fit)
- Managed data platforms (Databricks, Snowflake) when cloud path aligns.
- Security tools matched to infrastructure (DLP, antivirus, identity).
- Upfront fit analysis: vendor highway vs. your national road constraints.
Highway vs. national road
Vendors bring speed and depth, but each carries architecture constraints. A product that only runs on Azure is the wrong choice for a sovereign on-prem path. Analysis before commitment, not after.
Private AI: the hard problems are operational, not theoretical
Compute, isolation, and threat modeling decide whether sovereign claims hold in practice.
Where the models run
- Bare metal vs. virtualized GPU clusters.
- Right people in the right jurisdiction to operate.
- Compliance minimums on GPU and inference stack.
Keeping perimeters separate
- Air-gapped vs. hybrid sovereign patterns.
- Network segmentation between data perimeters.
- Agent sandboxes for untrusted code execution.
Where sovereign claims break
- Attack surface assessment per tier.
- Connectivity audit: paths outside desired jurisdiction.
- Vendor dependency mapping on sovereign claims.
Private architecture operating model checklist
Clear ownership, documented runbooks, and independent alerting in your control plane.
Ownership & ops
- Who owns prod infrastructure: internal, MSP, or hybrid?
- How do you select and audit the managed services partner?
- Does the operator know your applications and dependencies?
- Documented architecture, runbooks, and change control.
Resilience & visibility
- 24/7 support SLA for all production applications.
- Independent monitoring and alerting in your control plane.
- Escalation when the provider fails to act on alerts.
- Regular resilience testing and failover validation.
You cannot do everything locally. That is not a failure of sovereignty.
A hybrid routing strategy lets you keep sensitive workloads sovereign while using large external models for public intelligence. Sovereignty is about routing control, not blanket isolation.
Sovereign workloads
- Personal data, staff records, operational schedules.
- Classified documents and restricted communications.
- Internal process automation and agentic workflows.
- Any inference touching private or jurisdictionally sensitive content.
Public intelligence workloads
- Market intelligence on publicly available data.
- Open-source research, news, and geopolitical signals.
- Heavy compute tasks on non-sensitive inputs.
- These workloads benefit from frontier model capability at low risk.
The semantic spine encodes the routing rules. Every data object carries a classification. The system routes automatically. No human decision required at query time.
Forvis Mazars adapts stack to client constraints
Azure for internal IT; dedicated servers for R&D and client engagements; sovereign options where mission requires.
Infrastructure choice is driven by mission intent, not a single default. Azure covers internal IT operations. Dedicated servers support R&D and client-specific needs. Sovereign and restricted requirements extend to European national clouds and fully on-prem architectures depending on the engagement context.
Azure baseline
Enterprise AI, productivity, and collaboration at scale.
European sovereign
National cloud providers (France, Germany) for residency-sensitive clients.
Client-dedicated
UK-only deployments where cross-border transfer is prohibited.
On-prem sovereign
GPU compute with minimum compliance for restricted workloads.
Match tier to class
Each workload class maps to the lowest-risk tier that still meets operational needs.
BOB current state: 3 interconnected modules in research preview
Three modules sharing a semantic spine on GAIA sovereign infrastructure. Each at a different technology readiness level.
Market Intelligence
Generate structured intelligence on target organizations. Company positioning, market dynamics, competitive landscape, and key strategic challenges. Usable prototype in operational environment.
Relationship Intelligence
Reveal strategic connections across the firm. Who knows who, surface prior interactions, turn relationship knowledge into firm-wide intelligence. Technology validated in beta.
Offering & Engagement Intelligence
Transform proposals into reusable assets. Interactive proposals and client engagement tracking. Every engagement becomes reusable firm intelligence. Prototype deployed in operational environment.
An open-source alternative to Palantir
BOB is built on ABI, an open-source agentic intelligence platform. Jeremy Ravenel, CEO of NaasAI and Senior AI Advisor to Forvis Mazars, bridges both organisations: NaasAI is the technology partner, Forvis Mazars is a contributor and design partner applying the platform internally as proof of practice. The project positions an open, ontology-grounded, sovereign-ready alternative to proprietary platforms like Palantir, running on GAIA compute and grounded in BFO/CCO for interoperability and auditability.
BOB target state: from intent to outcome
The semantic spine connects what the firm knows to what it does. Data flows in, governed intelligence flows out.
Client knowledge graph
Engagement data, service offering, market intelligence, and industry trends unified through a single ontology-grounded knowledge graph.
Sovereign AI in production
Proactive business opportunities, cross-selling signals, and benchmarking. All auditable and reusable across engagements.
Our sovereignty journey: transparency builds trust
Forvis Mazars evolved from owned servers to colocation, then reassessed connectivity and vendor paths.
Forvis Mazars evolved its infrastructure posture as sovereignty requirements became clearer. We moved from owned physical servers to European colocation, then discovered that connectivity paths and vendor dependencies can still create exposure. We are now actively working with European hosting partners to close those gaps.
Owned servers
Physical servers in our own facilities.
European colocation
Scale and resilience through in-region hosting.
Deeper assessment
Connectivity, vendor paths, GPU compliance re-evaluated.
Infrastructure matched to purpose
Azure for internal IT; dedicated servers for R&D and client needs; mission intent drives the choice.
Palantir Technologies
Probably the most visible commercial success story for ontology as operating architecture.
Signal
Palantir is the clearest commercial proof that ontology can become operating architecture, not a documentation layer.
Key points
- Foundry, Gotham, and AIP center work around object types, properties, links, actions, functions, and security controls.
- The ontology connects data, logic, decisions, and system write-back so users and agents operate on shared business objects.
- Its market message turns semantic structure into an operating system for decisions, not a back-office data model.
Evidence
Palantir describes the Ontology as the system at the heart of its architecture and defines core concepts for objects, links, actions, functions, and operational workflows.
Strategic takeaway
Decision systems need a governed model of the business before AI agents can act with confidence.
OBO Foundry
The gold standard for open, interoperable biomedical ontologies.
Signal
OBO shows that ontology value depends as much on governance and reuse discipline as on formal modeling.
Key points
- The Foundry coordinates interoperable biomedical ontologies under shared design principles and community review.
- Ontologies such as ECO encode evidence and conclusions so research claims can be connected and reused.
- The model proves that federated domains can share meaning without collapsing into one central application.
Evidence
OBO publishes open ontology principles and reusable biomedical ontologies, including the Evidence and Conclusion Ontology for representing evidence-backed scientific assertions.
Strategic takeaway
Mature semantic programs need operating rules: ownership, design principles, reuse, versioning, and review.
United States Department of War / DoD and Intelligence Community
A public signal that formal ontology is becoming mission interoperability infrastructure.
Signal
Defense adoption signals that formal ontology is becoming mission interoperability infrastructure.
Key points
- Public reporting states that BFO and CCO were selected as baseline standards for formal ontology work.
- BFO provides top-level categories, while CCO adds reusable mid-level classes for mission-specific domains.
- The target is data sharing, federated search, analytic efficiency, and interoperability across complex mission systems.
Evidence
Public sources describe Basic Formal Ontology and Common Core Ontologies as baseline standards for DoD and Intelligence Community ontology work and as a shared foundation for mission data integration.
Strategic takeaway
Standards have to precede scale when many systems must coordinate under high operational risk.
U.S. Customs and Border Protection / CBP
CBP is building ontology-backed knowledge graphs for live border operations, not just exchange standards.
Signal
CBP proves that ontology can become mission infrastructure when response windows are measured in minutes and many sensor feeds must fuse into one operational picture.
Key points
- Border Patrol leadership is leading an ontology development effort across CBP and DHS for enterprise-wide data integration and knowledge sharing.
- A proof of concept used RDF triples linking sensors, acts of sensing, and unmanned aerial vehicles for real-time mapped airspace during drone interdiction.
- A 30-day test collected 17,000 records meeting time and space criteria for qualified interdiction scenarios at the border.
Evidence
Public reporting from the Data Centric Architecture Forum describes CBP's ontology work and the sensor-to-drone RDF pattern used to give field agents precise, mapped airspace information under operational pressure.
Strategic takeaway
Semantic models pay off when many feeds must fuse into one decision picture and the cost of ambiguity is measured in missed response windows.
National Institutes of Health / NCBO BioPortal
NIH-backed infrastructure has made biomedical ontologies searchable, reusable, and queryable at scale.
Signal
BioPortal shows how ontology becomes useful when it is searchable, mapped, queryable, and exposed as infrastructure.
Key points
- BioPortal aggregates biomedical ontologies in a common repository for lookup, annotation, mapping, and reuse.
- It exposes APIs, mappings, and SPARQL access so ontology assets can feed applications and analysis workflows.
- The case proves that shared meaning needs service interfaces, not only files and stewardship documents.
Evidence
NCBO BioPortal describes itself as a comprehensive repository of biomedical ontologies, with services for search, annotation, mappings, APIs, and SPARQL access.
Strategic takeaway
Semantic assets gain strategic value when they are consumable by platforms, products, analysts, and AI workflows.
NATO research community
NATO research shows ontology as an interoperability tool for coalition command and control.
Signal
NATO research makes the interoperability problem explicit: coalition systems need semantic mediation, not just connectivity.
Key points
- IST-075 and IST-094 explored ontology-based semantic interoperability for heterogeneous command-and-control systems.
- The work covers mediation, model harmonization, service discovery, and translation across tactical abstractions.
- It proves that common meaning matters most when multiple actors must coordinate without one canonical system.
Evidence
NATO research papers document ontology-based approaches for semantic interoperability and tactical service discovery across military networks and command-and-control environments.
Strategic takeaway
Federated operations need a shared semantic layer so local systems can remain different while decisions remain coherent.
Google made knowledge graphs mainstream for entity-centric search.
Signal
Google made the strategic shift visible: understanding entities and relationships beats matching strings.
Key points
- The Knowledge Graph models real-world things and relationships to improve search, panels, answers, and disambiguation.
- It moves retrieval from document-centric matching toward entity-centric understanding.
- The same logic applies inside enterprises where operational entities are scattered across documents and systems.
Evidence
Google introduced the Knowledge Graph as an intelligent model of real-world entities and relationships, commonly summarized as a move toward things, not strings.
Strategic takeaway
AI search and assistants need durable entity understanding before they can produce reliable operational answers.
Microsoft
Microsoft is now making ontology a native enterprise data product concept inside Fabric.
Signal
Microsoft bringing ontology into Fabric shows that enterprise platforms are mainstreaming semantic assets.
Key points
- Fabric IQ positions ontology as an enterprise vocabulary and semantic layer across domains and OneLake sources.
- Documentation covers entity types, properties, relationships, data bindings, graph views, and agent-consumable concepts.
- The platform can generate ontology items from Power BI semantic models, making semantic modeling part of the analytics stack.
Evidence
Microsoft Fabric documentation describes ontology as a way to unify enterprise meaning and generate ontology concepts from existing semantic models.
Strategic takeaway
When platforms consume ontology natively, the strategic question becomes who governs the meaning those platforms inherit.
Amazon Web Services
AWS provides the infrastructure layer for RDF, SPARQL, and enterprise knowledge graphs through Neptune.
Signal
AWS validates graph infrastructure, while also showing that storage capability is not the same as semantic authority.
Key points
- Amazon Neptune supports RDF and SPARQL for knowledge graph workloads alongside property graph use cases.
- AWS guidance shows OWL ontologies loaded into Neptune and paired with reasoning engines such as RDFox.
- The infrastructure enables graph operations, but governance of concepts, constraints, and inference remains an enterprise responsibility.
Evidence
Amazon Neptune documentation covers SPARQL access, and AWS guidance explains how OWL ontologies can be used in model-driven graphs on Neptune.
Strategic takeaway
Cloud graph services can host semantic assets, but they do not decide which meanings are authoritative.
IKEA
A rare public consumer-goods example where ontology and knowledge graph practice directly support product discovery, recommendations, and customer experience.
Signal
IKEA shows that ontology can support commercial experience, not only regulated or scientific domains.
Key points
- Public material describes a three-layer knowledge graph: concepts, categories, and product data.
- The graph supports product discovery, recommendations, search, navigation, APIs, and explainable customer experiences.
- The case proves that semantic structure helps when product context and business rules must travel across channels.
Evidence
IKEA Knowledge Hub and public talks describe how concept, category, and data layers support recommendations and digital experience use cases.
Strategic takeaway
Semantic models become business infrastructure when recommendations and decisions must be explainable, reusable, and channel-independent.
EDM Council FIBO
The most important open financial ontology standard.
Signal
FIBO shows how formal meaning becomes a risk and reporting control in a regulated industry.
Key points
- FIBO defines financial instruments, contracts, entities, indices, derivatives, and regulatory concepts in formal ontology assets.
- The model uses OWL and Description Logic with industry review and standards alignment.
- It proves that shared definitions can reduce ambiguity in reporting, lineage, risk, and entity resolution.
Evidence
EDM Council and FIBO specification pages describe FIBO as a formal financial industry ontology for business concepts and relationships.
Strategic takeaway
Where ambiguity creates financial or regulatory exposure, business meaning needs the same rigor as data quality.
Goldman Sachs / FINOS Legend
A rare public example of a major bank open-sourcing its internal data modeling and governance platform.
Signal
Legend shows that regulated enterprises need business meaning to be modeled, governed, and executable by engineering teams.
Key points
- Goldman Sachs open-sourced Legend through FINOS as a modeling, governance, lineage, and collaborative data platform.
- Legend combines visual modeling, mappings, execution, SDLC, and review workflows for financial data products.
- The case connects semantic modeling directly to delivery discipline, not only architecture diagrams.
Evidence
FINOS public materials describe the Legend case study and Goldman Sachs decision to open-source its data modeling platform through FINOS.
Strategic takeaway
Semantic governance scales when models are versioned, reviewed, mapped, and executable in the delivery workflow.
JPMorgan Chase
A public example of enterprise knowledge graphs used for mission-critical financial applications.
Signal
JPMorgan Chase shows that entity resolution becomes core infrastructure when decisions depend on noisy text and internal identifiers.
Key points
- Publications describe knowledge graphs used for risk assessment, fraud detection, investment advice, and financial news linking.
- JEL links company mentions in text to entities in an enterprise company knowledge graph.
- The case proves that graphs are valuable when they connect unstructured evidence to governed enterprise entities.
Evidence
JPMorgan Chase publications on JEL describe financial-news entity linking against a company knowledge graph and broader enterprise knowledge graph applications.
Strategic takeaway
High-value decisions require entity resolution that connects documents, events, and enterprise-specific objects.
Gene Ontology Consortium
The early proof that scientific knowledge needs shared computable meaning.
Signal
Gene Ontology is the early proof that scientific knowledge needs shared computable meaning before large-scale analysis works.
Key points
- GO provides controlled terms for gene functions, biological processes, and cellular components across organisms.
- The knowledgebase combines evidence-supported annotations with GO-CAM models that connect annotations into pathways.
- The case established the pattern of identifiers, evidence, relations, and curation before analytics.
Evidence
Gene Ontology public resources and the 2023 knowledgebase paper describe a computable structure for gene function, evidence-backed annotations, and biological models.
Strategic takeaway
Reusable knowledge depends on stable identifiers, evidence codes, relationships, and sustained expert curation.
Open PHACTS
A landmark public-private semantic web initiative for drug discovery.
Signal
Open PHACTS showed that drug discovery needs answerable cross-domain questions, not isolated datasets.
Key points
- The initiative integrated compounds, targets, diseases, tissues, pathways, and public drug-discovery databases.
- It used semantic web technology, APIs, and query mechanisms to help researchers traverse related evidence.
- The case demonstrates why domain questions should drive graph design.
Evidence
IHI project materials and the Open PHACTS triple store paper describe a semantic platform for integrating pharmacological data and answering complex drug discovery questions.
Strategic takeaway
Semantic infrastructure should be judged by the cross-domain questions it makes answerable.
AstraZeneca
A strong public example of an internal pharma knowledge graph for drug development.
Signal
AstraZeneca shows how competitive knowledge graphs combine public science, internal evidence, and machine learning readiness.
Key points
- BIKG integrates public, licensed, proprietary, and literature-extracted biological data for drug development.
- The graph connects genes, proteins, diseases, compounds, NLP pipelines, and ontology alignment.
- Kazu documentation shows the adjacent need for entity recognition and normalization in scientific text.
Evidence
AstraZeneca public materials describe BIKG as an internal Biological Insights Knowledge Graph and Kazu as tooling for biomedical entity recognition and normalization.
Strategic takeaway
The strongest knowledge assets connect external evidence, internal data, text extraction, and governed graph structure.
Roche
A mature pharma example of FAIR data, semantic hubs, and ontology-backed interoperability.
Signal
Roche shows that ontology can become data-governance plumbing for large scientific operations.
Key points
- Public sources describe RDF, RDFS, OWL, community vocabularies, BFO-aligned models, and semantic harmonization.
- The FAIR approach connects metadata, terminologies, domain ontologies, application models, and productive applications.
- The case proves that interoperability requires design discipline before data is consumed by downstream platforms.
Evidence
Roche FAIR data by design material and the FAIR in vivo platform paper describe ontology-backed data harmonization for life sciences knowledge graphs.
Strategic takeaway
FAIR data becomes operational only when metadata, terms, models, applications, and governance are designed together.
Novartis
A visible drug-discovery knowledge graph case using biomedical entities and literature evidence.
Signal
Novartis is a clean public example of experts traversing evidence relationships instead of searching isolated repositories.
Key points
- Public case studies describe a graph connecting genes, diseases, compounds, text-mined literature, historical data, and image-derived data.
- Researchers use the graph to evaluate relationship strength and identify promising compounds or disease hypotheses.
- OntoBrowser adds evidence of ontology tooling around open-source science and browsing.
Evidence
Neo4j and Novartis public sources describe drug discovery knowledge graph use cases and the OntoBrowser project for working with biomedical ontologies.
Strategic takeaway
Experts need connected evidence paths that reveal why an answer is plausible, not only where a document is stored.
Pfizer
A visible pharma example of semantic integration, ontologies, and knowledge graph AI.
Signal
Pfizer reinforces the pattern: the higher the cost of scientific ambiguity, the more valuable governed semantic integration becomes.
Key points
- Public sources describe data standards, vocabularies, ontologies, linked data, and an intelligent data framework.
- Recent public material describes biomedical knowledge graphs with Data4Cure for continuously updated scientific insight.
- The work connects literature, identifiers, compounds, disease areas, public data, and internal data for drug discovery.
Evidence
Bio-IT World and Drug Discovery Online sources describe Pfizer semantic integration work and knowledge graph collaboration for AI and data-driven discovery.
Strategic takeaway
Semantic integration matters most when evidence is fragmented and the cost of a wrong interpretation is high.
DARPA
The historical bridge between early semantic web research and defense needs.
Signal
DARPA explains why defense communities saw semantic interoperability early: autonomous systems need explicit meaning.
Key points
- DAML aimed to make web information machine-readable through semantic annotations and ontologies.
- The program created transition paths to military command-and-control and intelligence activities.
- DAML and DAML+OIL influenced OWL and later ontology and knowledge graph standards.
Evidence
DAML.org and the DAML BAA describe early semantic web work focused on machine-readable information and defense-relevant transition paths.
Strategic takeaway
Agentic and autonomous systems increase the value of explicit semantics because machines act on representations.
Boeing
A public aerospace example where semantics support model-based systems engineering and lifecycle data.
Signal
Boeing makes the aerospace analogy concrete: lifecycle decisions require shared meaning across parts, requirements, and evidence.
Key points
- Public sources describe semantic capabilities for MBSE, aircraft data hierarchy, impact analysis, and lifecycle consistency.
- The work connects parts, requirements, engineering data, system models, and analysis workflows.
- The case maps closely to asset-intensive operations where versions, safety, and maintenance evidence matter.
Evidence
MarkLogic and Boeing public repositories describe semantic support for model-based systems engineering and aircraft data hierarchy work.
Strategic takeaway
Complex assets need one governed model of reality across design, operations, maintenance, safety, and change impact.
Airbus Skywise
The clearest public aviation platform example of ontology-backed operational data integration.
Signal
Skywise shows ontology becoming operational when it is embedded into fleet, maintenance, and equipment workflows.
Key points
- Airbus launched Skywise with Palantir to integrate aviation data across airlines and operational use cases.
- Developer documentation exposes ontology APIs for aircraft, parts, events, maintenance, and work packs.
- The platform supports predictive maintenance, disruption reduction, fleet operations, and analytics over aviation data.
Evidence
Airbus public launch material and Skywise developer documentation describe an aviation data platform with ontology APIs for operational entities and workflows.
Strategic takeaway
Ontology becomes strategic when it is wired into operational workflows where asset context changes decisions.
The Open Group OSDU
The energy sector's clearest open data-standardization move.
Signal
OSDU is the energy sector proof point that data standardization is now a shared platform concern.
Key points
- OSDU provides an open-source, standards-based, technology-agnostic data platform for energy data.
- Public ontology work converts OSDU schemas into OWL/RDF, moving schema standardization toward formal semantics.
- The case is necessary infrastructure, but it does not replace enterprise-level concept governance.
Evidence
OSDU Forum and OSDU Ontology public materials describe common energy data platform standards and ontology conversion work over OSDU schemas.
Strategic takeaway
Sector standards help align platforms, but enterprises still need to govern the meanings that drive decisions.
Equinor
A public operator example of ontology-based access and contextualized industrial data.
Signal
Equinor shows the energy operator bottleneck clearly: finding trusted data can be harder than analyzing it.
Key points
- Public research describes ontology-based data access for exploration data at Equinor.
- OmniaPlant principles publish contextualized industrial data through open APIs for plant and operational data.
- The work connects geologists, timeseries metadata, plant context, and industrial applications.
Evidence
SINTEF publication material and Equinor OmniaPlant describe ontology-based data access and contextualized industrial data APIs.
Strategic takeaway
Discovery improves when operational data is exposed through governed context, not only stored in more repositories.
Cognite
A market-facing industrial knowledge graph platform used in energy and process industries.
Signal
Cognite validates industrial knowledge graphs as a market category, especially for asset-intensive operations.
Key points
- CDF contextualizes asset, timeseries, document, 3D, maintenance, and process data.
- Cognite publishes core and process industry data models for assets, equipment, timeseries, maintenance orders, and notifications.
- The case proves industrial platforms want semantic structure, while formal authority still has to span all platforms.
Evidence
Cognite public materials describe an industrial knowledge graph and process industry data models for contextualized asset and operations data.
Strategic takeaway
Industrial platforms can operationalize knowledge graphs, but enterprise meaning should remain governed above any single platform.
The market uses similar words for different layers. The winners increasingly combine them.
Analytics
Defines business metrics, reporting logic, dimensions, and reusable calculation meaning.
Discovery
Documents data assets, ownership, lineage, quality, access, and governance responsibilities.
Relationships
Connects entities, events, documents, and facts so systems can traverse operational context.
Meaning
Defines entity types, relations, identifiers, definitions, constraints, rules, and intended interpretation.
Grounding
Gives AI agents approved concepts, context, provenance, and action boundaries.
Observation
The strategic infrastructure is not one tool. It is the governed connection between meaning, evidence, systems, and AI execution.
Semantic authority is not the same as platform capability.
What platforms can do
- Integrate data.
- Visualize workflows.
- Query graphs.
- Automate actions.
- Support AI search and agents.
What the enterprise must own
- Authoritative identifiers.
- Approved definitions.
- Relations and constraints.
- Mappings and provenance.
- Validation and inference expectations.
Internal strategic assessment
A platform object model, property graph, schema, dashboard, or AI summary may support operations. It does not automatically prove that enterprise meaning is preserved, governed, exportable, or reusable outside the platform.
Decision rule
Operational acceptance should not be confused with semantic acceptance.
Evaluate semantic claims by evidence, not terminology.
What model is authoritative?
There must be a designated model for enterprise meaning, with ownership, scope, and version control.
Can it leave the platform?
Definitions, identifiers, relations, constraints, mappings, and provenance must be inspectable, exportable, reconstructable, and reusable.
What semantic loss is accepted?
Derived products may omit detail when needed. They should not contradict, redefine, or silently drift from approved meaning.
Executive test
If the enterprise cannot inspect, govern, validate, export, and reuse its meaning outside a vendor system, it does not yet control its semantic infrastructure.
Semantic lock-in is the next vendor lock-in.
What leaders already recognize
- Infrastructure dependency.
- Data residency.
- API coupling.
- License and switching cost.
What AI makes more dangerous
- Meaning embedded in object models.
- Relationships hidden in platform logic.
- Rules buried in workflows.
- Agent context controlled by vendors.
Why it matters
If enterprise meaning exists only inside a platform, future migration becomes semantic rework. AI increases the risk because agents act on hidden context, not only visible data.
Strategic position
Vendors should compete to operationalize meaning, not to own or redefine it.