A concern has been building for me as enterprises accelerate their adoption of AI. Note, I say adoption, not transformation. I’ll discuss the difference in my next article.

The public conversation keeps returning to model selection: which model reasons better, costs less, supports a particular workflow, and should sit behind an application or agent. Those decisions matter, especially as model marketplaces and routing layers make model choice more fluid. Model selection is useful when the enterprise understands the meaning the model is being asked to operate on.

A foundation model arrives with knowledge learned from the world. It has absorbed patterns from public text, human-generated content, code, documents, labeled examples, feedback signals, and countless descriptions of reality. Some of those signals are explicit labels created by people. Others are created through the training process itself, where the model learns by predicting missing or next tokens across enormous bodies of text. Later, human feedback, ranking, annotation, evaluation, and alignment further shape what the model learns to prefer, avoid, emphasize, and reproduce.

That capability is remarkable. It gives the model general understanding, language fluency, and reasoning capacity across broad domains. It also means the model carries meaning shaped by many sources: public data, human judgment, labeling practices, evaluation criteria, and feedback loops.

Inside the enterprise, the model may understand what a customer, account, policy, risk, claim, transaction, relationship, or exception means in general language. It does not automatically carry the enterprise’s definitions, ownership structures, process context, restrictions, exception logic, regulatory obligations, or decision rights. Those meanings are institutional. They live inside the organization’s operating model, business history, control environment, and accumulated judgment.

When that meaning remains implicit, AI infers. It infers from available documents, data, prompts, historical outputs, and surrounding context. Sometimes that inference is useful. Sometimes it introduces the wrong meaning with confidence, fluency, and speed.

Enterprise AI risk begins there.

The hidden meaning problem behind hallucination/error

AI hallucination (which is simply an error) is often discussed as a model-layer issue. Models can fabricate facts, overstate certainty, misread context, and generate polished answers that sound plausible while lacking grounding. That risk is real, and enterprises need model evaluation, monitoring, and controls to manage it.

In enterprise settings, another failure pattern deserves equal attention. A model may be asked to reason over unclear data, inconsistent definitions, stale documentation, contradictory business rules, or concepts that humans understand only because they have lived inside the organization long enough to absorb its contradictions. In those cases, the enterprise has handed AI something it cannot safely interpret.

This is where the enterprise AI conversation becomes too narrow. Model cards, data sheets, training data, evaluation, human feedback, RAG, prompt engineering, and governance controls all matter. The deeper enterprise problem lies beneath those practices: AI systems need context that explains the meaning of the information they are asked to use.

That context includes where meaning came from, which domain owns it, where it applies, where it is restricted, where the same term carries a different meaning, and which interpretation governs a specific workflow or decision. Without that context, AI operates on inference rather than enterprise truth.

Human judgment is already inside the system

AI is shaped by human judgment long before it reaches the enterprise.

Even when a model is trained through self-supervised learning, it learns from human-created material. The internet, books, policies, documents, code, conversations, and institutional artifacts all carry assumptions. They carry omissions, biases, histories, cultures, incentives, and power. The model learns from the accumulated record of how humans have described reality.

Later stages of model development make that judgment more explicit. People compare answers. They rank outputs. They decide what is helpful, safe, correct, aligned, acceptable, or preferred. Those choices shape model behavior and reinforce patterns the system learns to reproduce.

The model learns language and accumulates human meaning.

That is powerful. It is also messy. If labels are inconsistent, the model can absorb inconsistency. If feedback is narrow, the model can absorb narrowness. If the data is uneven, the model can learn the unevenness. If evaluation rewards polish over truth, the model can become more persuasive than accurate.

AI becomes a mirror of the systems that teach it.

Enterprises should care deeply about this because their internal systems are already rife with hidden judgment. A KPI is a business definition expressed as a number. A label is a human decision about what something is. A workflow is a representation of how responsibility moves. A policy is a boundary. A dashboard is an expression of what the enterprise considers important enough to measure.

AI makes those hidden judgments operational at machine speed.

Semantic explainability comes before model explainability

Model explainability remains important. Enterprises need to understand model behavior, limitations, performance boundaries, and failure modes. Semantic explainability comes earlier in the chain because the model’s output is shaped by the meaning embedded in the data, context, and instructions it receives.

Semantic explainability is the enterprise’s ability to explain what its concepts mean, where those meanings came from, who owns them, where they apply, where they are restricted, and how they should be interpreted in a specific business context.

It includes the meaning of critical data elements, the business processes that give those elements context, the ownership structures that govern them, and the differences that appear when domains use the same term in different ways. It also includes the enterprise’s ability to distinguish errors from legitimate domain distinctions and temporary exceptions from durable business meaning.

This discipline extends beyond cataloging data. A catalog can identify that a field exists. A glossary can provide a definition. A lineage tool can show movement. A governance workflow can assign an owner. Those capabilities are useful, but they do not automatically tell AI what the enterprise means.

Humans can operate with implicit meaning because humans fill in blanks. Experienced people know that the same word can mean different things in different meetings. They know which report is trusted and which one is decorative. They know which exception is real and which one is noise. They know when a policy is interpreted strictly and when it is interpreted practically. They know where formal authority and operational reality diverge.

AI does not inherit that institutional intuition. The enterprise has to make it explicit.

Semantic coherence preserves legitimate differences

Semantic coherence requires visibility, explanation, and governance across meaning. It does not require one universal definition everywhere.

Complex enterprises often contain legitimate differences in meaning across domains. A customer may mean something different to sales, servicing, risk, finance, and reporting. An account may mean one thing in billing and another in investment operations. A relationship may be legal, operational, household-based, advisor-based, platform-based, or regulatory, depending on context.

The goal is to make those differences visible, explainable, and governable.

This matters because many enterprise meaning conflicts are not errors. They are signs that different domains operate with different scopes, responsibilities, obligations, and decision contexts. Flattening those differences can create new risks. Leaving them implicit creates another form of risk. The enterprise needs a way to preserve legitimate domain meaning while creating enough coherence for AI to reason safely across boundaries.

That is where the meaning problem becomes a production problem. Once AI enters the operating environment, unclear definitions and hidden domain differences no longer remain passive documentation issues. They become active inputs into recommendations, summaries, workflows, decisions, and evidence.

A recommendation can become a summary. A summary can become a task. A task can become an action. An action can become evidence. At every handoff, meaning can drift unless the enterprise deliberately keeps it attached to the work.

Agentic AI raises the stakes

Agentic AI makes semantic drift more consequential because the enterprise is no longer managing a single prompt and a single answer. It is managing chains of interpretation. AI hands off work, summarizes it, routes it, combines it, and creates the next step. One agent’s output can become another agent’s input.

As agentic systems expand, meaning has to travel with the work. A customer definition used by one agent cannot quietly shift when another agent uses the output downstream. A risk category used in one context cannot become a general label without its original scope. A recommendation grounded in one domain cannot become an action in another domain without the relevant interpretation, boundaries, and evidence.

This is a control issue. It is also an enterprise identity issue.

An enterprise has an identity, whether it has articulated it or not. That identity lives in definitions, ownership structures, decision rights, accountability, standards, controls, workflows, metrics, and institutional memory. AI forces that identity to become machine-readable.

When the enterprise does not define itself, AI infers. It infers from documents, data, prompts, past decisions, historical outputs, and whatever context is available. That is a fragile way to scale intelligence across an operating environment.

The stronger the model, the more serious this risk becomes. A weak model may fail loudly. A strong model can produce polished, confident, coherent output even when the meaning is unclear. That is harder to detect because it looks right. In enterprises, “looks right” can become the beginning of an expensive mistake.

This is where experience still matters. People who have spent years inside complex organizations understand that the visible process is rarely the whole process. They know where exceptions live. They know where rules are interpreted. They know where ownership is formal and where ownership is practical. They know that the hard part is often the context around the task.

AI can accelerate work. It cannot replace the need to understand what the work means.

The governance field is already moving in this direction

The broader AI governance field already points toward this reality. Dataset documentation emphasizes the need to describe motivation, composition, collection, intended use, and maintenance. Model documentation emphasizes intended use, limitations, evaluation conditions, and performance boundaries. Data statements for language systems highlight context, inclusion, bias, and representativeness. Data-centric AI shifts attention toward data and label quality rather than treating model tuning as the only path to better performance.

Human feedback research reinforces the same point from another angle. Human judgment shapes what AI systems learn to prefer, avoid, emphasize, and reproduce. Risk management frameworks increasingly emphasize context, lifecycle controls, accountability, monitoring, governance, and distributed responsibility across the system. Agentic AI security guidance is drawing increasing attention to data poisoning, excessive agency, sensitive information disclosure, supply chain exposure, and unsafe actions based on manipulated or misunderstood context.

The pattern is clear. AI trust depends on the system around the model: data, meaning, documentation, governance, human judgment, operational context, and decision controls. Output-level evaluation remains necessary, but enterprise trust begins earlier.

It begins with whether the organization can explain what it gave the model to understand.

The leadership discipline ahead

The next phase of enterprise AI requires a discipline of meaning governance.

Leaders need visibility into the critical concepts AI must understand before it can support a process; the data elements that carry those concepts; the definitions that are certified or disputed; the meanings that remain local; and the meanings that require enterprise-level reconciliation.

They also need to know what context must accompany data when AI consumes it, what meaning must accompany an output when one agent passes work to another, which interpretations are permitted for a given use case, which differences require escalation, and which decisions require evidence.

These requirements may appear slower than deploying a model. They are the work that allows AI to scale safely.

The real risk is that enterprises move quickly on top of what they have never made explicit. That is how AI scales confusion. It scales inconsistency. It scales assumptions nobody surfaced. It scales the fuzzy parts of the enterprise, turning them into machine behavior.

The model learned from the world. The enterprise must teach it what is true here.

This requires an enterprise-owned meaning foundation strong enough to guide AI in business contexts. For drafting, summarizing, searching, and low-risk productivity, broad model knowledge may be sufficient. For business processes, decisions, customers, risk, operations, controls, reporting, and agent-to-agent execution, enterprise meaning has to travel with the work.

The enterprise must be able to explain its own meaning. AI explainability begins before the model responds.

It begins with whether the enterprise can explain what it asked the model to understand.

Light research grounding

A few foundational research and governance streams support this direction:

• Dataset documentation, including work on datasheets for datasets, emphasizes the need to document motivation, composition, collection, intended use, and maintenance.

• Model documentation, including model cards, emphasizes intended use, limitations, evaluation conditions, and performance boundaries.

• Data statements for NLP highlight the importance of documenting language data to address bias, exclusion, and context.

• Data-centric AI emphasizes improving data quality, label quality, relevance, and representativeness rather than treating model tuning as the only path to better performance.

• Human feedback research, including RLHF, reinforces that human judgment shapes model behavior.

• AI risk management frameworks increasingly emphasize context, lifecycle controls, accountability, monitoring, and governance across the system.

• Agentic AI security guidance increasingly highlights risks around data poisoning, excessive agency, sensitive information disclosure, and unsafe action based on manipulated or misunderstood context.

Together, these streams point toward the same conclusion: trusted AI depends on the system around the model, including the enterprise’s ability to explain its own meaning.

Subscribe now

Leave a comment

(Please check out AI Acquisition Impact Details, its eye-opening)

The recent wave of AI acquisitions can look like a list of isolated vendor moves. I see something more structural. The market is quietly assembling the enterprise AI operating stack.

Each deal tells us which layer of enterprise control is becoming valuable: semantic meaning, real-time data, runtime security, workflow execution, observability, and infrastructure. These are the layers that determine whether AI can operate within an enterprise with the right context, boundaries, evidence, and accountability.

That is why I organized the deals by operating layer rather than buyer, valuation, or product category. The result is a holistic view of the market’s impact and what enterprises should protect as AI becomes part of daily operations.

Some transactions in the table are completed, and some were announced as definitive agreements. The pattern matters more than the status of any single deal. AI value is moving toward the parts of the enterprise that make intelligence usable, governed, and specific to the institution.

The holistic operating-layer view

The acquisition wave is becoming a map of the enterprise operating stack

The old AI narrative centered on the model race. The market is still investing in models, but the acquisition pattern shows a broader move toward the operating conditions around models. Buyers are reaching for the layers that make AI work in production: governed data, business meaning, workflow context, secure runtime behavior, telemetry, and cloud infrastructure.

For enterprises, this shift is important because the real constraint is rarely the model alone. Large organizations need confidence that AI will use the correct context, respect policy boundaries, capture evidence, and remain usable when platforms change. Acquisitions can strengthen those conditions. They can also move more of the enterprise’s identity into someone else’s platform.

This is the core enterprise question behind the acquisition wave: who controls the context AI uses when it acts?

See the comprehensive list of 2025 & 2026 AI-related acquisitions, what is consolidated, and the potential Enterprise impact.

AI Acquisitions and Impact Table

Meaning is moving upstream

The clearest signal is the semantic layer. NVIDIA’s acquisition of illumex is significant because illumex was built around the Generative Semantic Fabric, which turns enterprise knowledge into AI-ready, context-rich business language embedded in semantic ontologies. This is not a peripheral data capability. It is semantic infrastructure. It matters because generic AI cannot reliably operate inside a business without understanding how that business defines customer, product, risk, policy, obligation, exception, and ownership.

Meaning is becoming a strategic layer. The enterprise that cannot define its own meaning will gradually inherit meaning from vendors, applications, models, and workflow tools. That may feel efficient in the short term, but it creates long-term convergence. If many enterprises use the same platform defaults to define work, risk, customers, and decisions, their operating logic begins to look the same.

This is where DSIL™ becomes central. DSIL is my framework for making enterprise meaning, rules, scope, decision rights, and ownership machine-readable and enterprise-owned. The acquisition wave reinforces the need for that layer because the market is already trying to package context.

Data foundations are becoming AI foundations

Databricks acquiring Tecton, Salesforce acquiring Informatica, IBM moving to acquire Confluent, and Salesforce acquiring Waii all point to the same reality. AI needs governed, fresh, accessible, and interpretable data. Data infrastructure is becoming AI infrastructure.

These deals matter because the enterprise AI experience depends on whether the system can access the right data at the right time with the right meaning and the right permissions. Real-time feature serving, data integration, metadata, streaming, natural-language querying, and data governance are moving closer to agentic workflows.

The enterprise impact is structural. Better data foundations can reduce broken workflows, stale context, manual reconciliation, and fragmented decision logic. The consumer impact is usually indirect: fewer errors, faster service, better personalization, and smoother digital experiences. The sovereignty question is direct: can the enterprise attach its own policy, lineage, semantic status, quality expectations, and usage rights to data as it moves?

Security is becoming runtime governance

The security deals are equally important. Cato acquiring Aim Security, F5 acquiring CalypsoAI, Check Point moving to acquire Lakera, CrowdStrike acquiring Onum, Palo Alto acquiring Chronosphere, and Google completing the Wiz acquisition all show that AI production requires more than access control. It requires runtime governance.

Once AI touches sensitive data, workflows, decisions, code, cloud environments, or external systems, controls need to operate where action happens. Prompt protection, agent guardrails, inference-layer security, telemetry pipelines, observability, and cloud security become part of the AI operating model.

This is a major shift for enterprise governance. Policies written in documents are no longer enough. Enterprises need enforceable rules, escalation paths, approval thresholds, evidence capture, and kill paths that can operate at runtime. DSIL defines the enterprise-owned source of those rules. Security and observability platforms can help enforce them, but the enterprise still needs to own the logic.

Workflow AI is where employees feel the shift

Workflow acquisitions show where AI becomes visible in daily work. Salesforce acquiring Bluebirds, Workday acquiring Sana, OpenAI acquiring Statsig, Atlassian acquiring The Browser Company, Atlassian acquiring DX, and Capgemini acquiring WNS all sit close to work execution.

This is where AI stops being a side tool and becomes part of how people prospect, learn, search, test, browse, measure engineering work, and run operations. The immediate experience is often employee-facing, but the enterprise impact runs deeper. Workflow AI changes role boundaries, decision handoffs, action scope, and accountability.

Every workflow acquisition should trigger an operating-model review. What data can the workflow agent access? What actions can it take? When does a human need to review? Which outcomes belong to the employee, the manager, the system owner, or the vendor? How will the enterprise know when the workflow has changed enough to require new governance?

Observability is becoming the trust layer

Observability is often treated as a technical category, but in an AI-enabled enterprise, it becomes a trust layer. Palo Alto’s Chronosphere acquisition and Cisco’s NeuralFabric acquisition show two sides of the same shift: enterprises need to see what AI systems are doing, and they need platforms that can operate against domain-specific enterprise context.

AI without evidence creates operational fragility. If a model gives a recommendation, an agent takes an action, or an automated workflow changes a business outcome, the enterprise needs a record of what happened. It needs to know which context was used, which policy applied, whether a human reviewed the action, and which downstream systems were affected.

Telemetry alone is insufficient. Observability provides signals. Enterprise governance determines which signals count as evidence, which events require escalation, which records must be retained, and which patterns indicate drift.

Infrastructure is now part of the AI governance surface

Infrastructure deals such as Google acquiring Wiz and Qualcomm acquiring Arduino show that AI is moving into cloud security, edge devices, robotics, and physical operating environments. The infrastructure layer increasingly determines where AI can run, how fast it can respond, how secure it is, and how much control the enterprise keeps over data and execution.

This matters because governance cannot stop at the application layer. As AI moves across cloud, edge, and devices, enterprise policy has to travel with it. Data residency, key ownership, access control, runtime security, and auditability become part of the same design conversation as model capability and workflow automation.

The infrastructure question is practical: can the enterprise preserve its own rules when the runtime moves?

What enterprises should do now

Enterprises should treat AI acquisitions as signals about the operating model, not isolated vendor news. Every acquisition should be mapped to a control layer: meaning, data, security, observability, workflow, or infrastructure. That map should show which enterprise capability is being strengthened, which dependency is increasing, and which governance obligation needs updating.

The enterprise should also define its own machine-readable source of truth for meaning, policy, scope, decision rights, ownership, escalation, evidence, and lifecycle status. In my work, that layer is DSIL™. CAIO ownership gives that layer an accountable steward, and runtime governance turns it into an enforceable practice.

The goal is not to avoid vendors. The goal is to use vendors without surrendering the enterprise’s identity. Enterprises can and should buy powerful platforms, but they need portability, exportability, semantic clarity, auditability, and policy continuity. Otherwise, every acquisition in the vendor market becomes a silent acquisition of part of the enterprise’s operating logic.

Closing view

The AI acquisition wave is revealing the next competition in enterprise technology. The valuable layer is no longer just model capability. The valuable layer is the context that makes AI institution-specific.

The companies that understand this will evaluate acquisitions differently. They will ask what layer of the enterprise operating stack is being absorbed. They will ask whether the deal strengthens enterprise control or increases dependency. They will ask whether their own meaning, policy, decision rights, and evidence remain portable.

AI is turning enterprise sovereignty into a design problem. The enterprise that can define itself clearly, govern itself at runtime, and preserve its own context across vendors will be able to scale AI without losing institutional identity.

That led me to look more closely at current AI regulation and guidance.

Regulation may arrive later. The operating discipline for trusted AI adoption is needed now.

I started looking at current AI regulation and guidance. The EU AI Act contains a provision that every enterprise AI leader should understand, even if their company does not operate in Europe.

Article 27 requires certain deployers of high-risk AI systems to conduct a Fundamental Rights Impact Assessment before first use. In plain English, it asks organizations to examine how an AI system could affect people, which groups may be impacted, what harms could occur, what human oversight exists, and what safeguards or complaint mechanisms are in place. The obligation is tied to the model in a real operating context: the process, the affected people, the oversight structure, and the organization’s responsibility for the outcome. (AI Act Service Desk)

That distinction matters.

A model does not affect people in isolation. It affects people when it enters a hiring process, a claims workflow, a credit decision, a benefits determination, a health triage process, an underwriting model, a fraud review, a customer service escalation, or an internal prioritization system. The risk lies in the relationship among the algorithm, the data, the workflow, the decision rights, the human review process, and the institutional logic surrounding it.

The United States does not currently have a broad federal equivalent to Article 27 for private-sector AI deployment. We have sector laws, civil rights laws, consumer protection enforcement, privacy rules, employment rules, credit rules, biometric laws, public-sector AI guidance, voluntary frameworks, and a rapidly expanding state-by-state patchwork. We do not have a single clear federal requirement that requires private-sector organizations to assess high-impact AI before deployment, document the safeguards, and make the decision context explicit.

That gap creates more than a compliance issue. It creates an adoption issue. AI transformation is another topic, but for now lets talk about adoption.

Experimentation is moving. Production is harder.

One reason the conversation about AI adoption feels confusing is that the word “adoption” is doing too much work.

A company can give employees access to AI tools. A team can build prototypes. A vendor can demo a compelling solution. A business unit can test an agent in a sandbox. A data science team can develop a model in a controlled environment.

That is experimentation.

Enterprise adoption begins when AI becomes part of a real operating workflow. It begins when the system touches production data, influences a decision, triggers an action, interacts with a customer, supports an employee, changes a process, or becomes embedded in how work gets done.

That move from sandbox to production is where many organizations slow down.

The reason is rarely technical readiness alone. It is often a matter of unresolved ownership and accountability.

The organization has to know who owns the output, who approves the use case, who is accountable if the recommendation is wrong, who decides whether AI can influence a customer, employee, patient, applicant, claimant, advisor, or citizen, who defines the data standard, who determines the level of human oversight, who monitors drift or harm after launch, and who has the authority to pause or shut down the system.

When those answers are missing, pilots multiply while production adoption slows.

This helps explain why AI activity can look high while scaled enterprise impact remains harder to achieve. McKinsey’s 2025 State of AI research reported that 88 percent of respondents said their organizations regularly use AI in at least one business function, while the majority remained in experimenting or piloting stages at the enterprise level. Approximately one-third reported that their companies had begun to scale AI programs. (McKinsey & Company)

The gap between usage and scale is where I want to focus now.

Regulatory gaps slow trusted implementation

A lack of regulation is often described as innovation-friendly. In some ways, it is. It gives companies room to experiment, test tools, explore vendor capabilities, and move before formal rules are written.

Enterprise implementation has a different threshold. AI scales when leaders trust the operating conditions around it. They need to know what the system is allowed to do, which data it can use, what decisions it can influence, what oversight is required, who owns the outcome, what evidence will be retained, and how harm or challenge will be handled.

When regulation is unclear, those answers become internal debates.

Legal teams evaluate discrimination, privacy, employment, credit, consumer protection, and reputational exposure. Compliance teams evaluate whether existing controls are sufficient. Risk teams evaluate monitoring and escalation. Product teams ask what can launch. Business teams ask why the movement is slow. Technology teams ask for standards that have not been defined.

This is where regulatory ambiguity creates drag. Pilots can continue, while trusted production slows.

The U.S. patchwork adds another layer of complexity. In the 2025 legislative session, all 50 states, Puerto Rico, the Virgin Islands, and Washington, D.C. introduced AI-related legislation, and 38 states adopted or enacted around 100 measures. (NCSL)

For a national enterprise, AI adoption must account for different rules across states, sectors, use cases, data types, affected populations, and business processes. Every AI initiative carries its own interpretation burden unless the organization creates a unifying internal framework.

The U.S. approach is emerging in fragments. Some states are addressing deepfakes. Some are focused on automated employment decisions. Some are moving through consumer privacy and profiling rights. Some are targeting biometric data, political ads, nonconsensual intimate images, government use, health care, or sector-specific automated decisioning.

Federal agencies have their own direction. OMB M-25-21 applies to federal agencies' use of AI and promotes responsible AI adoption while maintaining safeguards for privacy, civil rights, and civil liberties, as well as risk mitigation. (The White House)

That matters for government use. The private-sector enterprise problem remains.

The private sector is left with a familiar pattern: innovate quickly, interpret fragmented obligations, manage vendor pressure, respond to emerging enforcement, and build internal governance while adoption is already underway.

This sequence creates avoidable friction. Governance arrives after experimentation has spread. Risk teams are pulled in when a prototype is ready for production. Legal teams are asked for approval without a stable operating model. Business teams want speed, but the organization cannot always explain who owns the AI-enabled outcome.

This is why some AI programs stall at the exact moment they should become useful.

The prototype works. The business value is visible. The model may be strong enough. The missing piece is the enterprise’s ability to own the operating consequences. The U.S. approach is fragmented by design. I included a companion state-by-state working table (see attachment below) for readers who want to see how uneven the current U.S. AI protection landscape is. The table is not legal advice, but it shows why enterprises need internal operating discipline while regulation remains fragmented.

In the U.S., AI protection is emerging in fragments. Some states are addressing deepfakes. Some are focused on automated employment decisions. Some are moving through consumer privacy and profiling rights. Some are targeting biometric data, political ads, nonconsensual intimate images, government use, health care, or sector-specific automated decisioning.

Federal agencies have their own direction. OMB M-25-21 applies to federal agencies' use of AI, not private-sector AI, to promote responsible AI adoption while maintaining safeguards for privacy, civil rights, and civil liberties, and for risk mitigation. (The White House)

That matters for government use. It does not solve the private-sector enterprise problem. The private sector is left with a familiar pattern: innovate quickly, interpret fragmented obligations, manage vendor pressure, respond to emerging enforcement, and build internal governance while adoption is already underway.

This sequence creates avoidable friction. Governance arrives after experimentation has spread. Risk teams are pulled in when a prototype is ready for production. Legal teams are asked for approval without a stable operating model. Business teams want speed, but the organization cannot always explain who owns the AI-enabled outcome.

This is why some AI programs stall at the exact moment they should become useful.

The prototype works. The business value is visible. The model may be strong enough. The missing piece is the enterprise’s ability to own the operating consequences.

Frameworks help, but ownership has to be operationalized

The U.S. does have valuable frameworks. The NIST AI Risk Management Framework is designed for voluntary use and is intended to improve the ability to incorporate trustworthiness into the design, development, use, and evaluation of AI products, services, and systems. (NIST)

That is helpful. It gives organizations language and structure. It supports better risk thinking.

Frameworks still have to be translated into enterprise operating reality.

A framework does not automatically define which business process owns an AI outcome. It does not certify whether the underlying data is authoritative, provisional, restricted, synthetic, expired, or derived. It does not establish which human role may override the model. It does not decide what evidence must be captured. It does not resolve which escalation path applies. It does not determine how downstream systems should treat an AI output.

That work has to happen inside the enterprise.

For high-impact AI, governance cannot begin after scale. The operating foundation must be defined before AI is embedded in business execution.

DSIL helps the enterprise become machine-readable and sovereign

This is the role of DSIL™, the Digital Substrate Identity Layer.

DSIL is the enterprise-owned layer that helps an organization become machine-readable without surrendering its identity to vendors, tools, or fragmented local interpretations. It makes the organization’s business meaning, decision logic, policies, trade-offs, accountability structures, and governance expectations explicit enough for AI systems to operate within them.

AI needs an institutional context. It needs to know which meaning is authoritative. It needs to know which decision rules apply. It needs to know which trade-offs the organization accepts. It needs to know where automation is appropriate, where human judgment is required, where escalation is mandatory, and where action is prohibited. It needs to know what constitutes sufficient evidence. It needs to know which business outcomes the organization is prepared to own.

DSIL helps an enterprise understand itself in a form that machines can safely consume. It formalizes what the organization means, how it makes decisions, who is accountable, which policies matter, which exceptions require review, and which AI-enabled business processes the enterprise is willing to stand behind.

Sovereignty becomes practical when the enterprise owns the layer that defines its meaning, decisions, policies, trade-offs, and accountability structures.

Enterprise sovereignty is the ability to preserve institutional identity as AI scales. It means the organization owns its definitions, decision logic, governance rules, risk tolerance, escalation paths, data boundaries, and accountability expectations. It means AI-enabled processes reflect the enterprise’s own standards rather than inherited defaults from a vendor, model, workflow tool, or local team.

The name matters less than the capability. I call this DSIL, but every enterprise will need some version of this operating layer: a way to make business meaning, data trust, decision logic, policies, trade-offs, ownership, human oversight, escalation paths, and evidence standards explicit enough for AI systems to consume.

Without this layer, AI adoption relies on tool interpretation, vendor defaults, and local assumptions. Each team makes assumptions. Each workflow develops its own shadow logic. Over time, the organization may lose coherence across decisions, processes, and customer experiences.

That is the institutional risk.

Responsibility moves into the enterprise

The absence of a U.S. Article 27-style requirement should not be interpreted as permission to scale AI without impact discipline.

In reality, the lack of a single federal rule increases the need for enterprise-owned governance. When regulation is fragmented, the organization has to create the connective tissue itself.

That connective tissue has to be operational.

A company needs to know where AI is used, what it consumes, what it produces, what decisions it influences, who is affected, who owns the outcome, how exceptions are handled, and what evidence is retained. These are production-readiness questions.

A high-impact AI system should move toward production only when the organization has a clear view of where the system sits in the business process, what decision or action it influences, which people may be affected, what data it relies on, whether that data is fit for the use, what human oversight is required, what happens when the model is wrong, how a person can challenge the outcome, and what evidence will be available after the decision is made.

Those responsibilities move into the enterprise when the regulatory environment is incomplete.

That makes the work a leadership obligation.

Impact discipline needs to become part of the operating model

I remember consistently starting new initiatives with an impact assessment and, before each incremental release, filling out an 80-plus question form. That experience taught me something important: assessment discipline matters, but it can become heavy when every initiative starts from scratch.

AI adoption will involve copilots, agents, assistants, automations, decision-support tools, retrieval systems, embedded model features, vendor systems, and workflow-level intelligence. If every review begins with a blank page, governance becomes too slow. If governance is skipped, risk compounds.

A practical internal impact review needs to cover scope, affected groups, rights and harms, data and design, human oversight, transparency, mitigation, redress, governance, validation, monitoring, third-party dependencies, and residual risk. The goal should be to turn those questions into reusable enterprise operating infrastructure.

This is where the operating layer matters.

Instead of asking every AI use case to rediscover the enterprise context, the organization creates reusable institutional primitives: business domains, Foundational Data Products™, semantic contracts, decision rights, usage boundaries, governance expectations, escalation paths, and accountability structures that AI systems must reference.

Impact review becomes faster and stronger over time because the organization is no longer reassembling context one use case at a time.

Governance becomes adoption infrastructure.

The delay between sandbox and production can be reduced

The move from sandbox to production is where AI initiatives often lose momentum. The prototype works, but the enterprise is not ready to absorb it.

The data is not certified for the use case. The decision owner is unclear. The workflow has not been redesigned. The escalation path is missing. The oversight model is vague. The vendor contract does not address downstream usage. The model output has no evidence record. The business team wants the capability, but no one can confidently say what happens if the system causes harm or produces an incorrect recommendation.

A stable operating layer reduces that delay.

It defines business meaning, data trust, decision rights, ownership, escalation rules, human oversight, evidence standards, usage boundaries, and accountability expectations. It gives legal, risk, compliance, product, data, technology, and business teams a shared operating language.

This gives the enterprise the internal discipline to move responsibly while the law remains incomplete.

Organizations hesitate to embed AI deeply into workflows when accountability remains unresolved. They struggle to productionize what they cannot own. They struggle to automate what they cannot explain. They struggle to scale what they cannot trust.

The production path gets clearer when ownership, evidence, and operating boundaries are defined in advance.

The capability is needed before the mandate arrives

The U.S. may eventually move closer to a high-risk AI assessment model. It may happen through federal law, sector regulation, agency enforcement, state laws, litigation, procurement standards, insurance requirements, or market pressure.

Enterprises with real exposure cannot wait for a clean federal answer.

AI is already entering knowledge work, customer interactions, underwriting, claims, servicing, software development, compliance workflows, research, marketing, HR, operations, and executive decision support. The risk is that enterprises scale AI before they have made their own operating logic explicit.

That is how organizations drift.

They lose coherence decision by decision, workflow by workflow, vendor integration by vendor integration, exception by exception, until the enterprise no longer knows whether its AI-enabled actions reflect its own standards or inherited defaults.

The enterprise must own its digital identity before intelligence begins acting on its behalf.

The adoption threshold is ownership

AI adoption should no longer be measured by access to tools, sandbox activity, hours saved on summarizing meeting notes, or the number of pilots in progress.

The more important measure is whether the enterprise has made itself legible enough for AI to operate safely, consistently, and in alignment with its own institutional logic.

In the EU, Article 27 establishes a formal requirement for certain high-risk AI deployers to assess impacts on fundamental rights before deployment. In the U.S., there is no broad equivalent. That gap creates uncertainty and a leadership opening.

Enterprises can build the substrate now, enabling AI governance to move from after-the-fact review to pre-deployment readiness. It connects business meaning, data trust, decision logic, policies, trade-offs, accountability, human oversight, escalation, and evidence capture before AI scales across the enterprise.

Without it, the enterprise cannot reliably define what constitutes good output, what constitutes sufficient evidence, or which AI-enabled actions it is prepared to own.

Organizations that build this layer will have clearer adoption pathways, cleaner vendor conversations, stronger auditability, and better decision accountability. They will know which AI systems can move forward, which require controls, which need human review, which should not be deployed, which business processes can be automated, and which require trained human judgment, domain expertise, and accountable review.

The absence of U.S. regulation does not remove the need for impact discipline.

It makes enterprise-owned discipline the differentiator.

Subscribe now

Leave a comment

Appendix:

U.S. AI Protection Patchwork State-by-State Working View

I created this working table to support the article’s argument: the U.S. does not currently have one broad Article 27-style AI impact requirement. Instead, AI protections are emerging through a fragmented mix of state laws, sector rules, privacy obligations, employment AI requirements, biometric protections, deepfake laws, public-sector guidance, and voluntary frameworks.

The table is not intended as legal advice. It is a practical research companion for understanding why enterprise AI adoption can slow as organizations move from sandbox experimentation to production implementation. When rules vary by state, sector, use case, affected population, and decision type, enterprises need their own internal operating discipline.

That is the broader point of the article: regulation may arrive later, but the capability to define ownership, accountability, data trust, decision logic, human oversight, escalation, and evidence standards is needed now.

https://docs.google.com/spreadsheets/d/1KzUCrHO_Lo0a1CuzBBNZcRMRi_uyk6a_3JVrdCKcAbo/edit?usp=sharing

When an enterprise has articulated how it makes trade-offs, where decision boundaries sit, what its terms mean, who owns what, and how governance persists, AI systems can operate against that articulation. When an enterprise has not, AI systems harden around defaults instead. Vendor priors fill the articulation gap. The result is convergence: every enterprise looks the same, because every enterprise’s AI is filling the same gap with the same priors.

This is the institutional logic gap. It is the most underdiagnosed risk in enterprise AI deployment, and the gap that the Foundational Data Products™ methodology is designed to close.

What “institutional logic” really means

Institutional logic is the way an enterprise has committed itself to operating. It is the unstated set of priorities that explains why the same situation produces different responses in two different organizations. It is the rule of thumb that a senior underwriter applies, and it is nowhere in the policy manual. It is the threshold at which a controller escalates a transaction that everyone in the finance organization knows, but no system encodes. It is the meaning of “customer” that differs between sales and compliance, and that nobody has ever resolved on paper.

When the enterprise is run by humans, institutional logic lives in heads, in informal hierarchies, and in the slow accretion of precedent. The enterprise functions because the humans who carry the logic can interpret edge cases, escalate ambiguity, and correct for the gap between what the system says and what the institution intends.

When the enterprise is run by AI systems, this stops working. AI systems do not interpret. They infer from data, from training, from patterns. They cannot recover the institutional logic that nobody wrote down. They will not pause and escalate as a senior underwriter would. They will produce an output confidently, and the output will reflect whatever pattern the data and the model converge on.

If the institution has not articulated its logic, the AI fills the gap with vendor priors. The vendor priors are competent. They are also generic. They were trained on the patterns of every other enterprise, which means they encode the average rather than the institutional. The institution that runs on AI without articulation gets the average, not the institution.

Six dimensions of articulation

The articulation question can be made precise. Six dimensions of institutional identity matter for AI delegation. They are not all equally weighted, because they do not all carry the same operational consequence.

1. Trade-Off Articulation. Whether the enterprise can describe explicitly how it prioritizes competing objectives. Whether AI systems have a documented decision hierarchy that reflects institutional values. Whether the trade-offs that define competitive positioning are formalized beyond individual judgment.

2. Decision Boundary Definition. Whether automated and human decision criteria are documented. Whether escalation thresholds are explicit and consistent. Whether AI authority boundaries are defined architecturally, not only in policy.

3. Institutional Logic Codification. Whether the way of doing things is documented in machine-actionable formats. Whether domain concepts — customer, risk, value, quality — carry consistent definitions across systems. Whether strategic intent translates into measurable parameters.

4. Ownership and Accountability Clarity. Whether decision rights and data ownership are explicit enough that AI systems can resolve which authority governs which domain. Whether knowledge ownership is operational, not only documentary.

5. Governance Maturity. Whether governance is institutional rather than project-based. Whether data quality and semantic consistency are enforced systematically. Whether mechanisms exist to detect AI drift from institutional intent.

6. Delegation Preparedness. Whether the enterprise articulates AI success beyond efficiency metrics. Whether it distinguishes what should be delegated from what requires human judgment. Whether the AI deployment strategy accounts for institutional coherence.

The first three dimensions carry the highest weight in the diagnostic. Trade-Off Articulation, Decision Boundary Definition, and Institutional Logic Codification each account for roughly 20% of the total score. The reason is sequencing: an enterprise that has not articulated its trade-offs cannot define its decision boundaries cleanly, and an enterprise that cannot define its decision boundaries cannot delegate them. Ownership and Governance each carry 15%, and Delegation Preparedness carries 10%. The weighting tells the same story as the framework: institutional identity comes first, governance second, AI delegation last.

What the diagnostic surfaces

To be honest, the diagnostic shows three (plus one) things at once.

1. The composite score, on a 0 to 100 scale, lands the enterprise in one of four bands. Ready (80 to 100): strong foundation, focus on maintaining clarity as AI scales.

2. Progressing (60 to 79): key elements in place, critical gaps remain.

3. At Risk (40 to 59): significant structural ambiguity; AI delegation without articulation will likely result in convergence.

4. Urgent (0 to 39): institutional logic largely tacit; immediate action required before AI systems harden around defaults.

The dimension breakdown shows where the gap actually is. An enterprise at the Progressing band overall may have strong governance maturity and weak trade-off articulation, or vice versa. The dimension scores indicate where the institutional work needs to happen. The composite score alone is not enough; the breakdown is the actionable part.

The disagreement among the people taking the assessment is itself a signal. The diagnostic should be completed by a small group, not a single individual, because disagreement on whether trade-offs are explicit, whether decision boundaries are clear, and whether ownership is real is itself diagnostic. Two senior leaders who score the same dimension five points apart are surfacing the same articulation gap that the AI will encounter.

What it does not measure

The Enterprise Identity Readiness Assessment is not a technical readiness assessment. It does not measure data quality, AI tooling maturity, model capability, or infrastructure readiness. Those are downstream. The premise of the assessment is that institutional work must come first; the technical work, however well done, will inherit whatever ambiguity the institution has not resolved.

The assessment is also not a maturity model in the conventional sense. Maturity models tend to imply that more is always better and that every enterprise should aim for the top tier. This assessment is more honest about that. An enterprise that scores in the Ready band has not finished anything; it has earned the right to scale AI without inheriting incoherence. An enterprise in the Urgent band isn't failing; it is being asked to complete the institutional work before the AI deployment makes the gap permanent.

Where the assessment lives now

The Enterprise Identity Readiness Assessment v1.0 is now publicly available on GitHub under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 license. It is free for personal, educational, and internal organizational diagnostic use, with attribution. Commercial use requires a separate license.

The repository contains the Excel workbook, the scoring methodology document, a worked example with full leadership-level interpretation, the license, a citation file for academic and professional reference, and a changelog for version tracking.

The assessment is the diagnostic instrument for the first stage of the broader methodology. Diagnosis comes first; stabilization, intelligence enablement, judgment enforcement, and intent preservation at scale come after. The assessment makes the institutional gap visible. The methodology closes it.

Run the assessment. Sit with the result. Show it to your leadership team. The institutional logic gap is not something to fear; it is something to articulate. The work of articulation is the work that earns an enterprise the right to delegate to AI without losing itself.

Enterprise Identity Readiness Assessment on GitHub: github.com/AnnaJibga/enterprise-identity-readiness-assessment

© 2026 Anna Jibgashvili | Foundational Data Products™ | DSIL™

The NBER “Firm Data on AI” paper, published in February 2026, is the most rigorous dataset on enterprise AI adoption available. Nearly 6,000 senior executives across the US, UK, Germany, and Australia. Sixty-nine percent of firms use AI. Eighty-nine percent of executives report no productivity impact. Ninety percent report no employment impact.

The paper measured exactly what it set out to measure, and the measurement was careful. The reading of what it means is where the industry is going wrong.

The standard read is that AI is overhyped. That read does not fit the data. AI is changing work. The data is telling us something more specific than “nothing happened.”

What the survey was designed to capture

The NBER productivity question asks executives how AI has affected “the volume of sales per employee” over the past three years. Sales per employee is a good metric. It is the right metric for measuring productivity change at the firm scale once that change has worked its way through the organization into output. It is a clean, comparable, long-established labor productivity proxy.

What it cannot see is structural change while that change is still in progress. Sales per employee registers the result of a transformation after the workflow, headcount, and revenue have all re-stabilized in their new configuration. During the years when the workflow is being rebuilt, the ratio moves slowly or not at all. That is not a flaw. That is what a throughput ratio does.

Every previous general-purpose technology produced the same early reading. Electricity did not appear in factory productivity statistics for forty years after adoption began. The factories that eventually captured the gains were those that redesigned the shop floor around electric motors, rather than those that dropped motors into steam-era layouts. The productivity data sat flat until the workflow was rebuilt, and then it moved.

The NBER data tells us what stage of that arc enterprise AI is currently in. It is not a verdict. It is a snapshot.

What the snapshot captures

Right now, AI is being deployed across enterprises as an individual productivity tool. Employees summarize documents faster, generate content faster, and analyze information faster. That improves personal productivity without changing the enterprise's structure.

When AI is layered onto the edge of an existing process, the org chart does not change. Reporting lines do not change. Workforce numbers do not change. The process underneath stays exactly the same.

That is the world the NBER sample is living in.

What transformation looks like when it has worked through to the metric

A second population of firms exists, and sales per employee clearly show that population.

Gamma reached $100 million in annual recurring revenue with about 50 employees. That is roughly $2 million of revenue per employee. Salesforce, a reference point for enterprise SaaS, runs at around $500,000 per employee. Gamma is four times more productive by the same metric that reads flat across the NBER sample.

Midjourney is further along the curve. Roughly $500 million in revenue with approximately 100 employees, entirely self-funded, no marketing spend. That is around $5 million per employee, ten times the SaaS benchmark.

Neither company is an outlier because its AI is better than the AI inside. The models they use are the same public models available to everyone. They are more productive because the workflow was built around AI from day one.

They are also AI-native firms with no legacy approval chains, no fragmented system landscape, no inherited process debt, and no historical reporting structure designed for human throughput. Incumbents are trying to layer AI into operating models that were built for a different era.

There is no legacy process to bolt AI onto. There is no approval chain designed for human throughput. There is no form schema inherited from a decade of paper.

The product is the workflow.

And the workflow was designed with AI as a participant rather than as a bolt-on.

Sales per employee reads this cleanly. The metric is not broken. It works exactly as designed once structural change is complete and baked into the firm’s operating model.

This is the point the NBER data has been interpreted to contradict, and it does not. The survey measured incumbents in the middle of a structural transition. AI-native firms that completed the transition before they ever had an output ratio to move are producing revenue-per-employee numbers that would have been implausible in the SaaS era. The measurement sees them. The measurement cannot detect incumbents yet because they have not reached the same point on the arc.

Real transformation is different from tool deployment

Real AI transformation happens when organizations redesign workflows, restructure dependencies, embed AI into decision paths, reduce manual handoffs, clarify ownership, and build trusted Foundational Data Products™ that enable work to move through systems rather than people.

That does not necessarily mean layoffs. It does mean the nature of many roles will change. Some work will disappear. Some work will shift upward into judgment, exception handling, governance, escalation, relationship management, and orchestration. Some entirely new roles will emerge around AI supervision, data certification, decision accountability, and workflow design.

Why this is not the RPA story again

Anyone who lived through the last automation wave will read this argument with a specific objection. Robotic Process Automation was sold as transformative technology ten years ago. It produced the same kind of press, the same kind of consulting engagements, the same kind of executive conviction. It did not transform much.

I measured an RPA program end-to-end at an enterprise scale. Fewer than 10 percent of claims completed the full workflow through RPA without human intervention. The rest broke, fell to exception queues, or required someone to manually kill a frozen process.

The failure modes were specific and repeated. Claims arrived with missing fields, handwritten notes, unfamiliar form variants, or exceptions the bot had not been programmed to resolve. When the process fell outside the narrow path the automation expected, the pipeline broke, and manual intervention took over.

The lesson from RPA is not that automation failed. It is that automation without workflow redesign fails predictably. RPA was layered onto existing processes built for humans, with all the input ambiguity, data quality variance, format drift, and exception handling that humans had silently absorbed for decades. The steps ran faster where they ran at all. Everything else still needed a person.

AI deployed the same way will produce the same result. A summarization tool sitting next to an analyst does not transform the analytical workflow. An LLM inside a ticketing system does not transform customer service. An agent calling the same ambiguous data humans have always called does not transform the decision.

What makes AI different from RPA is not that AI is inherently more transformative. It is that AI removes the specific constraints that kept RPA scoped to the narrowest deterministic tasks. AI can handle missing data by inferring or escalating. It can read handwritten input. It can recognize forms it has not seen before. It can detect its own failure states and route around them.

Those four capability gains map exactly onto the four failure modes that killed the RPA program I measured. On paper, AI should be able to do what RPA could not.

Whether that potential gets realized depends entirely on whether organizations use AI to redesign workflows or repeat the RPA pattern at a higher speed. A firm that drops an LLM into a claims process without redesigning around its actual capabilities will produce an AI program with a 15 percent end-to-end success rate instead of a 10 percent one. Marginally better. Still not a transformation.

The pattern is the same. RPA programs reported task-level success while end-to-end workflows stayed broken. AI programs are now reporting individual productivity gains while enterprise-level productivity stays flat. The fix is also the same. Measure the workflow, not the task. Measure the structure, not the speed. That is where transformation shows up early, before it reaches an output ratio.

The measurement questions that do show transformation early

The right measurement questions are different from sales per employee, not because sales per employee is the wrong answer, but because it is a late answer. By the time revenue per employee moves at an incumbent, the transformation is already complete. For everything earlier in the arc, different questions are needed.

The right measurement questions look different:

1. Which workflows that existed three years ago no longer exist?

2. Which workflows were split into two, merged, or newly created?

3. How many workflow roles are now performed by AI agents rather than humans?

4. Where did decision ownership shift?

5. Where did the shape of a process change from linear to parallel, or from single-pass to recursive?

6. Which dependencies between people, systems, and teams no longer exist?

None of these show up in sales per employee. All of them are measurable.

A framework for measuring transformation in progress

The NBER finding creates a specific opportunity. There is no widely adopted instrument for measuring AI-driven workflow transformation at the firm level while it is still underway. The field has defaulted to late-stage output metrics because that is what existing enterprise performance systems produce.

A transformation measurement framework would sit on five dimensions.

Workflow composition. How many workflows were split, merged, created, or retired in the measurement period? A firm running the same workflow inventory it had three years ago has not transformed, regardless of how many AI tools it has purchased.

AI role insertion. How many roles inside workflows are now performed by AI agents rather than by humans, and how many human-AI handoff points exist? Counts both agent-performed roles and the orchestration surface humans now manage.

Decision velocity and ownership. How decision cycles are shortened, and where decision rights are moved. A decision that previously required three human approvals and now requires one, with two agent validations, has transformed, even when the outcome volume is unchanged.

Process shape. Whether processes shifted from linear to parallel, from single-pass to recursive, from batch to continuous. Shape change is the clearest external signature of a transformed workflow.

Dependency restructuring. What now depends on what? Which upstream systems became critical, which became obsolete, and which dependencies reversed direction? Dependency maps reveal transformations that output metrics hide until much later.

A firm scoring zero on all five dimensions has not transformed. It has adopted tools. The NBER survey captured this population at a specific point in its arc.

Why this matters for the next survey wave

The NBER authors plan to run this survey twice yearly from 2026 onwards. That creates a longitudinal dataset that has not existed before. As the survey waves accumulate, sales per employee will start to move for firms that completed their structural change earlier. It will not move for firms that stayed in tool-deployment mode.

Pairing the NBER output data with a structural measurement layer would enable the industry to distinguish between the two populations while the transition is still underway. Right now, they look identical in the data. In five years, they will not.

The real signal is structural

AI is a transformative technology. The 89 % no-productivity finding is not the end of the story. It is a precise reading of where enterprise AI adoption currently sits on a longer arc, taken by researchers who designed the right instrument for the question they asked.

The question the industry is asking is different. The industry wants to know which firms are actually transforming and which are only buying tools. Sales per employee answers that question eventually, not early.

For the years in between, the signal is structural. Workflows that changed. Decisions that moved. Roles that shifted. Dependencies that reshaped.

The signal is structural before it is financial.

That is where the story is right now, and that is what a companion measurement framework should make visible.

The full framework, with scoring methodology and reference implementations, is in development. The next post in this series will publish the specification.

Source:
Yotzov, I., Barrero, J.M., Bloom, N., Bunn, P., Davis, S.J., et al. (2026). “Firm Data on AI.” NBER Working Paper No. 34836. https://www.nber.org/papers/w34836

© 2026 Anna Jibgashvili | Foundational Data Products™

Subscribe now

Leave a comment

There is a difference between understanding that compounding trade-offs are dangerous and feeling the moment your trust score collapses in Q5 because of a decision you made in Q2 that felt entirely reasonable at the time.

What the simulator does.

It puts you in the chair of a Product Leader building an enterprise data platform. Three to six quarters. Six competing metrics: Trust, Adoption, Governance, Speed, Budget, and Stakeholder Sentiment.

Every quarter, you face a realistic scenario: executive pressure, a data quality crisis, a semantic conflict between functions, a budget challenge, and an AI team requesting capabilities you did not plan for. Three options. Each one has a legitimate rationale that a good leader can defend. None of them is obviously correct.

You choose. The metrics move. The next quarter arrives with the consequences of the last one already baked in.

This is not a tutorial. It is not a quiz. It is a safe-to-fail environment where the compounding logic of enterprise data strategy becomes visible before it costs you.

What two runs taught me.

I ran it a few times with the same first quarter. One decision in Q2 changed everything.

Run 2 (59, Steady Progress): Force enterprise-wide semantic standards immediately. Simulator: “Too heavy-handed. Business units revolt. Semantic coherence needs buy-in, not mandates.”

Run 4 (80, Exceptional Leader): Create a semantic layer with governed golden definitions and federated input. Simulator: “Perfect. Federated governance with central coherence. This is exactly what Chapter 8 preaches.”

Trust: 55% vs 95%. Same starting point. Same Q1. One Q2 decision.

And here is what the speed argument looks like in practice: Run 2 had Speed at 65%, lower than Run 1’s 50%, but the overall score was 80 vs 52. Slower, better foundations, significantly better outcome. Speed without semantic coherence does not compound. It costs you. Not immediately, but inevitably, in the quarters when the options narrow because of what you chose earlier.

This is the Arc 1 argument made visible. Reuse amplifies whatever foundations already exist. Semantic stability is not semantic consistency. The intelligence supply chain fractures at the points where meaning was never governed. The simulator shows you exactly where those fractures surface.

What your score reveals.

The simulator is a diagnostic. Where you struggle reveals something real about your strategic instincts, and by extension, about where your enterprise’s foundations are most at risk.

If your trust score collapses, you are likely optimizing for speed and adoption at the expense of the quality and governance that trust requires. This is the most common pattern. It feels like progress in the early quarters.

If your governance score collapses, you are likely building fast and governing late: the pattern in most enterprise AI deployments. The simulator shows you what governance added after the fact costs compared to governance built alongside the product.

If your stakeholder sentiment drops while your technical metrics hold, you are solving the wrong problem. Intelligence delivered without the political capital to sustain it gets defunded before it scales.

Play it more than once. The second run is where the real learning happens: when you understand which Q2 decision you cannot afford to make and why, and change the timeline to see the difference it makes.

A note on where this is.

This is an MVP. The scenarios, the logic, and the compounding mechanic are real: drawn from actual enterprise implementations. The interface is functional, not polished. Future versions will add more scenarios, industry-specific tracks, save functionality, and team workshop modes.

The reason to share it now rather than wait for v2 is the same reason the arc posts exist: the problem is urgent, and the window is narrowing. An imperfect tool that makes the compounding argument experiential is more useful today than a perfect one that arrives later.

Where to find it.

The simulator is live at foundationaldataproducts.com/simulator. Free. Eight to twenty minutes depending on how many quarters you choose.

Share your score in the comments. I want to know which quarter broke you, and which decision, in hindsight, you would make differently.

The Enterprise Data Products Strategy Simulator is built on the same logic as the Foundations Strategy arc. The scenarios are drawn from real enterprise implementations. The outcomes reflect what happened in practice, not what should have happened in theory.

© 2026 Anna Jibgashvili | Foundational Data Products™ | All Rights Reserved

I started this series to document what I was observing inside large enterprises, the patterns that kept repeating, the gaps that kept compounding, and the question nobody seemed to be asking directly: what happens to institutional identity when intelligence begins participating in execution?

The series organized itself into three stages.

The Convergence: why now. The Diagnosis: how to know where you stand. The Build: what to construct, and in what order.

Because once intelligence participates in decisions, whatever is not explicitly institutional becomes accidental.

The Numbers Tell a Clear Story.

In 2025, enterprises invested $684 billion in AI initiatives. Over $547 billion of that investment failed to deliver intended business value. 95% of generative AI pilots failed to scale. 84% of those failures were leadership-driven. Industry research now places AI project failure rates as high as 90%.

60% of AI projects are abandoned when AI-ready data foundations are missing. Nearly two-thirds of organizations remain stuck in pilot mode, with only 4 out of 33 pilots reaching production on average.

Stanford’s Digital Economy Lab studied 51 enterprise AI deployments published this month. Their conclusion was precise: same technology, same use cases, vastly different outcomes. The difference was never the AI model. It was always the organization, its readiness, its processes, its leadership.

These numbers did not surprise me. They confirmed what I had been observing for years inside the institutions I worked with and within.

I watched enterprises invest heavily while the foundational conditions for AI to work were never established. I watched governance get applied to systems that were never designed to be governed. I watched smart, experienced people carry institutional knowledge that no system had ever been built to capture. And I watched the same failures repeat, not because organizations lacked ambition or resources, but because nobody had named what was actually missing.

That observation led me to a deeper analysis: how can AI actually scale inside a large, complex enterprise, and how can the organizations I spent my career building stay marketable, differentiated, and distinctively themselves as intelligence reshapes how work gets done?

The Three Paths to AI at Scale is the result of that analysis. It is not a framework borrowed from research. It is what I found when I followed the question honestly. Leaders need to see these paths clearly, because the one they are on right now may not be the one they chose.

The Market Responded. The Gap Remained.

The largest technology companies acquired or built capabilities specifically to reach enterprise data, to help organizations make it AI-ready. Remarkably intelligent startups built sophisticated tools to help enterprises map their data, read it, add semantics, establish lineage, and surface meaning across fragmented systems. That wave of innovation was real. Many of those tools delivered genuine value.

But they came with a structural cost that was rarely named at the time.

Every tool that reached into the enterprise data layer and encoded meaning on the organization’s behalf, every platform that mapped trade-offs, defined concepts, or interpreted institutional logic, tied that encoding to itself. The semantic layer lived in the vendor. The decision logic resided in the platform configuration. The meaning that should have belonged to the enterprise became a feature of the subscription.

Organizations gained capability. They traded sovereignty to get it.

The assumption that transformation could be purchased without first understanding what the organization actually is did not just apply to AI models. It applied to the entire ecosystem of tools built to bridge the foundational gap. The gap remained. It was papered over with a more sophisticated layer of dependency.

AI executes within whatever structure exists, encoded or not, coherent or not, held inside tools the enterprise does or does not own. When that structure is implicit, fragmented, and externally held, AI amplifies those conditions. It does not resolve it.

68% of failed AI projects were underinvested in data governance and foundational capabilities. 61% treated AI as an IT project rather than a business transformation. These are foundational failures.

And Yet AI Is Working, For The Organizations That Built The Foundation First.

Organizations moving AI from pilots to production are seeing average returns of 1.7x. Cost savings of 26 to 31% are documented across the supply chain, finance, and customer operations. Visionary adopters show 3.6x three-year total shareholder return versus those that lag.

The enterprises succeeding are realizing up to 5x the ROI of their peers, largely because they have established sovereign, AI-ready foundations that unify data, governance, and operational control. Interest in sovereignty has surged more than 400% in the past year, reflecting a global shift toward control and resilience. 93% of US executives are currently redesigning their data stacks, not because the technology failed, but because the architecture became a liability.

The contradiction between failure rates and success stories resolves clearly. The organizations achieving transformative results built their institutional identity into the foundation before they delegated reasoning to a system. The ones failing deployed the same technology on unresolved foundations and discovered that AI scales whatever exists, including the fragmentation, the ambiguity, and the unarticulated logic that nobody ever formally encoded.

AI produces different results because the organizations are different. Their readiness. Their foundations. Their sovereignty.

The Response That Compounded The Problem

The dominant enterprise response to poor AI results has been reduction. Mass layoffs. Eliminating experienced people, often those who carry the deepest institutional knowledge the organization has accumulated over decades.

That response deserves more scrutiny than it has received.

The people being eliminated are precisely the ones who know how decisions are actually made, why certain trade-offs exist, where the exceptions live, and what the organization has learned through experience that never made it into any system. That knowledge is the raw material of institutional identity. When it walks out the door before it is encoded, it is gone. The AI that follows defaults to industry patterns. It produces outputs that reflect every organization, not yours specifically.

Success in AI requires achieving strategic differentiation and a lasting competitive edge. That depends on what makes the organization distinctively itself, not what makes it functionally similar to its competitors.

There Is Another Way.

Start with understanding your own enterprise digital identity.

Understand how the enterprise operates and delivers value, process dependencies, priorities, data, and accountability structures, business vertical by vertical. Map where they connect, overlap, and diverge across domains. From that inventory, the right automation candidates emerge, from the organization’s own understanding of itself, on its own terms.

Projects that treat AI as a transformation rather than an IT tool implementation achieve 61% success rates versus 18% for those that do not. Projects with sustained executive sponsorship achieve 68% success rates versus 11% for those that lose it.

The difference is whether the organization encoded who it is before it delegated reasoning to a system, and whether it kept that encoding sovereign.

DSIL™: The Foundation That Makes Sovereignty Operational

Institutional identity must be encoded before it can be protected.

DSIL™, Digital Substrate Identity Layer™, is the methodology that enables that encoding. It captures how the enterprise actually operates: its risk appetite, judgment boundaries, decision thresholds, escalation paths, and trade-offs. It makes that logic portable, able to travel across systems, domains, and workflows without being reshaped by the tools it passes through. And it keeps that logic sovereign, owned by the enterprise, governed as institutional policy, independent of any vendor platform or model provider.

This is what separates DSIL™ from the tool market that emerged to fill the foundational gap. The semantic layers, data catalogs, and knowledge graphs mapped meaning within platforms. DSIL™ encodes meaning inside the institution. The distinction matters enormously when a tool changes, a vendor is acquired, or a platform reaches end of life. With tool-dependent encoding, institutional logic resets. With DSIL™, it travels.

Enterprises that establish sovereign, AI-ready foundations are realizing five times the ROI of peers who rely on fragmented or vendor-dependent architectures. The foundation produces the returns. Sovereignty protects them from being absorbed by whoever controls the tools.

When DSIL™ is in place, AI agents draw from encoded institutional logic rather than statistical industry averages. Decisions reflect the organization’s own values and trade-offs rather than vendor defaults. New initiatives build on an existing identity layer rather than reconstructing context from scratch. And when tools change, and they will, the institutional identity travels with the enterprise rather than resetting inside a platform.

Control of the data layer, not the models, defines who captures value in AI. DSIL™ is that layer. Portable. Sovereign. Owned by the enterprise. Independent of any tool or vendor.

The Function that Does Not Yet Exist

Enterprises today have an executive responsible for AI. What they do not have is a transformation leader.

These are meaningfully different functions.

The executive responsible for AI is measured on deployment activity, pilots launched, agents demonstrated, and business sponsors impressed. Acceleration without direction, however, does not produce transformation.

A transformation leader carries a different mandate. They understand the undercurrents that leadership cannot always see from where it sits, the institutional knowledge at risk, the compounding governance gaps, and the foundational debt accumulating beneath every new initiative. They help leadership understand what the organization actually is, what it needs to become, and which path will get it there with its identity intact.

This series was a public service announcement for that leader, and for the executive who needs to appoint one.

There are three paths to AI at scale. Vendor-mediated identity. Fragmented identity. Sovereign identity. The first two are what happen when no one chooses deliberately. Path three must be designed. It starts with the foundation. It requires a leader who understands the mandate.

If you want your organization to remain itself as AI scales through it, there is a way. The foundational way.

The Mandate

AI transformation carries executive responsibility.

As intelligence becomes embedded in execution, institutional logic must be made explicit.

Trade-offs require articulation. Authority requires definition. Meaning requires stability. Delegation requires structure.

These are the conditions that determine whether your organization scales coherently or scales away from itself.

For decades, institutional continuity was preserved through experience. Precedent lived in leadership judgment. Context reconciled ambiguity. Hierarchy stabilized interpretation.

AI changes those operating conditions fundamentally.

When intelligence participates directly in execution, institutional logic must be translated into architecture.

Strategic posture becomes a decision parameter. Risk tolerance becomes thresholds. Escalation becomes workflow. Judgment becomes system behavior.

Without deliberate design, these elements settle into infrastructure through accumulation rather than intention. At that point, what the organization becomes is no longer a leadership decision. It is an accident.

Leadership carries a structural obligation that belongs to no other function.

Institutional doctrine must be formalized before delegation stabilizes. Authority must be clear before automation distributes it. Meaning must remain consistent as systems scale. Sovereignty must be built into the foundation, not claimed after the tools have already absorbed the logic the enterprise never encoded.

What This Series Established

Institutional identity, how an enterprise creates value, makes decisions, assigns accountability, and interprets risk, must be made explicit before intelligence can operate within it safely. As architecture. As the foundation from which every system, every agent, and every automated workflow draws.

DSIL™ is that framework. Portable. Sovereign. Owned by the enterprise. Independent of any tool or vendor.

Transformation is inevitable. Up to 87% of enterprises risk falling behind if they do not commit to sovereign, AI-ready foundations. The ones that build that foundation will scale AI that compounds their institutional advantage. The ones who defer will discover they have built intelligent systems that reflect no one in particular.

The foundation is where transformation begins. Sovereignty is what ensures it remains yours.

The window is open. It will not stay open.

Institutional integrity in the age of intelligence depends on executive authorship.

The next series is coming. It will address what transformation actually looks like, not as a strategy document, but as an operational reality.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Sources

Pertama Partners, AI Project Failure Statistics 2026 https://www.pertamapartners.com/insights/ai-project-failure-statistics-2026

Fortune / MIT NANDA Initiative, 95% of Generative AI Pilots Failing https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo

Stanford Digital Economy Lab, The Enterprise AI Playbook: Lessons from 51 Successful Deployments https://digitaleconomy.stanford.edu/publication/enterprise-ai-playbook

Deloitte, State of AI in the Enterprise 2026 https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html

CIO / EDB, Building Sovereignty at Speed in 2026 https://www.cio.com/article/4098933/building-sovereignty-at-speed-in-2026-why-cios-must-establish-ai-and-data-foundations-in-120-days.html

Analytics Week, AI Sovereignty: Why 93% of US Executives Are Redesigning Their Data Stack https://analyticsweek.com/ai-sovereignty-2026-data-stack-redesign

Solutions Review, AI and Enterprise Technology Predictions 2026 https://solutionsreview.com/ai-and-enterprise-technology-predictions-from-industry-experts-for-2026

Master of Code, AI ROI: Why Only 5% of Enterprises See Real Returns in 2026 https://masterofcode.com/blog/ai-roi

Tech.eu, The Missing Layer in Europe’s AI Strategy: Data Ownership https://tech.eu/2026/04/01/the-missing-layer-in-europes-ai-strategy-data-ownership

Hyperight, What 300 Enterprise AI Use Cases Reveal About 2026 https://hyperight.com/enterprise-ai-operationalization-2026

#EnterpriseIdentity #DSIL #Leadership #AIReadiness #StructuralIntegrity

Subscribe now

Leave a comment

Share

I emphasized interoperability by designing for consistent value across APIs, shared data, and reusable implementations, so that users experienced the same outcome regardless of how they accessed it. On the surface, this created technical efficiencies. More importantly, it reinforced trust by ensuring the product behaved consistently across entry points.

That shift made my role more elastic, end-to-end. It heightened my awareness of how data freshness affects users and led me to think more deliberately about performance, including how to pre-calculate what the interface requires to make the experience feel immediate.

More importantly, it changed the underlying design question.

It shifted from what this team needs to build to what the enterprise needs to own so every relevant initiative can build on top of it.

That lesson was never fully absorbed.

Most organizations adopted the vocabulary of interoperability without building the shared foundations it required. They reused what was convenient and left everything else in silos. As enterprises moved from mainframe transaction systems to relational databases, from relational to data warehouses, through the ETL integration era, from Hadoop data lakes to cloud platforms like Snowflake and Redshift, and now toward lakehouse architectures, each transition created new copies of the same data living in parallel with the old.

Some systems stayed on Oracle. Others moved to Snowflake. Others landed in Hadoop and never fully migrated out.

The mainframe never went away. It simply accumulated more systems on top of it.

Governance stepped in at each transition, but it remained forward-looking and applied primarily to new initiatives rather than to the enterprise as a whole. Existing fragmentation remained unresolved. Addressing it at the enterprise level was often seen as too costly, too complex, and too slow. As a result, governance advanced with new systems, while underlying inconsistencies persisted.

The fact is, AI arrived at a time when many organizations were just completing cloud migrations, not fully, but enough to shift attention forward. Few had ecosystems capable of supporting AI at scale. None had an explicit digital identity to serve as a foundation for AI transformation, and only a small number had explored technologies such as blockchain in that context.

AI transformation is arriving at that unresolved condition, and it is not forgiving.

When a team lacked shared foundations in the interoperability era, they got slower. When AI agents operate across domains simultaneously without shared foundations, the organization becomes incoherent at scale.

The cost shifted from an efficiency problem to an integrity problem.

The role structures enterprises built for the old paradigm, the Elastic PM, who did end-to-end product management, the Scrum Master, the PMO, and the governance committee, were not designed for this.

Product organizations were not designed for the new skills AI is introducing.

For years, enterprises operated under a core assumption: a Product Manager could hold strategy, execution, and adoption together. The full-stack PM became a symbol of versatility, someone capable of defining vision, guiding development, and translating value across stakeholders.

Elasticity was seen as a strength. For a time, it was.

AI has changed the role of the PM in several ways. As this shift began to surface, data product management emerged as a distinct role, the first visible signal that the elastic model was under strain. Even the most adaptable, end-to-end PM, the 0-to-1 builder, must now evolve to operate effectively in this new environment.

AI has fundamentally changed what the PM role requires compared to the pre-AI product world.

In reality, the role has already separated into distinct functions, and most organizations have not yet named them.

How AI Changed Roles

In my experience, product innovation rests on three core responsibilities: defining what to build, building it, and driving its adoption. Every organization names them differently. Every framework sequences them differently. The underlying purpose, however, is consistent: the right outcome for the right user, delivered through a process that connects vision to execution to real-world impact.

These three responsibilities are not phases that end. They form a continuous loop. What to build must be grounded in what produces the intended outcome. How to build it must be designed around that outcome, not around features, timelines, or velocity metrics. Whether adoption occurred and whether the outcome was achieved closes the loop and informs what comes next.

AI did not break that loop. It deepened every stage within it — dramatically.

Defining what to build now requires understanding what AI can and cannot do, which processes are genuine candidates for automation, and what the organization must have in place before committing. Building it now requires navigating probabilistic systems, data contracts, model governance, and a delivery mandate that extends well beyond shipping features. Driving adoption now means building institutional trust in systems that users cannot fully see or verify.

As these responsibilities deepened, the role itself evolved.

Rather than eliminating roles, AI is expanding them into distinct functions, each requiring deeper expertise as the complexity of product systems increases.

One of the earliest signals of that shift was the emergence of the Data Product Manager (Data PM) as a distinct function. What had previously been absorbed within the broader product role began to separate, as data required its own lifecycle, ownership model, and governance discipline.

This was not a specialization trend. It was a structural signal.

The Elastic PM has evolved into three distinct capabilities:

• Data & AI Strategist - defines what should be built, where AI belongs, and what the organization must have in place before committing

• AI Product Manager - owns delivery, including probabilistic systems, data contracts, model governance, evaluation frameworks (what good looks like), and performance

• AI Adoption / Support PM -ensures outcomes are realized in practice, including user enablement, system adoption, and continuous monitoring

This third capability can be supported by a system with human-in-the-loop (HITL) mechanisms for continuous monitoring and drift detection.

This pattern is not unique to product management.

Across the enterprise, roles are undergoing a similar reconfiguration. Responsibilities that were once held within a single function are being separated into distinct capabilities, while others are being absorbed or partially automated. In some cases, functions that appear to disappear are re-emerging elsewhere with greater depth and different ownership.

For example, adoption is no longer confined to a single role. It may be led by a data and AI strategist, embedded within a product, or extended into functions such as marketing. At the same time, elements of support may be automated or system-assisted, shifting the nature of the work rather than eliminating it.

The effect is not reduction, but redistribution; responsibilities are being reorganized to align with how systems operate, how decisions are made, and how outcomes are produced.

As this redistribution occurs, what becomes critical is not the structure of roles but the clarity of the underlying system in which they operate. Without a stable foundation for meaning, ownership, and decision logic, responsibilities fragment even when roles are clearly defined.

Consider how each of these responsibilities has deepened.

• Strategy anticipates consequence
  Vision must align not only with market opportunity but also with regulatory exposure, ethical implications, and institutional risk. Strategic PMs must identify high-value AI opportunities while ensuring responsible integration into decision environments.

• Delivery stewards intelligence systems
  Execution has evolved into lifecycle governance. Data readiness, model reliability, interpretability, observability, and bias monitoring are now part of the delivery mandate. Success is measured less by shipped features and more by system integrity.

• Adoption builds trust, not just usage
  AI products must be understood before they can be trusted, and trusted before they can scale. Explainability, transparency, and behavioral acceptance are product requirements.

Individually, these expectations are reasonable.

Collectively, they redefine the role.

The traditional do-it-all PM model is not scaling with the systems we are building.

What once created speed now risks creating entropy.

The Elasticity Boundary

In the earliest stages of innovation, elasticity is necessary.

One product leader often holds the narrative together by shaping the vision, partnering with engineering, translating value, and guiding early adoption. This compression accelerates learning cycles and reduces friction.

Elasticity, however, has a natural half-life.

As AI systems mature, the surface area expands. Dependencies increase. Stakeholders multiply. Regulatory scrutiny intensifies. Operational consequences grow.

At a certain threshold, stretching further no longer creates leverage. It begins to erode clarity.

This is the Elasticity Boundary, the point at which capability gives way to design.

Across enterprises, a consistent pattern is emerging in how product leadership evolves as complexity increases.

This progression reflects a structural response to the expansion of capabilities within the role. This shift becomes visible in how roles evolve as complexity increases.

The Elasticity Curve

The curve below captures that evolution.

Elastic. Stretch. Divide. Federate.

Elastic: One Product Manager spans strategy and delivery. This works when required capabilities can still be held within a single role, and speed matters more than specialization.

• Stretch: As systems expand, new capabilities emerge in data, AI, governance, and adoption. Expectations outpace individual capacity, and the role begins to strain as these capabilities are added without structural support.

• Divide: At a certain point, organizations recognize that durability requires the separation of responsibilities. Strategy, delivery, and adoption become distinct roles, not because of scale alone, but because the capabilities required within each have become too deep to be held by one person.

• Federate: As complexity scales further, these capabilities are replicated across domains and coordinated through shared governance and operating principles, ensuring consistency without centralizing control.

This progression is not driven by hierarchy. This is driven by new capabilities that didn't exist in the role and cannot be absorbed without structural change.

The Triad Is Not the Point

This evolution of the role should not be mistaken for a prescription.

Some organizations will adopt triads. Others will prefer guild models, dual-track partnerships, or operational overlays.

The future of product leadership will not be uniform. What will be universal is something deeper:

Governed Interoperability.

Modern data ecosystems rely on shared metadata and lineage. Product organizations must design equally clear decision-making interfaces.

Without them, ambition fragments. Structure matters less than coherence.

As roles continue to separate and responsibilities are redistributed, coherence becomes the constraint. Without a stable foundation for meaning, ownership, and decision logic, even well-defined roles will drift.

The range of emerging operating models reflects this shift.

Companion to the AI PM Elasticity Curve

Across organizations, this shift is already taking shape in different ways.

The specific structures vary, triads, guilds, embedded models, or operational overlays, but they reflect a common pattern: as capabilities deepen, roles separate, and coordination becomes a design requirement rather than an afterthought.

These are not prescriptive models. They are emerging responses to the same underlying constraint.

What Remains Human

AI will act as a force multiplier for product leaders. It extends analytical reach, accelerates synthesis, and reduces operational drag.

As a result, the scope of what a Product Manager can oversee continues to expand.

Yet some capabilities remain distinctly human.

Judgment, ethical reasoning, empathy, strategic restraint, and the ability to influence decisions without breaking alignment.

These are not artifacts of a pre-AI era. They are stabilizers in an AI-driven one.

Conclusion

Elasticity in product management is no longer defined by breadth, but by the boundaries of its capabilities.

A role may still span strategy and delivery, or delivery and adoption, but only within the limits of the capabilities it can sustain.

Elasticity accelerates. Specialization sustains.

Early innovation rewards stretch. Enduring institutions reward clarity.

The challenge is not choosing between them. It is knowing when to transition — and having the organizational design in place before the cost of not transitioning becomes visible.

Maturity is not marked by how far a role can stretch, but by how intentionally a system is designed once it no longer should.

AI is not just reshaping products. It is reshaping how work is structured across the enterprise. The organizations that redesign their roles, governance models, and shared foundations with the same rigor they apply to their AI systems will be the ones that scale both capability and coherence.

Rather than removing roles, this shift is expanding them — into distinct functions that require deeper expertise, clearer ownership, and new capabilities that did not previously exist.

Organizations that do not make this transition will continue to operate with compressed roles that cannot sustain the capabilities required at scale.

The constraint is not effort. It is structured.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Share

Leave a comment

Once the foundation exists, with institutional identity made explicit, certified data products produced, and a machine-readable record of how the organization creates value, makes decisions, and assigns accountability, the operational question becomes how intelligence runs on top of it.

That is the question EDAOF answers.

What EDAOF is.

The Enterprise Data and AI Operating Framework is the operational system that runs on the DSIL™ foundation. It is not a project methodology or a governance checklist. It is the complete operating system that governs how data and AI demand is evaluated, built, governed, deployed, and monitored: continuously and at enterprise scale.

DSIL™ must exist before EDAOF can run. The foundation determines what the operating system has to work with. An enterprise that attempts to run EDAOF without a DSIL™ foundation will produce certified data products built on implicit, ungoverned identity: technically certified but institutionally unreliable.

The sequence matters: DSIL™ first, certified FDPs as the output, and EDAOF operational cycle as the system that produces and governs everything built on top.

The four components.

EDAOF has four integrated components. They do not operate independently. Each feeds into the next.

The Data Product Operating Engine (DPOE) serves as the intake, development, and certification function. Every data and AI request enters via a structured ten-point canvas that translates a business need into a specification that engineering can act on. Requests are scored and prioritized by dependency, criticality, and quality debt. Development follows a 12-step cycle with a governance gate embedded before the build phase: data that has not been profiled for validity and whose quality rules have not been tested does not enter development. The output is a certified data product with a named owner, a defined consumer, and a quality score that travels with it.

The Data Product Hierarchy organizes this work into Domains, Subdomains, and Facets, enabling continuous, incremental delivery rather than large, slow releases. The fast-start principle: build the smallest certifiable unit of the most-used asset first, prove it is useful, commit to adoption before development begins, then build the next facet. The hierarchy grows from proven components.

The Policy and Decision Intelligence Layer (PDL) governs what intelligence can do with the data products DPOE produces. This is where guardrails are defined, confidence thresholds are set, escalation paths are established, and compliance requirements are embedded. It specifies the conditions under which an AI agent can act autonomously, when it must escalate to a human, what it is prohibited from doing regardless of instruction, and how exceptions are handled.

The PDL is deliberately separate from DSIL™. DSIL™ is identity, stable by design. The PDL is conducted and must evolve as regulations change, as new AI capabilities emerge, and as the organization’s risk appetite is calibrated through experience. Keeping them separate allows policies to be updated without touching the identity layer. It also ensures that every AI decision can be traced to the policy version that governed it at the time it was made.

The PDL defines the structure for encoding compliance requirements: thresholds, escalation paths, audit trails, policy versioning, and governance gates that operationalize regulatory adherence. The specific regulatory content (what GDPR, SR 11-7, the EU AI Act, NYDFS, HIPAA, or any sector-specific framework requires) is provided by compliance and legal SMEs with authority in the relevant jurisdiction. The framework provides the infrastructure. Domain experts provide the rules. That boundary is intentional. An enterprise operating in financial services will populate the PDL differently from one operating in healthcare, and both will update it as regulations evolve. What remains consistent across both is the structure that makes those requirements enforceable, auditable, and traceable to every decision made under them.

The AI Factory is where agents are deployed on certified data products and operate under the decision policies defined by the PDL. Before any agent enters the Factory, it must complete an Agent Requirements Document (ARD) that specifies its identity and scope, the data product contracts it will consume, including their trust scores and SLAs, its capability boundaries, its decision policies and confidence thresholds, its HITL escalation workflows, and its failure runbooks.

At deployment, the ARD becomes the agent contract: a versioned passport that travels with the agent throughout its operational life. Every decision the agent makes is logged against the contract version in effect at the time. When a policy changes, a new contract version is issued, and the previous version is preserved. This is what makes agents auditable throughout their lifetime rather than only at a single point in time.

Deployment is phased: Shadow, where the agent runs in read-only mode alongside humans; Staged, where the agent handles a defined percentage of live cases; and Production. Agents that do not meet the minimum trust threshold at each phase do not advance until gaps are closed.

Monitoring runs continuously across the entire system. It covers two distinct signals.

Output and adoption monitoring tracks whether certified data products are consumed as intended, whether downstream decisions are made differently as a result, and whether agent behavior aligns with what the ARD specified. These signals feed back into the next intake cycle, informing what needs improvement, what new facets are needed, and what the next development priority should be.

Identity drift monitoring tracks whether DSIL™ definitions hold as AI scales across the organization. When semantic drift is detected, such as when the same concept is interpreted differently across domains or when agent outputs reveal that institutional logic is no longer applied consistently, monitoring surfaces the signal and routes it to the CEIO function for remediation. Drift that goes undetected at the foundation level propagates through every layer above it. Monitoring prevents the propagation from becoming structural.

How the operating loop runs.

EDAOF is not a one-time program. It is a continuous loop:

Inventory and discovery reveal the organization’s digital identity, establish a quality baseline, and identify the first development priority. The cross-functional committee sees value early. Adoption is committed before development begins.

Development and certification run through the 12-step cycle. The governance gate enforces the boundary between profiling and building. Progressive certification is active throughout. The consumer API is delivered alongside the data product.

Deployment and activation bring the certified data product live. Consumers activate on the schedule they committed to at intake. The ARD is written. The AI Factory deploys the agent.

Monitoring and feedback tracks output quality, adoption patterns, and identity drift. Signals inform the next intake cycle. The CEIO function receives drift alerts and initiates DSIL™ remediation where needed.

The next facet is identified. The loop repeats, faster each time, because the pattern is established, the standards are proven, and the data product hierarchy is growing from certified components.

What EDAOF produces that nothing else does.

Trusted data products that AI agents can reliably consume: named owners, defined consumers, quality scores, and contracts that travel with the data.

Transparent prioritization so every stakeholder can see what is being built, why, and in what order.

Pre-committed adoption, where consumers plan to use the product before it is built, rather than discovering it as a problem after deployment.

An operating system that runs without the person who built it in the room: the cycle is documented, the standards are clear, governance is embedded, and the loop continues.

And an identity-integrity signal that routes back to the CEIO when the foundation needs attention. An operating system that cannot detect when its foundation is drifting will eventually produce outputs that reflect no one in particular.

This is part of the Enterprise Identity Imperative series. The next post examines how roles are being redesigned as EDAOF runs and why the elastic PM model that held strategy, delivery, and adoption together has reached its structural limit.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

The Choice Most Enterprises Don’t Know They’re Making

Over the next 12 to 18 months, every enterprise scaling AI will follow one of three paths, not because leaders are explicitly choosing a direction, but because the way identity is handled as intelligence scales inevitably hardens into infrastructure.

What appears to be a decision about speed, tooling, or execution is, in reality, a decision about how institutional logic is defined, encoded, and sustained.

We have seen this pattern before: a fast path is chosen under pressure, treated as temporary, something that can be corrected later through governance, integration, or consolidation. But what begins as an implementation strategy stabilizes into infrastructure, and infrastructure is rarely reversible without reconstruction.

Path 1: Vendor-Mediated Identity

Path 1 begins with acceleration. Internal capacity is constrained, governance is undefined, and timelines demand progress, so enterprises embed external providers deeply into execution. These providers do not simply advise; they build, define structures, encode logic, and operationalize intelligence inside the enterprise environment.

This pattern is already visible in the market. In March 2026, Bain & Company expanded its partnership with Palantir, deploying forward-deployed engineers directly into client operations. These are not consultants who recommend architectures; they are builders who write code, construct ontologies, and bring AI systems into production within the client’s environment. The model works because it delivers results quickly. Solutions move from concept to production, and value becomes visible early on, as reflected in Palantir’s rapid commercial growth.

But the structural implication is often missed. The ontology of the enterprise, the way it defines entities, relationships, and decision logic, is constructed within the vendor’s platform. Institutional logic is not only implemented through the platform; it is shaped by it.

The same pattern appears across large-scale enterprise platforms. Salesforce, for example, is deployed through a global ecosystem of thousands of partners and certified experts who configure workflows, define automation rules, and encode business logic directly into the platform. Enterprises gain speed, standardization, and measurable operational improvements, but the logic governing how the business operates becomes embedded in configurations, workflows, and platform-specific structures.

Five years later, the enterprise can execute but cannot fully articulate how it operates independently of the systems it uses. Switching vendors requires reconstructing institutional logic, scaling independently requires continued reliance on external partners, and differentiation begins to align with vendor defaults.

Semantic drift accumulates as core concepts diverge across systems. “Risk” is defined differently across platforms, “customer” varies by implementation, and integration becomes an exercise in translation rather than continuity.

This is not a failure of intent. It is a structural outcome of where identity is encoded.

Path 2: Fragmented Identity

Path 2 begins with decentralization. Each domain builds independently, teams optimize for their own workflows, and systems evolve without a shared substrate. This enables autonomy, but it produces divergence.

This pattern is becoming more visible as enterprises deploy AI agents across functions. In March 2026, VentureBeat highlighted a growing issue: agents built by different teams, on different platforms, do not share a common understanding of the business. Each agent operates with its own interpretation of core concepts such as customer, order, or region.

Finance defines “customer” in one way, marketing in another, and operations introduces a third interpretation. For decades, humans reconciled these differences through context and judgment. AI cannot do this reliably.

As intelligence scales, these inconsistencies propagate through systems. Optimization happens locally, but coherence erodes globally. The tolerance enterprises once had for semantic drift disappears the moment AI begins consuming and acting on that data.

Five years later, the enterprise fragments. Pilots succeed within domains, but scaling fails across the institution. Governance multiplies, but alignment does not. Each domain has intelligence, yet the enterprise as a whole lacks continuity.

Semantic definitions diverge across functions, thresholds are inconsistent, and escalation logic varies by system. The enterprise possesses intelligence, but it does not behave consistently.

The cost is not always visible in the early stages. World Economic Forum research in 2026 highlighted that enterprises struggle to realize AI's value because they operate across fragmented data environments, legacy systems, and workflows filled with exceptions and undocumented rules. Deloitte’s ‘State of AI’ report shows that while adoption is high, only a minority of organizations are truly transforming how they operate.

AI does not eliminate coordination work. It shifts it from interpretation, which humans could manage, to reconciliation, which machines cannot reliably perform across fragmented systems.

This is why fragmentation is not simply a data problem. It is an identity problem.

Path 3: Sovereign Identity

The market is beginning to recognize the underlying constraint. Intelligence requires shared meaning, shared meaning requires formalization, and formalization must precede scaled delegation.

This recognition is reflected in the emergence of the semantic layer. Microsoft’s introduction of Fabric IQ positions a semantic intelligence layer to provide AI systems with a shared version of reality. AtScale’s 2026 report emphasizes that enterprises will not succeed by deploying more models, but by ensuring those models operate from a common, governed semantic foundation. VentureBeat describes the semantic layer as production infrastructure that must be built, versioned, and governed with the same discipline as data pipelines.

These signals point to the same conclusion: meaning must be made explicit.

However, most implementations remain incomplete. Semantic layers are typically built within platforms rather than independent of them. Fabric IQ is tied to Microsoft Fabric, Palantir’s ontologies exist within Foundry, and similar patterns exist across other tools in the modern data stack.

These approaches improve consistency, but they introduce a new dependency. Institutional logic becomes bound to infrastructure. If platforms change, logic must be rebuilt. If multiple platforms coexist, meaning fragments again.

This is semantic architecture, but not sovereign architecture.

True sovereignty requires that the semantic foundation exist independently of the tools that consume it. It must be enterprise-owned, vendor-accessible, and platform-agnostic. The distinction is critical: platform-dependent semantics reduce fragmentation at the data layer but create lock-in at the semantic layer, whereas sovereign semantics preserve institutional identity across tools.

Path 3 begins with a structural decision to formalize institutional logic before scaling AI. The enterprise defines decision boundaries, trade-off hierarchies, semantic contracts, escalation paths, and operational constraints, not as documentation, but as architecture.

This architecture is what I define as the Digital Substrate Identity Layer (DSIL™).

DSIL™ sits beneath execution and above raw data. It is the layer where institutional identity is encoded as a machine-readable structure, independent of any single platform.

Over time, vendors continue to accelerate delivery, but they build on DSIL™ rather than define it. External systems consume institutional logic rather than reshape it.

Meaning stabilizes across the enterprise. Definitions persist across domains, trade-offs remain consistent, and decision logic becomes portable across tools.

Five years later, the enterprise scales with sovereignty. Vendors can be replaced without reconstructing identity, intelligence expands without distorting meaning, and differentiation is preserved.

The enterprise defines rather than inherits, scales without fragmenting, and remains institutionally distinct.

Why Semantic Continuity Matters

For years, semantic drift was tolerable because humans compensated for it. They interpreted differences, aligned context, and corrected inconsistencies in real time.

AI changes the operating conditions. When intelligence participates in execution, definitions propagate across systems, thresholds become automated, and inconsistencies compound at machine speed. Meaning no longer remains local; it scales.

There is a common assumption that consistency will improve over time through governance or integration. It does not. Without an explicit substrate, scale amplifies divergence.

Path 1 loses semantic continuity through vendor mediation, Path 2 loses it through fragmentation, and only Path 3 preserves it through design.

Semantic continuity is not emergent; it is engineered.

What Makes a Path Infrastructure

These paths do not remain transitional. They harden. Identity decisions become embedded in systems, workflows, models, and governance structures, and reversing them requires remediation rather than design.

This is why the next 12 to 18 months matter. What stabilizes now becomes the foundation on which intelligence scales for the next decade.

The Real Risk: Convergence

The dominant concern around AI is disruption, but the more immediate risk is convergence.

When identity is not defined, it is approximated. When it is approximated, it is standardized. When it is standardized, differentiation erodes. The enterprise continues to operate, but no longer operates as itself.

Path 1 converges toward vendor defaults, Path 2 fragments without a shared identity, and Path 3 preserves differentiation through explicit institutional definition.

AI will not erase most enterprises. It will standardize them.

DSIL™: The Architecture of Path 3

Path 3 requires a structural layer that most enterprises do not yet have, not a platform, not a governance framework, and not a collection of models, but a substrate.

The Digital Substrate Identity Layer (DSIL™) formalizes institutional identity as machine-readable architecture, encoding decision boundaries, trade-off hierarchies, semantic contracts, operational constraints, and responsibility structures.

It acts as the semantic contract across domains, the anchor for governance at runtime, and the structure that allows intelligence to scale without distortion. Systems consume DSIL™; they do not redefine it.

Without DSIL™, vendors define institutional logic, domains fragment it, and systems reinterpret it. With DSIL™, execution accelerates on a sovereign substrate, meaning remains stable, and identity is preserved.

The Window Is Narrowing

Most enterprises will drift toward Path 1 or Path 2 by default, because one feels like progress and the other feels like autonomy. Both are structural traps.

Path 3 requires intentional design, specifically the formalization of institutional identity through DSIL™ before delegation stabilizes into infrastructure.

The next 12 to 18 months will determine which path becomes operational reality. After that, reconstruction becomes remediation.

The Real Decision

This is not a decision about tools, platforms, or models. It is a decision about authorship.

Does the enterprise define itself, or does it inherit its identity from the systems it adopts?

Because in the age of AI, identity is no longer implicit. It is either designed or absorbed, and that distinction determines whether the enterprise remains distinct as it scales intelligence.

Next

The next article will move from principle to implementation, detailing the components of DSIL™ architecture, how to formalize decision boundaries and trade-off hierarchies, how to build semantic contracts that preserve meaning across systems, and how to operationalize governance at runtime.

The methodology exists, and the window to apply it is narrowing.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Sources by Topic

Path 1: Vendor-Mediated Identity

Palantir:

1. https://www.fool.com/investing/2025/12/17/2025-defining-year-palantir-takeaway-2026/

2. https://www.everestgrp.com/palantir-inside-the-category-of-one-forward-deployed-software-engineers-blog/

3. https://www.bain.com/about/media-center/press-releases/2026/bain--company-announces-expansion-of-lead-global-management-consulting-partnership-with-palantir-to-bring-world-industry-leading-ai-transformation-capabilities-to-clients/

Salesforce: 4. https://www.deloitte.com/global/en/about/analyst-relations/idc-marketscape-worldwide-salesforce-implementation-services-2025-2026-vendor-assessment.html 5. https://www.pwc.com/gx/en/about/analyst-relations/2025/idc_ww_salesforce_2026.html

Path 2: Fragmented Identity

6. https://venturebeat.com/data/enterprise-ai-agents-keep-operating-from-different-versions-of-reality (VentureBeat - multi-agent problem)

7. https://www.atscale.com/blog/why-ai-redefined-the-semantic-layer/ (Tony Baer/AtScale semantic drift)

8. https://www.weforum.org/stories/2026/01/how-to-make-ai-work-in-your-enterprise-through-integration-and-not-silos/ (World Economic Forum - fragmentation costs)

9. https://noah-news.com/fragmented-software-environments-hinder-enterprise-ais-potential-for-seamless-operations/ (NFON AG quote)

10. https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html (Deloitte 2026 State of AI)

Path 3: Sovereign Identity - Market Recognition

11. https://www.atscale.com/blog/semantic-layer-2025-in-review/ (AtScale 2026 State of the Semantic Layer)

12. https://www.apporchid.com/blog/from-promise-to-proof-what-enterprise-ai-must-deliver-in-2026 (App Orchid)

13. https://venturebeat.com/data/enterprise-ai-agents-keep-operating-from-different-versions-of-reality (Microsoft Fabric IQ)

14. https://www.techbuddies.io/2026/03/19/microsofts-fabric-iq-aims-to-give-enterprise-ai-agents-a-shared-version-of-reality/ (Fabric IQ analysis)

15. https://blog.fabric.microsoft.com/en-us/blog/introducing-fabric-iq-the-semantic-foundation-for-enterprise-ai/ (Microsoft Fabric IQ launch)

16. https://powerbi.microsoft.com/en-us/blog/semantic-layers-the-foundation-of-enterprise-ai/ (Microsoft semantic layer blog)

Additional Context

17. https://www.intelligentcio.com/north-america/2025/12/24/enterprise-ai-and-agentic-software-trends-shaping-2026/ (Enterprise AI trends)

18. https://rtslabs.com/enterprise-ai-roadmap/ (Enterprise AI roadmap failures)

19. https://www.cio.com/article/4106578/2026-the-year-of-scale-or-fail-in-enterprise-ai.html (CIO - scale or fail)

Subscribe now

Share

Leave a comment

This essay is part of the Enterprise Identity Imperative series. If you are reading this for the first time, the series builds the structural case for why AI transformation requires enterprises to formalize, encode, and protect their institutional identity.

You’ve now seen how institutional identity, articulated through six core elements (value, actors, work, information, responsibility, change), can be made explicit and portable through DSIL™ (Digital Substrate Identity Layer™).

*DSIL™ (Digital Substrate Identity Layer™) encodes institutional identity into semantic contracts, explicit, enforceable definitions that systems can operate within, preserving organizational sovereignty as AI scales.*

Enterprise Foundations Strategy Digital Identity Must Be Sovereign

You’ve made DSIL™ portable. That is the breakthrough. It is also the new risk.

Portable identity is extractable identity. If your decision substrate is not owned by the enterprise, it will be absorbed by the tools that operate on it. Your trade-offs become their defaults.

DSIL™ encodes how your institution actually operates: its risk appetite, judgment boundaries, and trade-offs. Your peers use the same models and data. This is what differentiates you. When that logic lives inside a vendor platform, it begins to align with shared defaults. Over time, the distinction erodes.

You can adopt tools. You cannot delegate how decisions are made. DSIL™ is where thresholds, escalation paths, and decision boundaries are defined. That layer must exist as institutional policy. Not as a configuration inside a system you do not control.

Institutions outlive tools, systems, and leadership cycles. If the identity layer exists only within a platform, it resets whenever the platform changes.

This is why sovereignty is structural. DSIL™ must exist independently of the tools that use it. Accessible to many systems, owned by the enterprise, defined by none. Because the moment identity is tied to a system, it no longer travels on its own. It is carried. And what is carried can be reshaped.

The architecture question

Sovereignty is not a philosophical position. It is an architectural requirement.

DSIL™ artifacts, semantic contracts, foundational data products, and decision libraries must live in structures that no single tool owns. That means standards-based representations: graph and ontology formats, open schemas, APIs that multiple systems can query without capturing. The test is simple. If you cannot export your identity layer and replay it in a different environment, you do not have sovereignty. You have dependency dressed as integration.

Storing DSIL™ inside a proprietary platform is the equivalent of keeping your financial ledger inside a vendor’s interface with no export capability. The data exists. You cannot verify it, audit it, or move it without the vendor’s cooperation. Most enterprises would not accept that condition for financial records. They accept it for decision logic without recognizing what they have conceded.

Sovereign storage requires the same discipline applied to regulated records: explicit retention policies, controlled access, and clear separation from experimental environments. The identity layer is not a sandbox. It is not a configuration file. It is institutional policy in encoded form. It must be governed as such.

Tools will change. The stack will change. The identity layer must persist across those changes without requiring reconstruction each time.

The role this requires

Portable, sovereign identity does not govern itself. It requires a function.

This is the structural argument for a Chief Enterprise Identity Officer (CEIO). Not a title added to an existing remit. A distinct function with a defined scope.

The CEIO does not own AI. Ownership of AI is the wrong frame entirely. The CEIO owns the substrate: the DSIL™ layer, its definitions, its contracts, its decision parameters, and the governed evolution of these over time.

The function sits above individual tools and vendors. It connects to risk, finance, legal, and operations, not as a service function but as a peer. It is responsible for ensuring that the portable identity layer remains a first-class institutional asset rather than a byproduct of tool-level implementation decisions.

If CIOs run pipes and platforms, and CROs calibrate risk exposure, the CEIO ensures the decision substrate remains legible, governed, and owned. That the institution knows what it has encoded, where it lives, who can change it, and under what conditions.

Without this function, sovereignty degrades. Not through a single decision. Through accumulation. Each integration adds a dependency. Each configuration choice embeds a vendor assumption. Each tool change requires a negotiation about what the enterprise actually defined and where that definition now lives. The CEIO exists to prevent that accumulation from becoming structural.

The legal frontier

Data privacy law protects individual identity from organizational appropriation. No equivalent protection currently exists for organizational identity from AI appropriation.

This is the next legal frontier in enterprise AI, and most institutions are not positioned for it.

When a vendor’s model is trained across multiple clients, the operational logic that those clients encoded does not disappear. It becomes part of a shared pattern space. The resulting homogenization is not incidental. It is an architectural consequence of how large models absorb and generalize from the data and configuration they process. Enterprises that have not explicitly defined and protected their decision substrate have no evidentiary basis on which to assert that their logic was distinct, sovereign, or appropriated.

Enterprises building DSIL™ now are creating that evidentiary record. Explicit definitions, governed contracts, timestamped evolution. The infrastructure of a future protection claim, built as operational practice before the regulatory requirement exists.

This argument was developed in the context of the broader thesis submitted to Harvard Business Review: that intelligence is not the hard part of AI transformation. Structural integrity is. The legal dimension of institutional identity is one of several frontiers that this thesis opens. Enterprises that treat their decision substrate as a protectable asset today are building the evidentiary foundation that emerging regulatory frameworks will eventually require.

What sovereignty produces

When DSIL™ is both portable and sovereign, the enterprise continues to behave like itself across tools, domains, and change.

Decision logic is explicit. Accountability is encoded. New initiatives attach to an existing identity layer rather than reconstructing the context from scratch. Identity evolves without fragmenting. The institution does not need to rediscover what it is every time the technology landscape shifts.

This is the compounding effect that portability alone cannot produce. Portability makes identity reusable. Sovereignty makes it durable. Together, they allow the enterprise to build on itself rather than starting over.

The competitive consequence is structural. Enterprises that establish sovereign identity early operate from a compounding advantage. Every system they add, every domain they extend, every capability they deploy draws on a layer that already exists and already reflects who they are. Enterprises that do not establish this layer face the same integration costs repeatedly, with no accumulation.

Differentiation in an AI-saturated market will not come from the models. Every institution will have access to capable models. It will come from the decision substrate that those models operate on. The institutions that have encoded their own substrate, protected it, and governed its evolution will behave distinctly. The institutions that have not will converge.

The requirement

Any enterprise operating with AI must define and protect its decision substrate: how it makes decisions, how it interprets risk, how it applies judgment, how it balances trade-offs across domains. Without that, differentiation does not hold. The enterprise operates on logic it did not choose and cannot audit.

DSIL™ is the methodology for encoding that substrate with the precision that portability and sovereignty both require. Not as documentation. Not as a governance artifact that sits outside operational systems. As a layer that travels with execution, remains institutionally owned, and evolves under deliberate control.

DSIL™ makes identity portable. Sovereignty ensures it remains yours.

Identity must travel. It must also be protected.

If this argument connects with work you are doing in your organization, the Enterprise Identity Readiness Assessment is available at https://fdp-blueprint-site-annajny.replit.app/toolkit#assessment

The next essay in this series addresses the benefits DSIL™ produces once sovereignty is established.

And if you are interested, I can share how your digital identity should be stored in practice.

Enterprise Foundations Strategy is a series on the structural conditions that determine whether AI transformation produces durable institutional capability or compounds existing incoherence.

#EnterpriseIdentity #DSIL #AIStrategy #EnterpriseAI

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Subscribe now

Share

Leave a comment

For decades, identity passed through people. A senior underwriter carried the organization’s risk appetite in her head. A claims manager knew which exceptions the company tolerated and which the policy forbade. A pricing director understood the competitive-positioning trade-offs that had never appeared in any documented framework. The organization remained coherent because these people were present, accessible, and willing to reconcile ambiguity when it arose.

That model has a structural limitation. It does not scale. It does not survive reorganizations, retirements, or the introduction of AI systems that need to reason across domains simultaneously without a human intermediary at every decision point.

Portability is what replaces the intermediary. When institutional identity is portable, it travels with the work rather than with the people who understand it.

What portability means.

Portability is not documentation. A policy manual is not portable. A governance framework is not portable. These are records of decisions: they describe what the organization has decided without encoding how those decisions should propagate across new contexts, systems, and domains.

Portable identity is identity encoded in a form that systems can consume, act on, and carry forward without human reinterpretation at each boundary crossing.

DSIL™ achieves portability through three mechanisms that work together as a single system:

Semantic contract templates define how core concepts are defined and governed. A semantic contract for “approved customer” does more than define the term. It specifies who owns the definition, which domains it applies to, what it means in each domain, what triggers a review of the definition, and how changes are versioned and communicated. The template structure allows every domain to adapt the contract to its specific context without departing from the institutional meaning it was designed to carry. Claims uses the same approved customer logic as KYC. The definition is portable. The adaptation is local. The meaning is consistent.

Foundational data products carry institutional context across consumption points without requiring each consuming system to reconstruct that context from source data. A foundational data product built on the DSIL™ substrate carries its semantic contract with it: what the data represents, who owns the definition, what assumptions are embedded, what the data can and cannot be used for, and what the quality and lineage record says about its trustworthiness. Downstream systems (analytics pipelines, AI models, decision engines) consume meaning rather than raw data. The context travels with the product rather than being relearned at each point of consumption.

Decision boundaries, as parameters, translate institutional trade-offs into operational logic that systems can apply consistently across domains. Risk tolerance becomes a threshold. Escalation logic becomes a workflow parameter. Competitive positioning trade-offs become optimization constraints. These are not hardcoded rules. They are parameterized expressions of institutional intent that can be updated centrally when intent changes and then propagated to every system that consumes them, without requiring each system to be individually reconfigured.

What breaks without portability.

The insurance claims domain illustrates the cost of non-portable identity precisely because claims processing is high-volume, high-stakes, and highly dependent on consistent interpretation of shared concepts across multiple functions.

Without DSIL™ portability, the claims graph looks like this: each domain defines its own version of core concepts. Fraud definitions diverge from legal definitions. Risk thresholds in claims do not align with those encoded in the underwriting model that approved the policy. Customer identity in the claims system does not match the customer identity in the CRM. Every boundary crossing requires reconciliation. Reconciliation requires human judgment. At claims volume, human judgment requires staff whose primary function is managing the semantic fragmentation that should never have existed.

The operational signature of this condition: exceptions proliferate, manual reconciliation becomes a permanent workflow rather than an edge case, and automation initiatives consistently produce results that cannot be trusted across domains because the definitions those initiatives rely on are locally valid yet institutionally incoherent.

With DSIL™ portability, the same claims graph operates under shared semantic contracts. Fraud, risk, and customer definitions are portable across claims, underwriting, and CRM because they are built on the same DSIL™ substrate. Decision boundaries propagate from the enterprise to the domain level via parameterized contracts rather than human coordination. Auto-escalation rules reflect institutional risk appetite rather than local manager judgment. The result is institutional coherence at the point of execution.

Portability as infrastructure.

The shift from implicit to portable identity is architectural, not procedural. Once institutional identity is encoded in portable semantic contracts, foundational data products, and parameterized decision boundaries, it becomes infrastructure: deployed once, consumed everywhere, updated centrally, and versioned continuously.

This condition makes AI deployment coherent rather than locally optimized. An AI system consuming a DSIL™-certified foundational data product is not approximating institutional intent from available data. It operates on institutional intent explicitly encoded by its owners. The AI executes the organization’s judgment, not a statistical inference about what that judgment might be.

The distinction compounds over time. Every AI deployment that builds on portable identity strengthens the coherence of prior deployments. Every AI deployment that builds on locally defined, unportable definitions deepens the fragmentation of prior ones.

Portability is not a feature of mature AI programs. It is a prerequisite for them.

The DSIL™ Toolkit.

The portability templates (semantic contract templates, foundational data product frameworks, and decision boundary parameter structures) are available for download, adaptation, and execution on foundationaldataproducts.com.

The toolkit provides the starting point. The institutional work of populating it with your organization’s definitions, trade-offs, and decision logic produces a DSIL™ substrate that is genuinely yours, rather than a generic approximation of your industry.

This is part of the Enterprise Identity Imperative series. The next post examines the operating system that runs on the DSIL™ foundation and how EDAOF converts portable identity into certified data products that AI can reliably consume.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

The problem is not that the elements are missing. The problem is that they remain implicit.

When elements remain implicit, they function as organizational culture: understood by experienced people, absorbed through proximity, and reconciled through judgment when interpretations diverge. Culture is not a failure mode. It is a coherence mechanism that worked well in environments where human interpretation was the primary execution layer.

AI is a distinct execution layer. It does not absorb culture. It requires structure.

The threshold that changes everything.

There is a specific threshold at which implicit identity becomes structurally dangerous rather than merely inefficient.

The threshold is crossed when AI begins participating in decisions that previously required a human to exercise institutional judgment. Before that threshold, implicit identity is absorbed by the human making the decision. The person knows that “approved customer” means something different in the claims context than in the marketing context and applies the appropriate interpretation without being told. The inconsistency never surfaces because it never has to.

After that threshold, the inconsistency becomes consequential. The AI system processing “approved customer” has no mechanism to incorporate contextual judgment. It applies whatever definition it was given or infers one from the data it was trained on. If the definition was never made explicit, the inference reflects statistical patterns rather than institutional intent.

This is not a technology problem. It is an architectural problem. The technology is functioning exactly as designed. The architecture is missing.

What making identity architectural requires.

The six elements become architecture when three conditions are met.

They must be explicit. Explicitness goes beyond documentation. A strategy document that describes how the enterprise creates value is not explicit in the architectural sense. Explicit means encoded in a form that a system can consume and act on without requiring a human to interpret it first. The definition of “customer” is not explicit until it exists as a semantic contract with an owner, a domain scope, a versioning history, and a specified set of consuming systems. Before that, it is an intention.

They must be machine-interpretable. Machine-interpretability is the criterion that separates identity-as-culture from identity-as-architecture. When the enterprise’s risk appetite is encoded as a confidence threshold that an AI system can read and apply, it has moved from cultural understanding to an operational parameter. When escalation logic is encoded as a workflow that a system can execute, it has moved from managerial judgment to institutional infrastructure. The test is whether a system can act on it without a human intermediary. If it cannot, it is not yet architecture.

They must be governed as infrastructure. Infrastructure governance means the identity layer has an owner, a change process, a versioning discipline, and a monitoring mechanism. When a semantic definition changes, the change is intentional, visible, and propagated to every system that consumes it. When a decision boundary is updated, the update is versioned, and every decision made under the prior version remains traceable to it. Governing identity as infrastructure prevents the architecture from drifting back toward implicit understanding over time.

What DSIL™ makes possible.

The Digital Substrate Identity Layer™ is the architectural layer where the six elements cross the threshold.

DSIL™ does not create the six elements. They already exist. What DSIL™ does is make them load-bearing: explicit enough for systems to consume, machine-interpretable enough for AI to act on, and sufficiently governed to withstand the changes every living enterprise undergoes.

When value is encoded in DSIL™, it takes the form of a set of machine-readable definitions that specify how the enterprise creates value across domains: definitions that AI systems can use to evaluate whether a proposed action aligns with institutional intent.

When actors are encoded, they exist as structured representations of the relationships, obligations, and authority that govern how participants in the enterprise interact: representations that AI systems can use to determine who should be involved in a decision and what their role requires.

When work is encoded, it exists as explicit decision logic, process definitions, and control structures that AI systems can execute rather than approximate: the difference between an AI operating within institutional logic and one inferring it.

When information is encoded, it takes the form of semantic contracts that make meaning portable across domains: the condition that allows the same concept to mean the same thing in risk, finance, operations, and any AI system that consumes data from all three.

When responsibility is encoded, it becomes an explicit accountability model that specifies who owns which decisions, what authority they hold, and what escalation paths apply when a decision exceeds the authority of the automated layer.

When change governance is encoded, it becomes a versioning and update process that allows the identity layer to evolve without breaking the systems that depend on it: the condition that makes the architecture survivable rather than brittle.

The design question.

The practical question is not whether to make institutional identity architectural. The inflection we described earlier settles that question: enterprises that defer this work will find it progressively more expensive to do as AI deployment embeds assumptions that were never explicitly authorized.

The practical question is where to start.

The answer is the element that carries the most dependency: the concept, the decision boundary, or the accountability structure that the most systems, workflows, and AI deployments currently rely on without an explicit, owned definition.

In financial services and insurance, that element is almost always information: the semantic definitions of core business concepts that every system in the enterprise touches. Customer, risk, product, policy, and claim: these concepts are consumed everywhere, defined nowhere explicitly, and reconciled constantly through human judgment that AI cannot replicate.

Starting with information means starting with semantic contracts for the enterprise’s most consumed concepts. Each contract is fully specified, with an owner, a domain scope, a versioning discipline, and a set of consuming systems identified. That is the first load-bearing piece of the architecture. Everything else is composed from it.

The transformation is not inventing something new. It is making the existing institutional structure legible: first to those who operate within it, then to the intelligence systems that will operate alongside them.

The operating system that converts this architecture into certified data products and enables AI to reliably consume institutional identity at scale is the subject of the next post.

This is part of the Enterprise Identity Imperative series. The next post introduces the operating system that runs on the DSIL™ foundation and converts encoded identity into certified data products that AI can reliably consume.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Very few things work exactly as the documentation suggests.

Processes are in place, but the true process often lies in how people interpret them. Definitions are available, but teams quietly modify them based on context. Policies are established, but experienced employees know when exceptions are valid.

Over time, people understand how the institution truly functions.

A senior manager recognizes the most important escalation paths. An analyst understands the key metrics that leadership values. A compliance officer can sense when intervention is needed, even if the rulebook doesn’t specify it.

Institutional knowledge spreads through experience, conversation, and proximity.

This method worked for decades.

Organizations didn’t need to fully digitalize their operating logic because people retained that knowledge mentally. When ambiguity arose, humans resolved it. When definitions conflicted, someone with context intervened.

The enterprise stayed consistent because people kept interpreting it.

THEN AI CHANGED THE OPERATING CONDITIONS

When intelligence participates in execution, in pricing, underwriting, routing, compliance, and capital allocation, the enterprise can no longer depend on implicit interpretation to preserve its identity.

Systems require structure.

Without it, various parts of the enterprise start creating different versions of the institution. Over time, these differences grow more pronounced. The organization that implemented AI is not the same organization that AI eventually reflects.

This is a structural problem.

ENTERPRISE DIGITAL IDENTITY (EDI)

Before naming the elements, a definition is necessary.

Enterprise Digital Identity is not a brand, culture, or identity and access management.

It is the enterprise's operational structure, made clear in a way systems can understand. It encodes the business processes by which the enterprise operates, the data that supports those processes, the relationships between data and decisions, the producers and consumers of meaning across domains, the dependencies and interlocks that govern how workflows are executed, and the authority structures that determine who owns what.

Every operational enterprise has this structure. None has intentionally digitized it.

That absence is what AI exposes.

Institutional identity is sustained by six structural elements. They do not need to be created anew. They already exist within every functioning organization, in policy documents, org charts, operating procedures, and the informal knowledge held by experienced people.

What changes with AI are not the elements themselves. It is the requirement that those elements be digitized: made explicit, governed, and machine-readable so that systems can operate within institutional logic rather than approximate it.

In my work, I refer to the process of encoding this structure as the Digital Substrate Identity Layer (DSIL) - the layer that makes institutional identity legible to machines.

THE SIX ELEMENTS

The following elements form the institutional identity as an operational framework. Each must be encoded before any intelligence system can operate within the enterprise’s logic rather than around it.

These are not abstract dimensions. They are the load-bearing structures of every enterprise. They already exist. The work of institutional identity is not creating them. It is encoding them precisely enough that a system, not a person, can operate within their logic.

WHY IMPLICIT IDENTITY IS NO LONGER SUFFICIENT

The reason these elements have remained implicit for so long is that implicit worked.

Human judgment is an extraordinary interpreter. A senior underwriter does not need a formal definition of “customer” to know which relationships carry liability. A compliance officer does not need a structured escalation map to know when to escalate.

Experience compresses institutional logic into reliable intuition.

That compression is invisible. It is also irreproducible.

When AI enters execution, the enterprise discovers this gap. An intelligence system operating on the definition of “customer” encoded in the CRM encounters a different definition in the risk system and a third in the compliance register.

A human analyst would reconcile these through institutional knowledge and informal escalation. The system cannot. It picks one, infers from patterns, or fails.

We are moving from a world where data was explained to one where it must explain itself. That shift has profound implications for how enterprises design knowledge, data, and AI platforms.

The enterprise never encoded which definition was authoritative. It never had to. Now it does.

The six elements make this explicit. They surface what was always there and give it form that intelligence can operate within.

EACH ELEMENT IN PRACTICE

Value

Value is the first element because it is the governing constraint.

An AI system reasoning about a pricing decision without access to the product’s risk exposure profile is not making a business decision. It is making a statistical inference that resembles one.

Value, encoded as institutional identity, comprises the revenue logic, cost structure, risk exposure, and regulatory obligations that define what the enterprise is for and what it must protect. Not as stated strategy. As an operating constraint.

Actors

Actors define the universe of participants and the terms on which they participate.

The distinction between a customer and a counterparty is not semantic. In a regulated context, it determines what disclosures are required, what actions are authorized, and who bears liability.

Actors must be encoded on governed terms, with explicit consent states, decision rights, and defined AI permissions, rather than inferred from behavioral patterns or derived from incomplete records.

Work

Work is the decision anatomy of the enterprise.

Every process has trigger conditions, authority levels, exception paths, and escalation structures. When these are not encoded, AI systems operate without institutional boundaries. They execute within the space where accountability was never defined.

The result is not a malfunction. The result is an action that no one intended to authorize.

Information

Information is the semantic contract between the enterprise and its systems.

Every organization has this problem at scale: the definition of a core concept differs across departments, systems, and time. Human analysts resolve these conflicts through institutional knowledge and informal escalation. AI cannot.

It needs a governed statement of which source is authoritative, at what granularity, under what conditions, and how drift is detected when definitions evolve without structural change.

Responsibility

Responsibility encodes the ownership and accountability map that determines what is delegable and what is not.

Every enterprise has decisions that cannot be automated because the irreversibility of an error exceeds what any automated system should be permitted to risk. These boundaries must be made explicit.

An AI system that expands into areas lacking responsibility will make decisions nobody planned to approve, and no one knows how to review.

Change

Change is the sixth element and the least discussed.

It encodes the governance of evolution: what may change, who must authorize it, under what conditions, and what downstream systems must be notified when it changes.

Without it, the other five elements decay. Definitions drift without detection. Authority maps become stale. The institution encoded at deployment is no longer the one that exists in production.

Encoding these six elements across the enterprise is not a documentation exercise. It is architectural work.

The methodology I use to perform this encoding is called the Digital Substrate Identity Layer (DSIL).

DSIL translates institutional identity - value, actors, work, information, responsibility, and change into governed, machine-legible artifacts that downstream systems can consume.

THE TRANSFORMATION IS NOT INVENTION

Institutions already operate through these structural elements. They always have.

They are the scaffolding that every functioning organization has constructed over time, through policy, through precedent, through the accumulated decisions of people who understood what the organization was and what it was for.

What AI changes is the environment.

Systems require those elements to be digitalized: explicit, governed, and machine-interpretable. The transformation is not inventing something new. It is digitalizing the existing institutional structure, making it legible to itself and to the intelligence systems that will operate within it.

When these elements remain implicit, different systems inherit different interpretations of the enterprise. When they are digitalized, the institution becomes legible to itself. Only then can intelligence participate without distorting the organization it serves.

This is the work that precedes AI deployment. Not model selection. Not infrastructure modernization. The work of making the enterprise knowable to itself.

Enterprise Digital Identity is the target state. The six elements, digitized across the enterprise, constitute its EDI. But EDI does not emerge from data infrastructure. It does not fall out of a knowledge graph project or a semantic layer initiative. It is produced through deliberate methodology: through the structured encoding of value, actors, work, information, responsibility, and change into governed, machine-legible artifacts.

The Digital Substrate Identity Layer™ (DSIL™) is that methodology. Every downstream layer, the semantic layer, the knowledge graph, the context engine, and the agent runtime consumes EDI as input. None can produce it.

Build the knowledge graph before the EDI work is done, and the graph becomes a sophisticated container for institutional incoherence. Produce EDI through DSIL™ first, and the graph becomes an authoritative representation of the enterprise.

This is not a sequencing preference. It is a structural dependency. AI infrastructure requires institutional identity as input. Institutional identity requires deliberate methodology to produce. The sequence cannot be reversed.

WHAT COMES NEXT

The six elements are the foundation. But foundation work alone does not produce enterprise intelligence.

Once digitalized, the elements must be governed, owned, versioned, and maintained against drift. They must become the substrate on which every subsequent layer is built: the semantic layer, the knowledge graph, the context engine, the agent runtime.

Only then can enterprise intelligence operate within institutional logic rather than approximate it.

AI Transformation fails because institutions never encoded what they are.

Next: Why institutional identity must eventually become architecture.

WHAT THE RESEARCH REVEALS

The argument above is structural. What the research reveals is that the infrastructure ecosystem is converging on the same conclusion, from the outside in.

• Knowledge graphs are moving from experimental to foundational. The 2026 enterprise knowledge graph market has reoriented around one central problem: AI systems hallucinate and drift when they lack semantic grounding. GraphRAG, retrieval-augmented generation built on semantic knowledge backbones, is emerging as the dominant architectural pattern for regulated industries. The reason is straightforward: graph structure preserves relationships, causality, and business context that disappear when data is flattened into tables.¹ But every knowledge graph presupposes the existence of authoritative definitions. The graph cannot determine which definition of “customer” governs when the credit function and the legal department disagree. That determination is institutional, not technical.

• Semantic infrastructure is collapsing the distinction between human and machine consumers of enterprise data. Enterprise Knowledge’s February 2026 analysis articulates the shift precisely: whereas people can infer meaning from fragmented content or tribal knowledge, AI solutions need content and data that is granular, self-describing, consistent, and structurally complete.² The enterprise that cannot satisfy this requirement at the level of its core operational concepts, its value structure, its actor definitions, and its decision authority is not AI-ready. It is AI-adjacent.

• RAG architectures are exposing governance as the primary failure mode. A December 2025 analysis of enterprise RAG deployments found that 40 to 60 percent fail to reach production, not because of model quality but due to governance gaps and the inability to explain decisions to regulators.³ The institutions that succeed treat knowledge infrastructure as a first-class architectural concern, not an afterthought. The ones that fail treat it as a retrieval problem. The distinction maps precisely onto the six elements: retrieval is Information. The failure mode is the absence of encoding for Value, Work, Responsibility, and Change that would make the retrieved content authoritative rather than merely relevant.

• Regulators are examining the same structural dimensions. Financial services regulators in 2026 have shifted from guidance to proof. The SEC, FINRA, and their counterparts are expected to examine how firms document AI use, supervise AI-generated outputs, and maintain clear lines of individual accountability.⁴ The examination framework maps onto the six elements with uncomfortable precision: Value is the business model under examination; Actors are the organizational structure and counterparty definitions; Work is the decision workflow and operational controls; Information is the data lineage and reporting accuracy; Responsibility is the governance, accountability, and escalation structures; Change is the model governance and policy update process. Regulators are not asking about AI. They are asking whether the enterprise knows what it is.

The convergence risk is institutional, not technical. As AI infrastructure becomes more accessible and powerful, enterprises face a structural temptation: deploy first, govern later. The research is consistent in its conclusion. Enterprises that deploy AI systems without encoding their institutional identity do not produce better outcomes. They produce plausible ones, outputs that resemble institutional logic without being grounded in it. Over time, the distinctiveness erodes. The organization that deployed a generic intelligence system begins to resemble every other organization that deployed the same system. The convergence is gradual. By the time it is visible, it has already shaped decisions that cannot easily be undone.⁵

NOTES

1. Graphwise and Enterprise Knowledge, “Enterprise AI and Agentic Software Trends Shaping 2026,” Intelligent CIO, December 2025. Galaxy, “Top Knowledge Graph Platforms for Enterprise Data Intelligence 2026,” January 2026.

2. Enterprise Knowledge, “Understanding the New Knowledge, Data, and AI Ecosystem: Trends in Enterprise AI Architecture,” February 2026.

3. NStarX, “The Next Frontier of RAG: How Enterprise Knowledge Systems Will Evolve 2026–2030,” December 2025.

4. Smarsh, “2026 Regulatory and Compliance Predictions: From Recalibration to Execution,” January 2026. Corporate Compliance Insights, “2026 Operational Guide to Cybersecurity, AI Governance and Emerging Risks,” January 2026.

5. ETR, “Top 10 Enterprise Technology Trends for 2026,” January 2026. Truyo, “AI Governance 2026: The Struggle to Enable Scale Without Losing Control,” December 2025.

Anna Jibgashvili is an enterprise data and AI strategist focused on the structural foundations required for organizations to operate with AI. She is the originator of the Digital Substrate Identity Layer™ (DSIL™) methodology and the Foundational Data Products™ framework. 2026

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

Subscribe now

Share

Leave a comment

The gap between what an organization knows about itself and what it has encoded in terms a machine can reason within is where many AI transformations quietly fail. Not at the model level. Not at the infrastructure level. At the level of institutional identity.

Most enterprises assume the primary challenge of AI adoption is technical: selecting the right model, modernizing the data platform, or building reliable pipelines for training and inference. These are important problems, but they are not the deepest ones.

The deeper challenge is that intelligence systems must operate within the logic of the enterprise itself. And that logic often exists only implicitly.

The Judgment Gap

When humans run an organization, ambiguity can be absorbed through judgment. Leaders reconcile inconsistencies through context and experience. When definitions drift, someone notices. When trade-offs emerge, they are negotiated. The organization functions because interpretation bridges the gaps between systems, processes, and intentions.

Machines cannot do this.

An intelligence system operating inside an enterprise must reason within structures that have been made explicit.

To function safely, it must understand how the enterprise creates value, not simply as a revenue figure, but as a governing logic. What drives value, what constrains it, and which risks are acceptable at what cost?

It must understand who the enterprise serves and on what terms, because a customer is not a database record. A customer is a legal entity with a consent state, a risk profile, and a lifecycle that determines what the organization may and may not do.

It must understand how decisions are constructed: what triggers them, where authority resides, when human judgment is required, and what constitutes an exception.

It must know which information is authoritative, who owns each definition, how those definitions propagate through systems, and what happens when they drift.

And it must operate within a clear accountability map, because intelligence that scales without knowing who is responsible for what will inevitably begin to act in the spaces where responsibility was never defined.

None of this is data.

It is the enterprise describing itself.

What the Infrastructure Conversation Assumes

This distinction is often overlooked because the infrastructure ecosystem has focused heavily on the technical side of knowledge management.

Over the past decade, the industry has produced increasingly sophisticated tools for storing and retrieving organizational knowledge: knowledge graphs, semantic layers, vector databases, and ontology frameworks. Each of these technologies addresses a real engineering problem. They allow enterprises to structure meaning, retrieve context, and connect information across systems.¹

But they all assume something that frequently does not yet exist: a clear declaration of what the enterprise actually knows about itself, who defined it, and why those definitions are authoritative.

Before knowledge can be stored, retrieved, or reasoned over, the enterprise must decide what counts as knowledge in the first place.

This work is not technical.

It is constitutional.

It is the enterprise defining itself with enough precision that intelligence systems can operate within its logic rather than around it.

The failure mode is now well documented at the production scale. When AI agents began consuming enterprise data at operational velocity, organizations discovered that the semantic drift they had tolerated for years, conflicting definitions, inconsistent metrics, and undocumented logic, was no longer absorbable. Human judgment had been papering over institutional incoherence at every level. Remove it from the loop, even partially, and the incoherence surfaces. Not as a data quality problem.² As an institutional identity problem.

Every knowledge graph, context engine, and GraphRAG architecture presupposes something it cannot supply: that the enterprise already knows what it means by its core concepts. It has a stable, governed definition of a customer. That its understanding of risk is the same in the credit function as it is in the compliance function. That the decision authority for a given action has been made explicit somewhere, not merely assumed.

The cart-before-the-horse problem is real. But the horse is not the knowledge graph.³ The horse is the structured, deliberate encoding of enterprise identity that makes a knowledge graph mean something. Build the graph before that work is done, and you will have a very sophisticated container for institutional incoherence.

This is not a sequencing preference. It is a structural dependency. The semantics stored in a knowledge graph are only as authoritative as the governance process that produced them. Ontologies encode meaning, but they do not determine whose meaning governs when definitions conflict. Semantic layers enforce consistency, but they cannot decide which version of “customer” is correct when the legal department, the credit function, and the product team hold different answers. GraphRAG can make retrieval traceable, but it cannot make the retrieved definition authoritative if that authority was never established. These are not engineering problems. They are prior questions, about institutional identity, and they require institutional answers before technical architectures can be built on top of them.

The Five Dimensions of Enterprise Identity

Enterprise identity, as I use the term, is not a metaphor, and it is not branding. It is the structured, machine-legible expression of five dimensions that together constitute what an organization is as an operational entity. Each dimension must be encoded before any intelligence system can reason within the logic of the enterprise rather than around it.

Value. An AI system reasoning about a pricing decision that does not have access to the product's risk exposure profile is not making a business decision. It is making a statistical inference that resembles one. Value, encoded as institutional identity, means the revenue logic, cost structure, risk exposure, and regulatory obligations that define what the enterprise is for and what it must protect. Not as stated strategy. As a governing constraint.

Actors. The distinction between a customer and a counterparty is not semantic. In a regulated context, it determines what disclosures are required, what actions are authorized, and who bears liability. Actors must be defined on governed terms, not resolved from incomplete records, not inferred from behavioral patterns, with explicit consent states, decision rights, and AI permissions that reflect the legal and operational reality of each entity category the enterprise operates with.

Work. The decision anatomy that governs how the enterprise operates: the trigger conditions that initiate a process, the authority levels that govern each decision node, the exception paths that exist when standard logic fails, the escalation structures that preserve human accountability at the boundaries of automated judgment. An AI system that executes decisions without these institutional boundaries is not augmenting the enterprise. It is displacing it.

Information. Every enterprise has this problem: the customer master in the CRM says one thing, the risk system says another, the compliance register says a third. Human analysts have been resolving these conflicts through institutional knowledge and informal escalation for years. AI cannot do this. It needs a semantic contract: a governed statement of which source is authoritative, at what granularity, and how drift is detected when definitions evolve without structural change.

Responsibility. Every enterprise has decisions that cannot be automated because the irreversibility of an error exceeds what any automated system should be permitted to risk. These boundaries must be made explicit. An AI system that scales into space where responsibility was absent will make decisions that no one intended to authorize and no one knows how to audit. The responsibility dimension encodes the ownership and accountability map that determines what is and is not delegable.

These five dimensions are not a framework for thinking about AI. They are the preconditions for AI operating safely. An enterprise that has not encoded them is not AI-ready. It is AI-adjacent.

The Architectural Layer That Precedes the Others

This observation leads to a structural conclusion: enterprises require an architectural layer where institutional identity is encoded before intelligence operates at scale.

I refer to this layer as the Digital Substrate Identity Layer™ (DSIL™).

DSIL is not infrastructure. It is methodology. It converts tacit operational knowledge into explicit, machine-readable structure across the five identity dimensions. It establishes which definitions are authoritative and why. It maps decision rights and accountability structures. It encodes the irreversibility classifications that determine where human judgment must remain in the loop. It creates the semantic contract between the enterprise and its AI systems: here is who we are, what we are for, and what you are authorized to do on our behalf.

In practice, this means producing a set of governed artifacts: structured definitions of value primitives, actor primitives, work primitives, information primitives, and responsibility primitives, each with assigned ownership and change management processes that prevent silent drift. These are not documentation exercises. They are governance instruments. The difference matters because documentation is descriptive; it records what someone believed to be true at a given moment. A governance instrument is prescriptive and maintained: it determines what is authoritative, who can change it, under what conditions, and what downstream systems must be notified when it changes. Once these artifacts exist, they become the substrate on which every subsequent layer, the semantic layer, the knowledge graph, and the context engine are built and continuously validated. Without them, those layers are built on assumptions.

This does not replace data architecture or semantic systems. Those layers remain essential. What DSIL introduces is the layer that precedes them, the place where institutional logic is defined before it is stored, queried, or optimized.

Once identity is encoded, intelligence systems no longer infer meaning from statistical patterns alone. They operate within the explicit logic of the enterprise. The semantic layer community is beginning to articulate the shape of this problem: that AI must be anchored to organizational logic, not merely to data.⁴ But anchoring requires something to anchor to. That something is institutional identity. It must be constructed deliberately. It cannot be extracted from the data that surrounds it.

This is the difference between automation that reflects the institution and automation that gradually reshapes it.

The Convergence Risk

When the identity work is done, the benefits compound. Enterprises that articulate their institutional logic explicitly can deploy intelligence systems that reflect their own constraints, values, and decision patterns. The advantage becomes structurally embedded. A vendor cannot replicate it. A competitor cannot reconstruct it from models trained on generalized patterns.

When the work is not done, the opposite happens.

Enterprises gradually outsource their reasoning to systems that were never designed to reflect any particular organization. Over time the distinctiveness erodes. The convergence is gradual and largely invisible, and by the time it becomes visible it has already shaped decisions that cannot easily be undone.

The problem is not that AI systems are incorrect.

The problem is that they are contextually generic.

The market has named this risk in infrastructure terms: off-the-shelf agents will struggle in complex domains because semantics are domain-specific.⁵ This is correct as far as it goes. But the deeper version of the risk is not that generic agents will underperform. It is that they will perform well enough, and in doing so will gradually homogenize the institutional logic of every enterprise that deploys them. The outputs will be plausible. The decisions will be traceable, in a narrow technical sense. What will be lost is the organizational distinctiveness that the enterprise spent decades constructing.

The protection against convergence is not a better model. It is an enterprise that has encoded what makes it different, in terms precise enough that no model trained on generalized patterns can replicate it.

The institutional stakes here extend beyond competitive differentiation. When an enterprise operates AI systems that are not grounded in its own identity, it is not merely risking underperformance. It is delegating consequential judgment to systems whose reference frame is the statistical average of every organization they were trained on. In regulated industries, such as financial services, insurance, healthcare, and energy, this is not an abstract concern. The decisions being delegated involve credit, coverage, capital, and compliance. The accountability structures that govern those decisions exist because the costs of getting them wrong are material and asymmetric. An AI system that infers an enterprise’s values rather than operating within them is not a tool. It is an autonomous participant whose operating logic the enterprise does not fully own.

The Progression

Organizations do not arrive at enterprise intelligence by deploying AI. They arrive at it through a deliberate progression that begins with identity work and scales through five stages: manufacture context, stabilize identity, enable intelligence, enforce judgment, and preserve intent at scale.

The first stage is the hardest. Manufacturing context means translating the implicit, distributed, often contested understanding of what the enterprise is into an explicit, governed, machine-legible structure. It is slow. It is political. It requires the participation of people who carry institutional knowledge that has never been written down. It is the work that no vendor can do for you, because the definitions belong to the enterprise, and the enterprise is the only institution that knows what they mean in practice.

Stabilization follows. Manufactured context is fragile until it is governed. Stabilization means establishing ownership, accountability structures, and change-management processes to prevent semantic drift. Without it, context decays. The AI systems that depend on it begin operating against a representation of the enterprise that no longer corresponds to what the enterprise actually is.

With a stable identity infrastructure in place, intelligence can be enabled: AI systems operating with a genuine understanding of the organizational context they inhabit. Not approximating. Not inferring from fragmented data. Reasoning within the structural logic of value, actors, work, information, and responsibility that the enterprise has deliberately constructed.

As capabilities mature, judgment must be enforced: which decisions remain with humans, which can be delegated under what conditions, and what audit trails are required to maintain accountability regardless of execution mode.

Enforcing judgment is not a governance overhead. It is the condition under which automation earns its mandate. An enterprise that has encoded its responsibility primitives can make these delegation decisions explicitly and defend them. An enterprise that has not will make them implicitly, by omission, as AI systems scale into the spaces where accountability was never assigned. The distinction between deliberate and accidental delegation is not academic. In a regulatory examination, in a board inquiry, in litigation, it is the difference between a governed decision and an unexplained outcome.

The fifth stage, preserving intent at scale, is the governing challenge of AI maturity. As intelligent systems proliferate, the institutional intent encoded at the beginning must remain coherent. Definitions must not drift without governance action. The enterprise must be able to look at every decision made by every AI system operating on its behalf and trace it to an authoritative source, a governed definition, and an accountable owner.

This is not AI strategy. This is an organizational strategy. AI is the mechanism. Identity is the foundation that determines what the mechanism can safely do.

Where Transformation Actually Begins

For decades, organizations could operate effectively without formally encoding their identity. Human judgment provided the connective tissue between systems and intentions.

As intelligence systems become embedded in execution, prioritization, pricing, underwriting, routing, and capital allocation, the implicit model breaks down.

The enterprise must now be able to describe itself in a form machines can reason within.

That is where AI transformation truly begins.

Not with the model.

With the enterprise knowing what it is.

Notes

¹ Gartner projects that by 2027 more than 60 percent of enterprises will augment data platforms with semantic layers to support generative AI. The enterprise knowledge graph market has accelerated significantly in 2025–2026, with GraphRAG emerging as a dominant architectural pattern for regulated industries. Sources: Gartner Strategic Predictions 2026; Dataversity, “The 2026 Enterprise AI Horizon,” December 2025.

² AtScale’s January 2026 analysis documented how AI deployment exposed long-standing semantic drift that human judgment had previously absorbed. Their framing: AI did not introduce new data problems — it removed the buffer that had been hiding them. Source: AtScale, “What Actually Changed in 2025 and Why It Redefined the Semantic Layer,” January 2026.

³ Dataversity’s 2026 enterprise AI assessment identified the “cart-before-the-horse problem” — organizations investing in agent frameworks before establishing semantically governed foundations — and prescribed reversing the order. The argument here extends that observation: the required foundation is not the knowledge graph but the identity work that precedes it. Source: Dataversity, “The 2026 Enterprise AI Horizon,” December 2025.

⁴ Enterprise Knowledge’s January 2026 analysis documented specific AI failure modes in the absence of semantic foundations: inability to distinguish draft from final documents, version conflicts in policy retrieval, and outputs that could not be traced to authoritative sources. Source: Enterprise Knowledge, “Where AI Is Failing Organizations Without a Semantic Layer,” January 2026.

⁵ BigDATAwire’s December 2025 analysis predicted that by late 2026, the semantic layer will become as important as the database was to analytics, and that off-the-shelf agents will struggle in complex domains because semantics are domain-specific. Source: BigDATAwire, “5 Changes That Will Define AI-Native Enterprises in 2026,” December 2025.

Anna Jibgashvili is an enterprise data and AI strategy consultant, author, and founder of Enterprise Foundations Strategy. She is the originator of the Digital Substrate Identity Layer™ (DSIL™) methodology and the Foundational Data Products™ framework.

This essay is part of the series The Identity Imperative, which is part of the Enterprise Foundations Strategy series on Substack. The complete methodology, templates, and assessment tools will be available at foundationaldataproducts.com.

Digital Substrate Identity Layer™ (DSIL™) · Foundational Data Products™ · Enterprise Foundations Strategy · 2026

This essay is part of the Enterprise Identity Imperative series, which explores how enterprises must encode institutional logic before intelligence systems operate at scale.

Subscribe now

Share

Leave a comment

NVIDIA acquired a semantic layer startup whose founder built what she called an organizational single source of truth, a mechanism that makes enterprise knowledge legible to AI systems. NVIDIA publicly named the reason: the team’s expertise in building ontologies will help accelerate enterprise adoption of agentic AI.

Klarna quietly began rehiring the human customer service agents it had eliminated two years ago. The CEO publicly acknowledged that while the AI strategy saved $60 million, it cost something more valuable than $60 million. He is still trying to buy it back.

One of the world’s most valuable technology companies paid $60-75 million to acquire semantic infrastructure. A major fintech discovered it had dismantled the institutional knowledge that made it distinctively itself.

The lesson in both cases is the same.

Enterprise identity is not a philosophical concern. It is operational infrastructure. And when it is absent, intelligence scales the wrong things.

The operating conditions have changed

For decades, large institutions operated with implicit alignment. Meaning lived in people. Trade-offs were absorbed through experience. Decision context traveled upward through the hierarchy and was reconciled in rooms. The organization functioned, even when definitions varied across domains, because human interpretation preserved continuity amid ambiguity.

AI changes the operating conditions.

When intelligence participates directly in workflows, shaping priorities, approving transactions, routing cases, adjusting pricing, or executing decisions, ambiguity is no longer merely conversational. It becomes executable.

If institutional identity is not made explicit, systems draw on the most readily available structure. Risk calibrates toward statistical norms. Pricing aligns with generic benchmarks. Customer engagement optimizes for patterns rather than institutional intent. Operational logic reflects prevailing industry assumptions rather than the institution’s accumulated judgment.

Convergence does not occur because leaders choose it. It occurs because intelligence requires structure, and where structure is undefined, defaults take hold.

This is the operating condition most enterprises have not yet fully confronted. The next 12 to 18 months will make that confrontation unavoidable.

What enterprise identity actually is

Enterprise identity is not a brand. It is not culture. It is not a values statement on a wall.

It is the explicit articulation of how value is created across domains, how decisions are constructed and escalated, which trade-offs define the institution, where authority resides when automation participates, and which meanings must remain stable as systems evolve.

When this articulation is present, formalized, and maintained, an enterprise can operate coherently. Definitions travel across domains without fragmenting. Decisions made in one context remain consistent with decisions made in another. Intelligence systems, when introduced, have something real to work with.

When this articulation is absent, scattered across teams, locked in the heads of people who have been at the company long enough to know things that were never written down, the enterprise is legible only to itself. And only barely.

Klarna was legible to its human agents. They had absorbed years of institutional knowledge. They knew when to bend a policy. They knew when a customer’s tone signaled something that efficiency alone could not address. They knew the difference between what the company said it valued and what leadership actually rewarded when it mattered.

The AI agent knew none of it. It had instructions. It did not have an identity.

What losing it looks like

Klarna’s AI agent resolved tickets in two minutes instead of eleven. By any operational metric, it was extraordinary. Resolution speed increased. Cost per interaction collapsed. The CEO projected $40 million in savings, then revised upward to $60 million as the program scaled across 23 markets.

And then customers started leaving.

The agent had optimized for exactly what it had been given: speed. What had not been given was Klarna’s actual organizational intent. Build lasting relationships in a competitive fintech market where switching costs are low, and trust is the only durable differentiator. That intent lived in the institutional knowledge of the 700 human agents who were let go. When they left, they took the identity with them.

This is the mechanism of identity loss. It does not announce itself. It surfaces as declining satisfaction scores, as escalations that should not exist, as customer churn that attribution models struggle to explain because the causal chain runs through something no dashboard measures: the erosion of the institutional judgment that made the organization distinctively itself.

There is a name for what happened inside Klarna’s delegation decision. The pace of delegation outran the pace of articulation. The AI assumed execution authority over customer relationships before the institutional logic governing them had been formally articulated. The system inherited the most available structure: resolution speed as a proxy for success, because that was what had been operationalized.

Klarna is not unique. It is representative. The same dynamic operates wherever intelligence is deployed atop an enterprise that has not first made itself legible.

The AI does not fail. The AI succeeds at the wrong objective. That is harder to diagnose and far more expensive to reverse.

The delegation problem

What Klarna encountered has a structural name: the delegation paradox.

Delegation is accelerating faster than articulation.

Across enterprises, AI systems are assuming decision-making authority at a rapid pace. Approving transactions. Adjusting pricing. Routing cases. Allocating capital. Escalating exceptions. The pace of delegation is measured in quarters. The pace of institutional articulation remains measured in years.

This gap is not a technology problem. It is an identity problem expressed through technology.

When a credit model establishes thresholds for acceptable risk, it is not executing a calculation. It is operationalizing the institution’s definition of creditworthiness. When a pricing algorithm interprets competitive positioning, it is embedding the institution’s risk appetite into repeated execution. When a workforce scheduling system reconciles coverage and labor costs, it encodes the institution’s operational priorities into its infrastructure.

Each delegation transfers judgment. And where judgment is transferred before it has been formalized, systems inherit whatever structure is most available: statistical norms from training data, optimization assumptions embedded in models, escalation pathways derived from existing workflows.

The resulting pattern reflects generalized logic rather than institutional specificity.

As delegation expands, these patterns stabilize. Workflows adapt. Adjacent systems integrate. Performance metrics align with algorithmic behavior. Over time, the patterns become infrastructural. Reconstructing institutional logic then involves redesigning live systems rather than articulating doctrine in advance.

This is why the next 12 to 18 months represent a structural inflection. Many enterprises are crossing from experimentation into embedded participation. At that threshold, identity is no longer an abstract concern. It becomes architecture. Once embedded in daily execution, it becomes the default environment for decisions and workflows.

Enterprises that make their institutional logic explicit before delegation will solidify their will to scale intelligence with coherence. Enterprises that defer articulation will encounter the operational consequences of logic embedded through accumulation rather than design.

What NVIDIA understood

NVIDIA did not make a $60-75 million acquisition because semantic technology is new. Ontology tooling has existed in various forms for decades. Knowledge graphs, taxonomy management, metadata catalogs: these are not novel ideas.

NVIDIA made this acquisition because it understood that agentic AI at enterprise scale requires a structured representation of what the enterprise actually is. Its entities. Its relationships. Its meaning. Without that representation, agents operating autonomously across enterprise systems have no stable ground on which to reason. They fill the gaps with generalized inference. And generalized inference is not the same as institutional knowledge.

The ontology is not the product. The ontology is the substrate that makes the product trustworthy.

NVIDIA is positioning for the layer that comes before intelligence can scale reliably inside complex enterprises. That is a significant strategic signal. The intelligence race is not about which model you run. It is about whether you have built the foundation that allows any model to operate coherently within your specific institutional context.

That foundation is what most enterprises have not built. And that gap is now visible in the public record.

What semantic infrastructure does and does not solve

This is where precision matters enormously, and where most enterprise AI conversations become dangerously imprecise.

The platform NVIDIA acquired automates the creation of a semantic layer. It maps an organization’s structured data and usage patterns into a knowledge graph. It generates business glossaries, maps metadata relationships, surfaces lineage, and connects technical data definitions to business language. It does this automatically, at scale, without requiring months of manual configuration.

That is genuinely valuable. It solves a real and expensive problem.

But this class of technology does not address a distinction that is consequential.

Automated semantic infrastructure maps what already exists explicitly in your data systems. It reads metadata. It analyzes usage patterns. It connects fields to business terms based on what is documentable and discoverable through technical inspection.

Enterprise identity is not primarily located in your data systems. It is located in the judgment that shaped those systems over time. In the decisions made and the ones overridden. In the definitions that were contested across departments and resolved through organizational negotiation. In the institutional logic that experienced employees carry and that new hires absorb gradually through proximity and observation.

None of that is in the metadata.

A semantic platform that onboards an enterprise by mapping its existing data to an industry ontology, a pre-built model of what a bank, an insurer, or a retailer generically looks like, gives that enterprise a structured representation of its industry. That is useful. It is not a structured representation of that specific enterprise’s identity. The baseline is external. Organizational specificity is layered on top of a generic industry model.

That is a meaningful difference in two ways.

First, it shapes what the AI can reason about. An agent operating on a generic industry ontology will produce outputs coherent within that ontology. It will be consistent with how the platform has modeled the industry. It will not necessarily be consistent with how this specific enterprise has made decisions, defined its customers, assessed its risk, or created its value over decades of operation. The coherence is platform-coherence, not institutional coherence.

Second, it shapes who owns the semantic foundation. If the enterprise did not build its ontology through deliberate internal work, it does not fully own it. When the platform changes, the ontology changes with it. When the contract ends, the semantic layer ends with it. The enterprise cannot fully interrogate an ontology it did not construct. It cannot defend it to a regulator who asks how a particular definition was established. It cannot evolve through organizational consensus because the foundation was automated rather than agreed upon.

Semantic infrastructure is an accelerant. It strengthens the foundation the company has already built. For enterprises that have done the prior work of externalizing their identity, the technology becomes extraordinarily powerful. Their institutional knowledge is the input. The platform’s capability is the amplifier.

For enterprises that have not done that prior work, the platform becomes a substitute. It supplies an external approximation of identity. The enterprise gets AI that is coherent, but coherent according to a generic model of their industry, not to who they specifically are and how they specifically operate.

Over time, enterprises that rely on the same platforms and are pre-trained on the same industry ontologies begin to reason in structurally similar ways. Their competitive differentiation erodes gradually as institutional specificity gives way to generic intelligence.

That is convergence. And it is the risk that never appears on AI risk registers until it is too late.

The ownership question

When Klarna eliminated its human agents, it did not intend to eliminate its institutional knowledge. The institutional knowledge was never formally owned. It had never been externalized, documented, or structured. It existed in the relationship between the organization and its people. When the people left, the knowledge left with them.

You cannot lose what you own. You can only lose what you never formally held.

Klarna did not formally hold its institutional identity. It resided in people, not in systems. When those people were replaced by a system that had no access to that identity, the enterprise could not transfer what it had never structured.

The same logic applies to semantic infrastructure. An enterprise that relies entirely on an automated platform to generate its semantic layer has not formally owned that layer. The platform generated it. The platform maintains it. If the platform changes its industry ontology model next year based on new training data, the enterprise’s semantic foundation shifts with it, without the enterprise’s knowledge or consent.

Enterprise identity, properly built, is vendor-agnostic. It is the input to any platform, not the output of one.

How to know where you stand

Knowing the identity problem exists is not the same as knowing whether your enterprise has it.

The instinct is to look for evidence in strategy documents, operating models, and governance frameworks. These matter. But they are not where coherence is demonstrated. Coherence is not declared. It is demonstrated through structure.

Three questions locate the gap more precisely than any audit.

The first is whether decision logic is stable across domains. When risk tolerance, as expressed in underwriting, aligns with capital allocation. When pricing posture reflects the same strategic positioning that informs product development. When escalation pathways operate consistently across functions rather than diverging by domain. If the answer requires checking with multiple teams before it can be provided, the logic is unstable. It is locally held.

The second is whether trade-offs are formalized or inferred. Every enterprise makes recurring choices: growth or margin, speed or control, customization or standardization. Over time, those patterns define strategic posture. They reveal how risk is interpreted, how opportunity is evaluated, and how authority is exercised. For decades, these trade-offs were absorbed through leadership judgment. Context shaped the outcome. Experience-guided interpretation. When intelligence participates in prioritization, pricing, or allocation, trade-offs must be translated into parameters. If they have not been formally articulated, systems will infer them from data patterns rather than institutional doctrine. In that transition, identity shifts from deliberate to derivative.

The third is whether institutional memory is durable or fragile. Every enterprise carries precedent: interpretation, context, judgment shaped by prior outcomes. This memory traveled through conversation for decades. It was rarely formalized because formalization was not required for the organization to function. When intelligence participates in execution, memory cannot remain informal. Historical decisions influence future parameters. Prior trade-offs shape optimization thresholds. Past exceptions inform automated rules. If institutional memory is not translated into structure, it does not disappear. It fragments. Different systems inherit different interpretations. Logic diverges across domains.

Coherence is therefore not cultural. It is architectural. It is visible in how decisions are constructed, how authority is exercised, and how meaning travels across the enterprise. The question is not whether an organization has a strategy. The question is whether its institutional logic can be clearly described, traced, and consistently applied as intelligence scales.

Most enterprises, examined honestly against these three questions, will find partial answers. That is the diagnosis. And the diagnosis is the starting point for the work that follows.

What the articulation gap requires

A coherent digital identity is not built through technology selection. It is built through deliberate internal work that precedes any platform decision.

It begins with value. Where does this enterprise actually create value today? Bring the people who understand that value creation into the room, the people with operational knowledge, not only organizational authority. Map how value is created, who is involved, and where the decision chain runs.

From there, trace the flows. Follow how decisions, data, and operational content move through the organization to achieve each value goal. These flows reveal interdependencies, contested definitions, and the shared assets that multiple domains depend on, the ones that carry the enterprise’s operational intelligence.

As the flows are mapped, patterns emerge. Certain assets appear repeatedly across value chains. These are the candidates for formalization. When the right people reach a shared understanding of what a foundational asset is, what it means, who owns it, how it must behave, and what its quality and lineage standards require, that agreement, documented and maintained, is the enterprise externalizing its own identity. That is an asset owned by the enterprise. One that no platform change can dissolve.

A semantic infrastructure platform can then amplify that work at a significant scale. The technology becomes an accelerant for an identity that already exists, rather than a substitute for one that was never built.

The progression is five stages: manufacture context, stabilize identity, enable intelligence, enforce judgment, and preserve intent at scale.

Most enterprises attempting AI transformation begin at stage three. They select platforms, deploy agents, and measure outputs. The structural work that precedes stage three has not been done. The identity has not been manufactured. The articulation gap has not been closed. And as delegation continues to accelerate, the gap becomes harder to close from within a live system than it was before delegation began.

The next 12 to 18 months are the window.

Klarna learned what happens when intelligence is deployed without identity. NVIDIA just paid $60-75 million because it understands that solving the identity problem is the unlock for everything that follows.

The enterprises that will benefit from what NVIDIA is building are the ones that have already done the work the infrastructure is designed to amplify.

That work does not begin with a platform selection. It begins with the deliberate decision to make the enterprise legible to itself, before delegation solidifies into architecture.

The choice every enterprise now faces is not whether to adopt intelligence. That decision has already been made by the market. The choice is what intelligence will operate on when it arrives.

One path is convergence. Adopt the available platforms, accept the industry ontologies they provide, and allow institutional logic to be inferred from data patterns rather than expressed through deliberate design. This path is fast. It produces measurable outputs quickly. Over time, it produces an enterprise that reasons like its industry rather than like itself. Differentiation erodes. Strategic posture drifts toward statistical norms. The institution becomes a capable operator of generic intelligence rather than the architect of its own.

The second path is delegation without ownership. Deploy the tools. Automate the workflows. Allow institutional logic to be encoded through accumulation rather than intention. The enterprise retains nominal control while the actual decision-making doctrine settles into the infrastructure through the behavior of systems no one fully designed. This is how most enterprises are currently proceeding. It feels like progress. It is progress. And it quietly embeds, at scale, a logic that no one is formally authorized to use.

The third path is deliberate identity. The enterprise does the structural work first. It maps its value creation, formalizes its trade-offs, externalizes its memory, and articulates the doctrine that governs decision-making before that doctrine is encoded by a system. Then it adopts platforms that amplify what the enterprise actually owns rather than approximating what it never built.

Convergence. Delegation without ownership. Deliberate identity.

Only one of these produces an enterprise that remains recognizably itself as intelligence scales through it.

This essay is part of Arc 2: The Identity Imperative, a Substack series running alongside the Enterprise Identity Imperative LinkedIn series. Each essay extends the arc argument in depth. Subscribe to receive each essay as it publishes.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

© 2026 Anna Jibgashvili · All Rights Reserved

Sources:

Klarna CEO reverses AI customer service strategy, resumes human hiring: https://www.entrepreneur.com/business-news/klarna-ceo-reverses-course-by-hiring-more-humans-not-ai/491396

Klarna workforce reduction and service quality decline: https://www.fastcompany.com/91468582/klarna-tried-to-replace-its-workforce-with-ai

NVIDIA acquires illumex for $60 million — ontology expertise cited as strategic rationale: https://www.calcalistech.com/ctechnews/article/hkrcgl5dbx

The CIO claims ownership of AI because it runs on infrastructure. The CRO claims it because AI makes decisions that carry risk. The COO claims it because AI is reshaping operational workflows. Each claim is legitimate, yet each is incomplete.

The conflict is not about AI. It is about a layer none of these functions was designed to own: the substrate, the semantic contracts, decision boundaries, and institutional identity structures that determine how AI reasons about the enterprise it serves.

When no one owns the substrate, everyone bears the consequences.

What the turf war gets wrong.

The CIO, CRO, and COO conflict reflects a reasonable disagreement over where AI sits in the organizational chart. It does not resolve the underlying architectural question.

AI is not a technology. It is not a risk category. It is not an operational function. It is an execution layer that runs on top of whatever substrate the enterprise has built, or failed to build. The question of who owns AI is therefore the wrong one. The right question is who owns the layer on which AI runs.

That layer is where the enterprise encodes what it is: how it defines its core concepts, how it makes decisions, where it draws the boundary between autonomous execution and human judgment, which trade-offs reflect its institutional posture, and how those definitions are governed as circumstances change.

In most enterprises, this layer lacks an owner. It has contributors: the data governance function defines some of it, legal defines some of it, risk defines some of it, and individual domain owners define pieces of it within their jurisdictions. The result is a fragmented substrate that reflects the organizational structure rather than the institutional logic it was meant to encode.

When AI operates on a fragmented substrate, it produces fragmented outcomes. Not because the models are wrong, but because what they were given to reason about was never coherent to begin with.

What the substrate contains.

The substrate is neither a data catalog nor a governance framework. It is the layer where five things are encoded:

Semantic contracts: the explicit definitions of how core concepts are understood across domains. What “customer” means in risk is the same as what it means in finance and operations because the substrate makes that meaning authoritative and portable.

Decision boundaries: the explicit specification of what AI can decide autonomously, what requires human judgment, and what triggers escalation. These boundaries are not model parameters. They are institutional policy, encoded in a layer that travels with every system that consumes it.

Trade-off hierarchies: the documented precedence rules that govern how the enterprise resolves competing priorities. When margin conflicts with retention, when speed conflicts with control, and when expansion conflicts with resilience, the substrate encodes how the institution has decided to resolve those tensions.

Accountability structures: the explicit assignment of ownership of definitions, decisions, and boundaries. Ownership is what makes the substrate governable. Without it, changes to the substrate occur through accumulation rather than intention.

Change governance: the processes that determine what may evolve and what must remain stable, how changes are versioned, and how every system that consumes the substrate is notified when a dependency changes.

Why existing functions cannot own it.

The CIO function owns the infrastructure layer: the platforms, pipelines, and systems that store and move data. Infrastructure ownership is about capability. The substrate is about meaning. These are distinct problems that require different ownership.

The CRO function owns the risk layer: the identification, measurement, and management of institutional exposure. Risk ownership is about outcomes. The substrate is upstream of risk: it defines the concepts and boundaries to which risk frameworks are applied. Owning risk without owning the substrate means governing outcomes while the conditions that produce them remain someone else’s responsibility.

The CDO function owns the data layer: the quality, lineage, and governance of data assets. Data ownership concerns the raw material. The substrate concerns what that material means and how it should be used. A CDO can govern data quality without governing semantic coherence, and often does.

The substrate requires a function responsible for maintaining institutional identity coherence across tools, domains, and AI systems. That function does not currently exist in most enterprises. It needs to.

The CEIO function.

The Chief Enterprise Identity Officer is responsible for the substrate layer.

CEIO is not a technology role. It is not a governance role. It is a strategic role whose mandate is to ensure that the enterprise remains legible to itself as intelligence scales through it.

The CEIO owns DSIL™, the Digital Substrate Identity Layer, which encodes institutional identity as a machine-readable architecture. The CEIO is responsible for the semantic contracts that make meaning portable across domains, the decision boundaries that govern AI behavior, the trade-off hierarchies that reflect institutional posture, and the change governance processes that maintain the substrate’s coherence as the organization evolves.

The CEIO sits at the intersection of strategy, governance, and technology, not within any one of them. This positioning is deliberate. The substrate must be informed by strategy (what the enterprise stands for), governed by policy (what rules apply), and implemented through technology (what systems consume). An owner who sits within any one of these functions will optimize for that function’s priorities rather than for substrate coherence across all three.

The CEIO does not own AI. The CEIO owns what AI operates on.

What breaks without this function.

Enterprises without a CEIO equivalent will encounter the substrate problem at the moment it is most expensive to fix when AI is already embedded in production systems across multiple domains.

At that point, the substrate is not missing. It exists in fragments across every system that made a local decision about how to define a concept, draw a boundary, or resolve a trade-off. Those fragments are not coherent with one another. They are, however, operational. Every system that depends on them has workflows, models, and performance metrics aligned with the fragmented substrate it inherited.

Reconstructing coherence at that stage requires coordinating changes across live systems: systems that cannot be taken offline for redesign, that have downstream dependencies the enterprise may not fully understand, and that have been producing outcomes the organization has come to treat as normal.

The CEIO function is most valuable before this condition arises. The case for creating it is strongest precisely when the problem is not yet visible, because visible problems are expensive.

Where ownership sits today.

Four conditions describe where substrate ownership currently sits within enterprises scaling AI:

Distributed without coordination. Multiple functions own pieces of the substrate, with no mechanism to ensure coherence across them. Each piece is locally governed. The whole is ungoverned.

Governance-delegated. A data governance or enterprise architecture function has nominal ownership of the substrate but lacks the mandate, authority, or cross-functional reach to enforce coherence. The substrate exists on paper, but in practice it fragments at domain boundaries.

Platform-delegated. Substrate ownership has effectively shifted to the vendors whose platforms embody the most institutional logic. The enterprise can configure but cannot fully articulate or reconstruct what it has delegated.

Intentionally owned. A named function with an explicit mandate owns the substrate, governs its evolution, and is accountable for its coherence as AI scales. This condition is rare. It is the one that compounds advantage rather than accumulating liability.

The honest question is which of these describes your enterprise today and what the cost of that condition will be as AI deployment scales.

This is the seventh post in the Enterprise Identity Imperative series. The next post examines what it means to build institutional identity as architecture, and why encoding precedes intelligence.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

NVIDIA’s statement named the reason precisely: illumex’s expertise in building ontologies will help accelerate enterprise adoption of agentic AI.

Ontologies. The formal representation of how an organization understands itself, its entities, its relationships, its meaning.

I have been writing about this layer for two years. Today, one of the world’s most valuable technology companies confirmed its importance with a $60-75 million acquisition.

This essay is my attempt to explain what that signal means and what it asks of enterprise leaders.

The premise most AI strategies miss

Organizations do not become intelligent simply by adopting AI.

Intelligence without structure amplifies ambiguity, accelerates poor decisions, and scales operational fragility. Before intelligence can operate safely inside an enterprise, the enterprise itself must become legible to humans and to machines.

AI runs on context.

Context is the structured understanding of how an organization creates value, who participates in that value creation, which decisions matter, what information is authoritative, and where accountability resides.

When this context remains implicit, scattered across teams, locked in tribal knowledge, and embedded in undocumented processes, intelligence systems default to probabilistic reasoning over incomplete signals. They fill the gaps with generalized patterns from their training data. They produce plausible outputs, but institutional specificity is absent. The outputs are confident, but the accountability is unclear.

The result is convergence.

The convergence problem

Convergence is the risk that rarely appears on AI risk registers.

It surfaces when enterprises rely on the same platforms, trained on the same generalized patterns, to reason about their own operations. A vendor-supplied semantic layer carries the vendor’s understanding of what an enterprise looks like, industry archetypes, common definitions, and standard decision structures. That understanding has real value. And it belongs to the vendor, shaped by their training data and design choices.

Over time, organizations that source their context layer from the same platforms begin reasoning in similar ways. Their AI produces similar interpretations. Their competitive differentiation, the specific way they define their customers, assess their risk, and create their value, erodes gradually through the replacement of institutional specificity with generic intelligence.

An enduring advantage emerges only when enterprises intentionally shape their own operational context.

What manufacturing context actually means

This is a leadership undertaking, expressed through architecture.

Manufacturing context means deliberately making your enterprise legible to itself first, and then to the systems that will increasingly operate within it.

It begins with value. Where does this enterprise actually create value today? Bring the people who understand that value creation into the room, the people with operational knowledge, not only org chart authority. Understand how value is created, who is involved, and where the decision chain runs.

From there, trace the data roads. Follow how decisions, data, and operational content move through the organization to achieve each value goal. These are the actual flows, the ones that reveal interdependencies, shared assets, contested definitions, and invisible bottlenecks that architecture diagrams do not capture.

As several of these flows are mapped, patterns emerge. Certain data assets appear repeatedly across value chains, shared, reused, and depended upon by multiple domains. These are the assets that carry the enterprise’s operational intelligence. The ones that must be formalized, certified, and protected.

Formalization requires agreement. When the right people reach a shared understanding of what a foundational asset is, what it means, who owns it, how it must behave, and its quality and lineage standards, that agreement, documented and maintained, is a Foundational Data Product. And it is proprietary to the enterprise that built it.

This work is architectural, and it precedes tool selection. Every platform adopted after this work is done becomes more powerful because it has something real to work with, institutional specificity, not a generalized approximation.

The methodology

The work I have developed over fifteen years in regulated financial services across Credit Suisse, BlackRock, Moody’s, S&P Global, Guardian Life, and New York Life follows a structured progression:

manufacture context → stabilize identity → enable intelligence → enforce judgment → preserve intent at scale

Each stage builds on the previous one. Foundational Data Products are the mechanism through which tacit operational knowledge becomes explicit and machine-readable. They establish semantic clarity, preserve institutional memory, and create the conditions under which automated reasoning can be trusted.

Once context is manufactured and identity stabilized, intelligence can move through the enterprise as a governed supply chain ingesting signals, informing decisions, triggering actions, and learning over time. Certification frameworks define what good looks like. Risk thresholds articulate what is acceptable. Control architectures ensure that autonomy expands only within deliberate boundaries.

The details of how each stage works in practice are what my forthcoming book addresses.

What today’s acquisition signals

NVIDIA acquired a team that understood ontologies, the formal representation of organizational knowledge, relationships, and meaning. That is the layer required to make agentic AI work reliably inside enterprises. A way for intelligent systems to understand what the enterprise actually is.

What illumex built is a platform that supplies that context layer. For enterprises that have already done the work of manufacturing their own context, a platform like this becomes a powerful accelerant. Their intelligence reflects their own definitions, decisions, and values.

For enterprises that have sourced their context layer externally without first doing their own identity work, the platform becomes a substitute. Substitutes carry the logic of whoever built them.

The question worth sitting with today is not whether to adopt semantic infrastructure. It is whether your enterprise has done enough of its own identity work to engage that infrastructure on its own terms and remain recognizably itself as intelligence scales through it.

The leadership mandate

Technology magnifies the structural conditions into which it is introduced. Where context is clear, AI amplifies precision. Where context is ambiguous, AI amplifies ambiguity faster, at greater scale, with greater confidence.

The future enterprise will be defined by how intentionally it architects the environment in which intelligence operates.

In the age of intelligent machines, the ultimate leadership responsibility is the deliberate design of organizational cognition.

This essay draws from my forthcoming book, Enterprise Foundations Strategy: An AI Transformation Blueprint for Building AI-Ready Organizations Without Losing Identity or Trust.

If this essay resonated, subscribe for more thinking on enterprise AI strategy, organizational cognition, and the foundations that make intelligence scale.

Subscribe now

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

© 2026 Anna Jibgashvili · All Rights Reserved

What reveals an institution's identity is the pattern of trade-offs it consistently makes over time.

Every enterprise faces recurring choices: growth or margin, speed or control, customization or standardization, expansion or resilience. The answers to these choices, not the stated values but the actual decisions made under pressure at scale, define strategic posture. They reveal how risk is assessed, how opportunity is evaluated, and where authority is exercised when competing priorities collide.

For decades, these trade-offs were resolved through leadership judgment. Context shaped outcomes. Experience-guided interpretation. The organization remained itself because the people making decisions understood what it stood for, even when that understanding was never formally documented.

AI changes the operating conditions in one specific way: when intelligence participates in execution, trade-offs must be encoded in structure.

What happens when trade-offs remain implicit.

A credit model does not apply judgment. It applies thresholds. If the institution’s risk appetite was never formally encoded and existed as executive calibration rather than documented doctrine, the model will infer it from historical patterns. Those patterns reflect what the organization did, not what it intended. The distinction matters when markets shift, regulations change, or the institution decides to move in a new direction. The model will not move with it. It will continue optimizing for the pattern it learned.

A pricing algorithm does not weigh competing priorities. It operationalizes whatever objective function was specified during training. If the trade-off between short-term revenue and long-term customer retention was never made explicit, the algorithm will resolve it in whatever direction produces the best score on the metric it was given. That resolution becomes institutional policy, applied consistently at scale, until someone notices that the outcomes no longer align with what the organization intended.

A capital allocation system does not distinguish between quantifiable and strategic value. It optimizes for what can be measured. Projects that resist quantification include initiatives that protect long-term differentiation, investments in relationships, and commitments to principles that don’t appear on a P&L. These will be systematically deprioritized unless the criteria that protect them are formally encoded.

In each case, the system is functioning correctly. The failure is not technical. The issue is that the institution’s trade-offs were never translated into a language the systems can act on.

Trade-offs become architecture.

The transition from implicit to explicit trade-offs is not a documentation project but an architectural one.

When trade-offs are implicit, they live in people. They travel through hiring, mentorship, and the accumulated judgment of leaders who understand what the organization stands for. This works as long as those people are present and the decisions requiring their judgment remain within human reach.

When AI begins participating in execution, the scope of decisions requiring institutional judgment expands beyond what humans can supervise directly. A pricing engine making thousands of decisions per hour cannot wait for executive calibration. An underwriting model processing applications across multiple markets cannot pause for contextual interpretation. Judgment must be encoded before delegation occurs. Otherwise, the system will substitute its own.

Trade-offs encoded as architecture become:

Risk tolerance as a threshold: a specific, documented value that defines the boundary between acceptable and unacceptable outcomes, with explicit rules for actions at the boundary.

Escalation as a workflow: a defined path that specifies when a decision leaves the automated layer and requires human judgment, the context the human receives, and the SLA that governs their response.

Preference as optimization logic: a formally specified objective function that reflects institutional priorities rather than generic defaults, with documented trade-offs among competing criteria.

Each of these translations requires the organization to make explicit what was previously absorbed through experience. That process is uncomfortable. It forces conversations about priorities that were previously left unresolved because they were not required to be resolved. AI makes resolution necessary.

The diagnostic question.

The test for whether an enterprise has encoded its trade-offs is not whether it has governance documentation. It is whether that documentation is specific enough for a system to act on.

Consider three questions:

If your risk model encounters a borderline application, one that falls exactly at the threshold between approval and rejection, consider what happens: whether there is a documented protocol or whether it depends on who reviews it.

If your pricing engine recommends a price that maximizes short-term margin at the expense of a long-term customer relationship, consider whether the system recognizes that trade-off. Consider whether there is a parameter that reflects the institution’s view on that balance.

If a capital allocation algorithm scores two projects identically on financial criteria but one protects a strategic capability that isn’t captured in the model, consider whether there is a mechanism for that strategic consideration to enter the decision, or whether the algorithm defaults to a choice.

If these questions cannot be answered by reference to documented, operational logic, and the honest answer is “it depends on the analyst” or “we’d escalate that” without a defined escalation path, the trade-offs remain implicit. They are being managed through judgment that AI cannot replicate.

What encoding trade-offs requires.

Three things that documentation alone cannot provide:

Specificity. A trade-off is not encoded until it is specific enough to yield a deterministic outcome in a defined situation. “We prioritize long-term relationships” is not encoded. “Customer lifetime value above X triggers a retention review before a pricing decision is finalized” is encoded.

Ownership. Every encoded trade-off needs an owner: a function or individual responsible for reviewing it when circumstances change, updating it when organizational priorities shift, and validating that the system’s behavior continues to align with institutional intent. Without ownership, encoded trade-offs become stale faster than the systems that consume them.

Versioning. Institutional priorities evolve. The trade-offs that defined the organization’s posture five years ago may no longer align with its current strategic direction. Every trade-off encoded in a system needs to be versioned so that changes are intentional, visible, and traceable to every decision made under the prior version.

These three requirements define the Policy and Decision Intelligence Layer: the governance structure that sits above data foundations and below AI deployment, encoding institutional trade-offs in a form that systems can act on and that humans can audit.

The identity that travels.

Enterprises that encode their trade-offs before scaling AI produce something that infrastructure investment alone cannot replicate: AI that behaves like the institution it serves.

The credit model approves and declines in ways that reflect the organization’s actual risk posture. The pricing engine helps balance margin and retention as the institution would. The capital allocation system protects strategic priorities that don’t appear in financial metrics because those priorities were formally encoded before the system was deployed.

This is what institutional identity looks like when it moves through AI at scale. Not a cultural artifact. Not a mission statement. A pattern of decisions, consistently applied, that reflects what the enterprise stands for.

Identity is encoded. Encoding begins with trade-offs.

This is the fifth post in the Enterprise Identity Imperative series. The next post examines what NVIDIA’s acquisition of illumex signals for enterprises that have not yet built their own semantic foundation.

The frameworks described in this post, including DSIL™, EDAOF™, and Foundational Data Products™, are proprietary methodologies developed by Anna Jibgashvili. Trademark applications are filed or pending. For licensing or implementation inquiries, contact anna@foundationaldataproducts.com.

An enterprise is coherent when its parts share a consistent understanding of how value is created, how decisions are made, and what the organization stands for when those decisions are contested. Coherence enables the enterprise to act as a unified whole rather than as a collection of locally optimized functions that happen to share a balance sheet.

For decades, coherence was maintained implicitly. Leaders carried institutional logic through experience, and managers reconciled inconsistencies through judgment. The organization functioned, even when definitions varied across domains, because those operating within it understood the context well enough to fill the gaps.

AI changes the operating conditions by removing human intermediaries. When intelligence participates in execution, institutional logic must be explicit enough for a system to act on it. Implicit coherence, maintained through culture and experience, does not transfer to machines.

The institutional legibility problem.

Enterprises operating under implicit institutional logic cannot safely scale intelligence. AI systems inherit interpretations rather than intentions. When the logic is never formally articulated, what gets inherited is the statistical average of past behavior, which may or may not reflect the organization’s intentions.

This produces a specific failure pattern: AI deployments that perform correctly by every technical measure yet produce outcomes that don’t reflect institutional intent. The system is not malfunctioning. It is functioning precisely as designed on logic that was never explicitly designed.

The problem is that the enterprise was never fully legible to itself.

Three signals indicate this condition:

Semantic drift. Ask your CFO, CRO, and COO to define “approved customer” without a meeting. If their answers differ, or if the question requires a meeting before anyone will commit to an answer, the enterprise has semantic drift in a foundational concept. That drift is manageable when humans reconcile it in real time. When AI systems make decisions based on it, the drift propagates automatically across every system that consumes the concept.

Decision fragmentation. Trace how a pricing decision made in one function affects capital allocation in another. If that trace requires conversations across three teams and yields different answers depending on who you ask, the enterprise has decision fragmentation. AI deployed in pricing, risk, or capital allocation will embed whatever fragmentation already exists, consistently and at scale.

Structural incoherence. Attempt to automate any cross-domain workflow without creating new governance exceptions. If exceptions proliferate at every boundary the workflow crosses, the enterprise exhibits structural incoherence at the integration layer. Every AI initiative that crosses domain boundaries will expose this incoherence: not because the AI is wrong, but because the boundaries were never designed to be crossed consistently.

What coherence requires.

The market response to coherence problems has been infrastructure: platforms for real-time data streaming, vector databases, agentic orchestration layers, and unified data lakehouses. These investments solve for execution velocity. They assume the enterprise already knows what it is.

The assumption is almost always incorrect.

The infrastructure market accelerates execution on whatever foundation exists. When the foundation is coherent, infrastructure compounds value. When the foundation is incoherent, infrastructure amplifies that incoherence: faster and across more systems than it would have reached manually.

Coherence requires something infrastructure cannot provide: the enterprise formally articulating its institutional logic. Not in a strategy document. Not in a governance framework. In the structural layer that governs how data is defined, decisions are constructed, authority is assigned, and trade-offs are resolved when two valid interpretations of the enterprise’s intent yield different outcomes.

This is the work most enterprises have not done. It is the work AI transformation now requires before infrastructure can deliver on its promise.

The coherence diagnostic.

Three tests that reveal where your enterprise stands:

The definition test. Take three foundational concepts in your business: customer, risk, and product, or their equivalents in your domain. Have leaders from three different functions write down what each concept means without consulting one another. Compare the answers. The gap between those answers is the semantic coherence gap your AI systems will inherit.

The decision trace test. Pick a high-stakes decision your enterprise makes repeatedly: a credit approval, an underwriting determination, a capital allocation, or a customer escalation. Trace the logic backward: what data feeds it, what rules govern it, who owns the thresholds, and where the escalation paths lead. If the trace breaks at any point, if the answer is “it depends on the analyst” or “that gets escalated, but we don’t have a documented protocol,” that break is where AI will either fail or produce decisions that cannot be explained.

The change test. Make a hypothetical change to a foundational definition: a regulatory update that redefines a core concept or a market shift that requires reclassifying a customer segment. Map every system, model, and workflow that would need to change as a result. If the map cannot be drawn, or if drawing it requires weeks of cross-functional effort, the enterprise lacks the structural coherence needed to manage change at AI scale.

These tests are uncomfortable. They surface gaps that have been managed through judgment for years. They surface them because AI cannot apply the judgment that was filling them.

What the diagnostic reveals.

Enterprises that run these tests typically discover one of three conditions:

Managed incoherence: the gaps exist and are actively managed through governance processes, cross-functional alignment, and explicit ownership of foundational definitions. These enterprises are sufficiently coherent to begin deliberately encoding institutional logic.

Unmanaged incoherence: gaps persist and are absorbed through human judgment without formal governance. The enterprise functions, but the logic that enables it is undocumented, unowned, and not transferable to other systems. This is the most common condition and the most urgent to address before AI deployment scales.

Invisible incoherence: the enterprise believes it is coherent because its governance structures are mature and its AI deployments are performing. The incoherence is not yet visible because the deployments have not yet crossed the boundaries where it resides. This condition is the most dangerous because it produces confidence before the problem surfaces.

The goal of the diagnostic is not to determine that the enterprise is incoherent. The goal is to pinpoint precisely where incoherence exists before AI systems uncover it through production failures.

This is the fourth post in the Enterprise Identity Imperative series. The next post examines where institutional identity resides and why it is found in trade-offs rather than in mission statements.