Part 1 defined the Knowledge Spine: an enterprise ontology operationalized on a semantic platform, connected at query time to lakehouses, domain graphs, and unstructured sources. Part 2 built it in six months. Part 3 kept it alive through reorgs, mergers, and silent drift.

This part is about the conversation that decides whether any of it survives: the one with the CFO.

Here is the pattern I have seen repeatedly. Semantic projects rarely die of bad modeling. They die at budget season. Not because they created no value, but because the value showed up in everyone else’s numbers: faster analytics in one budget, fewer integration projects in another, an AI assistant that stopped hallucinating in a third. The spine did the work; other lines took the credit. Infrastructure that cannot show its own balance sheet gets treated as overhead, and overhead gets cut.

So the spine needs what every other piece of infrastructure eventually earned: its own way of being counted.

Sell Answers, Never the Ontology

The unit of ROI is the same as the unit of delivery: an answered question. Because every vertebra ships with a named question and a named user (Part 2), every vertebra carries its own micro business case from birth.

Before the vertebra: how long did the answer take, how many people assembled it manually, how often was it wrong, what decisions waited on it. After: minutes instead of weeks, zero manual assembly, lineage on every number. That delta, question by question, is the spine’s revenue line. Nobody funds “an ontology.” People fund “supplier exposure answered in minutes instead of three weeks of spreadsheet archaeology.”

The Three Numbers a CFO Actually Hears

Cost avoided. Recurring analyst hours retired per question, multiplied across every question the spine now answers. Integration projects never built, because virtual mappings replaced another round of ETL. Duplicate data copies and shadow spreadsheets retired. This is the easiest bucket to quantify and the fastest to show.

Risk reduced. The hallucination tax made visible: wrong answers caught because every answer carries lineage. Audit preparation dropping from weeks to days, because definitions, ownership, and history live in one governed place. Regulatory changes handled as versioned releases (Part 3) instead of panic projects with consultants attached.

Speed gained. A new question that crosses silos: weeks of data wrangling before, hours now. A new AI use case: grounded on day one, because the grounding APIs already exist. An acquisition: queryable through federation before systems integration even starts. Speed is the bucket executives remember, because it changes what the business can attempt.

Behind these, track the leading indicators that predict them: consumers connected, questions answered per month, the share of answers carrying lineage, drift caught before consumers noticed, and the one number that should fall every quarter: cost per answered question.

Funding That Survives Budget Season

The funding model should mirror the operating model (Part 2): small hub, federated limbs.

The first vertebra is sponsor funded. One question, one budget, one believer. Never start with a platform line item; start with a business problem that already has money attached to its pain.

The hub is platform funded. Once two or three vertebrae exist, the spine team, the platform, and the upper ontology move to a platform budget, exactly like platform engineering. This is the infrastructure layer, and it is deliberately small: four to eight people even at scale.

The limbs are domain funded. Each domain pays for its own vertebra squad, because each domain keeps its own benefits. This is the structural fix for the “value lands in other budgets” problem: the budget that benefits is the budget that pays.

At scale, show the ledger. Showback per domain: questions answered, hours retired, consumers served. Chargeback is optional and often not worth the friction; visibility is what protects the platform line when budgets tighten.

The Compounding Curve

Here is the argument that separates a spine from every project the CFO has cut before: the economics improve with every vertebra.

Cost per vertebra falls. The upper ontology is already there, the mapping patterns are reusable, the extraction pipelines are templates, the playbooks are practiced. The first vertebra took a quarter; the eighth takes weeks.

Value per vertebra rises. Every new module enriches the questions that already exist. Connect contracts, and supplier risk answers improve. Connect the customer graph, and contract questions gain revenue context. Each vertebra is a node in a network, and the answers compound the way networks do.

And agentic AI steepens both lines. Every agent you deploy is a new consumer that asks questions at machine volume, so the denominator under cost per answered question explodes while the platform cost barely moves. The same agents raise the stakes on the risk bucket: an ungrounded agent pays the hallucination tax at machine speed too. The spine is the difference between agents that multiply your answers and agents that multiply your errors. Either way they multiply, which is exactly why this budget conversation cannot wait.

Falling unit cost against rising unit value is a curve every CFO recognizes. Somewhere around the third or fourth vertebra the lines cross, and the spine stops being a bet and starts being the cheapest way the organization answers anything. Put that crossing point on one slide. It is the only slide the funding conversation needs.

What Kills the Funding

Selling technology. The moment the pitch says “knowledge graph platform” instead of a question with money attached, the clock starts.

The hub paying for everything. A central team funding every vertebra recreates the monolith (Part 2) and makes the spine look expensive while every benefit lands elsewhere. Domains pay for their limbs.

Measuring activity instead of outcomes. Classes modeled, triples loaded, sources connected: none of these are value. Questions answered, hours retired, decisions accelerated: all of these are. Report outcomes or lose the room.

The Bottom Line

The spine earns its budget the same way it was built: vertebra by vertebra. Give every vertebra its micro business case, report cost avoided, risk reduced, and speed gained, fund the hub as platform and the limbs from the domains they serve, and show the compounding curve until it speaks for itself.

Meaning is infrastructure. Counted properly, it is the cheapest infrastructure you own.

If you have taken a semantic initiative through budget season: what number saved it, or what number was missing when it died? Tell me in the comments.

Coming in Part 5: The Agentic Spine. AI agents are becoming the spine’s heaviest consumers, and something more interesting: its contributors. Next up: agents that query the spine, agents that patrol it for drift, and what happens when your organization’s meaning becomes the operating system for its machines. Follow me so you don’t miss it.

The views expressed here are my own and do not represent those of my employer or its clients.

#KnowledgeSpine #KnowledgeGraph #Ontology #DataArchitecture #EnterpriseAI #SemanticLayer

The Knowledge Spine, Part 4: The Spine’s Balance Sheet was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1 defined the Knowledge Spine: the operationalization of an enterprise ontology, instantiated on a semantic platform and connected at query time to your lakehouses, domain graphs, and unstructured sources. Part 2 showed how to build one in six months instead of two years.

This part is about the harder question. The business underneath your spine refuses to hold still. How do you keep meaning true while everything it describes keeps moving?

Here is the uncomfortable truth: an ontology is a photograph of the business. The business, unfortunately, is a movie.

What Bends the Spine

Four shocks arrive on a schedule nobody controls, plus a fifth that never announces itself.

Reorganizations. Domains get redrawn, teams merge, ownership moves. The model that mapped cleanly to your org chart in January maps to nothing by June.

Mergers and acquisitions. An acquired company arrives with its own vocabulary, its own systems, and often its own ontology. Two definitions of “customer” now claim to be true.

New products and business models. Launch usage pricing and suddenly “subscription” stops meaning what it meant. Old classes get quietly stretched to cover things they were never designed to hold.

Regulation. A new rule renames, reclassifies, or redefines entire categories overnight, and compliance cannot wait for next year’s modeling workshop.

Silent drift. The most dangerous one. No memo, no event. People simply start using a term differently, source systems repurpose a field, and the gap between what the model says and what the business means widens a little every week. You discover it when an answer is confidently wrong.

A rigid spine meets these shocks and breaks. A living spine absorbs them. The difference is not the model. It is the metabolism around it.

Metabolism, Not Maintenance

“Maintenance” implies fixing things after they break. A living spine senses change before consumers feel it. Three signals are worth instrumenting from day one:

Validation trends. SHACL violations rising in one module mean reality is diverging from the model right there. Falling data quality is often meaning drift wearing a disguise.

Question failure. Track what people ask the spine and where it fails to answer or answers wrongly. A cluster of failed questions is a map of where the business has moved.

Bypass behavior. The clearest signal of all: side spreadsheets reappear, teams write private prompt hacks, analysts stop using the endpoint. People never file a ticket saying the ontology is stale. They just route around it.

Call it semantic observability. If you only monitor uptime, you will keep a dead model perfectly available.

Evolve Without Breaking Anyone

The spine has consumers now: dashboards, applications, AI agents grounded in it. Every change threatens them, so treat the ontology the way good teams treat an API.

Version it semantically. Additive changes (new classes, new relationships) ship freely. Changes that alter meaning get a new version, never a quiet overwrite.

Give breaking changes a deprecation window. Old and new definitions run side by side for a stated period, with notices to every consumer of the old one. Lineage tells you exactly who they are.

Test compatibility before release. Keep a suite of the real questions consumers depend on and run it against every candidate release. If a change breaks a question, you know before production does. Think of it as contract testing for meaning.

None of this is exotic. It is the boring discipline software learned decades ago, applied to semantics. Boring is what alive looks like at scale.

Shock Playbooks

Reorg: modules survive the org chart. Because domain modules are owned separately (Part 2), a reorg is a metadata change: reassign stewardship, remap identifiers, done. The meaning does not move just because the people did.

M&A: never merge ontologies on day one. Map the acquired vocabulary to your upper ontology so both can be queried together immediately, then retire duplicates release by release as integration actually happens. Federation first, consolidation slowly.

New product: extend, never overload. When a definition stops fitting, version it explicitly rather than stretching the old class until it means everything and therefore nothing.

Regulation: encode rules as constraints in the model. A regulatory change becomes a versioned release with validation attached, instead of an email chain and a prayer.

A Worked Example: The Tuesday Reorg

Say the company merges Sales and Customer Success into a single Revenue organization, effective immediately. “Account Owner” now means the revenue lead, not the sales rep. Here is how a living spine absorbs it.

Days 1 to 5, sense. Nothing breaks visibly, but the signals move. SHACL violations climb in the CRM mappings as the old owner field gets repurposed. Questions like “who owns this account” start returning stale names. A new tracking spreadsheet quietly appears inside the Revenue org. The drift dashboard lights up before a single consumer complains.

Week 2, triage. Stewardship of the Sales module transfers with the reorg. Because ownership is metadata, that transfer is a one day change, not a project. The new steward proposes the semantic change: Account Owner needs a new definition, and the model needs a Revenue Team concept.

Week 3, evolve. Additive parts ship immediately: the Revenue Team class and the new ownership relationship. The old Account Owner definition is not overwritten. It is versioned, marked deprecated, and given a 90 day window.

Week 3, release and monitor. The compatibility suite runs the real consumer questions against the candidate release and flags three dashboards and one agent prompt still bound to the old meaning. Lineage names their owners, they get notified automatically, and they migrate inside the window. Then the signals get watched again.

Total elapsed: about three weeks. Zero broken consumers, zero crisis meetings, and the AI agents answered correctly through the whole transition because they resolve meaning through the spine, not through hardcoded assumptions.

The rigid alternative? The org chart changes, the model does not, and six months later someone discovers that pipeline reports have been attributing revenue to people who left the sales team in Q1.

The Nervous System

Signals need someone to act on them. The stewards embedded in each domain (Part 2) are the spine’s nerve endings: first to sense that a term has shifted, first to propose the change. The central team triages proposals, guards the upper ontology, and runs the release train.

And this is where AI earns its keep twice. The spine grounds your AI; your AI can also watch the spine. An LLM reviewing query logs, failed questions, and source schema changes can draft candidate model updates for steward review. Humans stay the approvers. The machine becomes the early warning system.

The Bottom Line

A knowledge spine is not a monument you unveil. It is an organism you keep alive. Sense drift before consumers feel it, version meaning like an API, absorb reorgs and mergers through federation, and let stewards plus AI form the reflex arc that turns change from crisis into routine.

Part 1 gave the spine a name. Part 2 built it fast. This part keeps it true. What remains is the question every CFO eventually asks.

What broke your semantics: a reorg, a merger, a product pivot, or quiet drift nobody caught? Tell me in the comments.

Coming in Part 4: The Spine’s Balance Sheet. Proving ROI vertebra by vertebra, funding models that survive budget season, and the metrics that convince a CFO that meaning is infrastructure. Follow me so you don’t miss it.

The views expressed here are my own and do not represent those of my employer or its clients.

#KnowledgeSpine #KnowledgeGraph #Ontology #DataArchitecture #EnterpriseAI #SemanticLayer

The Knowledge Spine, Part 3: The Living Spine was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my last article I proposed a definition: a Knowledge Spine is the operationalization of an enterprise ontology — the ontology instantiated on a semantic platform and connected, at query time, to your lakehouses, domain knowledge graphs, and unstructured sources.

The most common response was some version of the same question: “Fine. How do we actually build one?”

The traditional answer is a multi-year semantic program. I think that answer is obsolete. Done right, with today’s tooling, you can go from nothing to a working backbone in six months — a blitz build. Here’s how, and why it’s now possible.

Why Speed Is Suddenly on the Table

Three things changed the math:

LLMs collapsed the modeling bottleneck. Drafting an ontology used to mean months of workshops. Today an LLM drafts candidate classes, relationships, and definitions from your existing glossaries, schemas, and documents in days — and your SMEs shift from authors to reviewers. Review is 10x faster than authorship.

Virtualization killed the ETL tax. The spine connects to lakehouse tables through virtual mappings. No migration project, no new copies of data, no six-month integration workstream. Mapping is configuration, not construction.

Extraction became a commodity. Pulling entities and relationships out of contracts and reports used to require a bespoke NLP team. Now it’s an LLM pipeline you stand up in a sprint — emitting output in terms of the ontology.

The constraint was never the technology’s speed. It was the waterfall habit of modeling everything before shipping anything. Drop that habit, and the blitz is open.

The Prime Directive Still Holds

Speed doesn’t change the unit of delivery: never “the ontology,” always an answered question — something the business needs to know that the current stack can’t tell them. A blitz is not modeling faster. It’s shipping answers faster.

Days 0–30: First Vertebra Live

Week 1 — pick the question, draft the model. One cross-silo question with a named sponsor who cares about the answer, not the technology. LLM-draft the ontology from existing schemas and glossaries; SMEs review and cut it to the 15–30 classes the question needs. SHACL constraints from day one.

Week 2 — instantiate and connect. The model goes onto the semantic platform. Map one or two lakehouse sources virtually. A federated query runs end to end — ugly is fine.

Weeks 3–4 — ship the answer. A dashboard, an API, or an agent that a named business user touches. The deliverable of the first month is a believer.

Days 31–60: Harden While Hot

Momentum is the blitz’s fuel; trust is its armor. In parallel, not in sequence:

• Governance as code: ontology into version control, review and release process, SHACL validation on every change.
• First extraction pipeline: contracts or reports relevant to the question, emitting entities conforming to the ontology.
• Instrumentation: query logs and feedback capture — the roadmap is driven by what users actually ask.

Days 61–90: Second Vertebra — the Federation Test

The second use case forces the question the first could dodge: how do domains connect without merging?

Pick an adjacent question that shares concepts with the first. Refactor the shared concepts into a small upper ontology; leave everything domain-specific in modules owned by domain teams. Resist the merge — the spine aligns identifiers and upper-level concepts; it doesn’t absorb.

If nothing moved into a shared upper ontology by day 90, you built an application, not a spine.

Months 4–6: Backbone by Default

Now compound. Add a vertebra every 30–45 days — each one a named question, a named user, a shipped answer. Meanwhile:

• Ground AI by policy. Every copilot and RAG pipeline resolves entities through the spine, so “where did this answer come from?” always has a lineage-backed answer.
• Publish the endpoints. SQL for BI, GraphQL/SPARQL for apps, grounding APIs for agents — connecting to the spine becomes the path of least resistance.
• Put the ontology on a release cadence. Versioned, reviewed, boring. Like all good infrastructure.

By month six the roadmap inverts: domain teams queue up to attach their vertebrae, because attaching is faster than building alone.

The Blitz Team

Small and senior: an ontologist/knowledge engineer, a semantic platform engineer, a data engineer for mappings and pipelines, and a product-minded lead who owns the question backlog. Plus part-time domain stewards who own their module’s definitions — meaning is authored where the knowledge lives. Four to five people. Not twenty.

“We’re a 50,000-Person Enterprise — Four People Won’t Cut It”

Correct — and that’s not how it scales. The spine scales the way platform engineering does: the hub stays small because it only owns the platform, the upper ontology, and the standards. Scale happens in the limbs.

Each domain stands up its own vertebra squad — its steward plus two or three engineers — building its module in parallel, against spine standards. Ten domains means ten parallel squads, while the central team grows to perhaps six or eight and shifts from building vertebrae to certifying them: reviewing modules, guarding the upper ontology, keeping the paved road paved.

At true global scale — multiple divisions, multiple regions — divisions run their own spines federated to a thin global upper ontology. Same pattern, one level up.

The rule at every size: the four-to-five person team builds the first vertebrae. Growth is many small teams attaching in parallel — never one big central team modeling on everyone’s behalf.

What Kills a Blitz

The cathedral reflex. Sneaking “while we’re at it” modeling into sprint one. Antidote: no class enters the ontology without a question that needs it.

Skipping the armor. Speed without governance produces a demo, not a backbone — fast to build, faster to rot. The day-31 hardening is not optional.

The tool-first trap. Buying the platform before the question exists. In a blitz the platform is instantiated in week two of a use case — never before one.

The Bottom Line

Two-year semantic programs die of sponsor fatigue before they ship. The blitz inverts the risk: a believer in 30 days, federation proven in 90, a backbone that earns its keep by month six — with governance hardened along the way, not bolted on after.

Vertebra by vertebra, at sprint speed.

Could your organization ship its first vertebra in 30 days? What would stop you? Tell me in the comments — I’ll compare notes in a follow-up.

Coming in Part 3: The Spine’s Survival Guide. Defining the spine was the easy part; building it fast, the fun part. Keeping it funded, secure, and adopted is where most die. Next up: proving ROI vertebra by vertebra, access control across federated domains, choosing the platform without falling into the tool-first trap, and turning skeptical SMEs into stewards. Follow me so you don’t miss it — and if your comment names a battle I haven’t listed, it may end up in the article.

#KnowledgeSpine #KnowledgeGraph #Ontology #DataArchitecture #EnterpriseAI #SemanticLayer

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views or positions of any entities author represents.

The Knowledge Spine, Part 2 — The Blitz: A Backbone in Six Months, Not Two Years was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have ontologies that could tell them. The problem is where those ontologies live: in PowerPoint decks, PDF glossaries, and modeling tools nobody queries. They describe meaning; they don’t deliver it.

I’d like to propose a definition of the term for the missing piece: the Knowledge Spine. The conept already exist, but is emerging and definition is not yet solidified. This is my version.

My Definition

A Knowledge Spine is the operationalization of an enterprise ontology: the ontology instantiated on a semantic platform and actively connected, at query time, to the domain knowledge graphs, lakehouses, and unstructured sources that hold the enterprise’s actual data, so that every consumer, human or machine, resolves meaning through one governed backbone.

Three words in that definition carry the weight:

Operationalized. The ontology is not documentation. It is deployed, versioned, queryable infrastructure. If you can’t run a query against it in production, you have a knowledge diagram, not a knowledge spine.

Connected. The spine doesn’t copy data into itself. It binds concepts to sources — a “Customer” in the ontology resolves to rows in the lakehouse, nodes in a domain knowledge graph, and entities extracted from contracts, all through mappings, not migrations.

Backbone. Like a biological spine, it doesn’t do the thinking and it doesn’t store the mass of the body. It connects the head (AI, analytics, applications) to the limbs (data sources) and carries signals reliably between them. Remove it, and everything is still there — it just can’t act in a coordinated way.

What the Spine Holds — and What It Doesn’t#

The spine is mostly metadata. It holds three things:

• Meaning — the ontology: classes, relationships, constraints and definitions of record.
• Bindings — the mappings that tie each concept to the tables, graph nodes and documents where its data actually lives.
• Identity — the shared identifiers and crosswalks that establish that this customer in the lakehouse is that counterparty in the risk graph.

What it does not hold is the bulk of the enterprise’s data. That stays at the source, under the source’s governance. The exceptions are deliberate: entities extracted from unstructured content, which have no other structured home, and small subsets materialized because reasoning or performance genuinely requires it.

A common misreading is that the spine replaces the data lake. It doesn’t. The lakehouse remains the system of record for structured data, and domain teams keep owning their graphs. The spine is the alternative to copying all of that into one central graph — not the alternative to the lake.

Why “Spine” and Not “Layer”?

We already have semantic layers, and they matter. But “layer” suggests something passive and flat — a pane of glass. A spine is structural and load-bearing. It implies:

• Verticality: it runs through the whole stack, from raw sources to AI agents, not just between BI tools and tables.
• Centrality with distribution: one spine, many connected limbs. Domain teams keep their knowledge graphs; the spine federates them.
• Consequence: if it’s wrong, everything downstream is wrong. That’s exactly the level of seriousness enterprise semantics deserves.

Guiding Principles

1. Ontology first, instantiation second. The spine begins as a formal model — classes, relationships, constraints — designed with the business, in standards like OWL/RDF/SHACL. Tooling comes after meaning.
2. Virtualize by default, materialize by exception. Connect to lakehouses and databases through virtual mappings so data stays where it’s governed. Materialize into the graph only what performance or reasoning genuinely requires — typically entities extracted from unstructured content and small, reasoning-heavy subsets. The default answer to “should this data move?” is no.
3. Federate domain knowledge graphs — don’t absorb them. Domain teams own their graphs: risk, product, supply chain. The spine links them through shared upper-level concepts and identifiers. This is data-mesh thinking applied to semantics: domain ownership, central interoperability. Federation does not replace the lakehouse: domain graphs and lakehouse tables sit side by side as sources, and the spine connects both.
4. Treat unstructured sources as first-class citizens. Contracts, reports, emails, and wikis hold most enterprise knowledge. Entity and relationship extraction pipelines should land their output in terms of the ontology, so a clause in a PDF and a row in a table describe the same “Obligation.”
5. Make the spine the grounding layer for AI. Every agent, copilot, and RAG pipeline should resolve entities and traverse relationships through the spine — not embed its own private notion of the business. This is how you get answers that are explainable and auditable rather than merely fluent.
6. Version and govern it like code. Ontology changes go through review, testing, and release. Lineage, access control, and definitions-of-record live with the spine, so governance is enforced where meaning is resolved.
7. Grow it vertebra by vertebra. Start with one domain and one high-value question the current stack can’t answer. Prove it. Extend.

Platform-Agnostic Architecture

A knowledge spine has five parts, whatever tools you choose:

1. Ontology & governance core — the formal enterprise ontology, versioned and released like software.
2. Semantic platform — where the ontology is instantiated and queried: reasoning, validation, and query across sources.
3. Connection fabric — virtual mappings to lakehouses and warehouses; federation links to domain knowledge graphs; extraction pipelines from unstructured content.
4. Consumption plane — SPARQL/GraphQL/SQL endpoints for applications and BI, plus retrieval and grounding APIs for LLMs and agents.
5. Feedback loop — usage analytics and steward workflows that push corrections back into the ontology.

Sources stay put. The spine carries meaning, bindings and identity — not the data itself. Consumers — human or machine — never bind to physical schemas again.

A Concrete Instantiation: Stardog + Databricks

Here’s one way I’d build it today:

The spine runs on Stardog, which instantiates the enterprise ontology and serves as the semantic platform: reasoning, SHACL validation, and federated query in one place.

Structured data stays in the Databricks lakehouse. Stardog’s virtual graphs map Delta tables to ontology concepts, so a SPARQL query against “Customer” is translated at query time into SQL pushed down to Databricks — no copying, no drift, and Unity Catalog governance still applies at the source.

Domain knowledge graphs — a product graph, a risk graph, a customer-360 graph — are connected through shared identifiers and upper-ontology alignment, queried as one federated graph.

Unstructured sources flow through extraction pipelines (Databricks is a natural place to run them) that emit RDF conforming to the ontology, landing entities from contracts and reports directly into the spine.

Consumers hit the spine from both directions: analysts through BI/SQL endpoints that expose graph concepts as tables, and AI agents through natural-language interfaces like Stardog’s Voicebox, whose answers are grounded in the graph rather than generated from model weights — with the lineage to prove it.

Swap Stardog for another semantic platform or Databricks for Snowflake and the pattern holds. The spine is the architecture, not the vendor.

The Bottom Line

Enterprises don’t have a data shortage; they have a meaning shortage. Ontologies were always the answer, but an ontology at rest is just a very rigorous opinion. Operationalize it — instantiate it, connect it, govern it — and it becomes a knowledge spine: the backbone that lets your data, your people, and your AI finally mean the same thing.

The organizations that build one will find their AI initiatives compounding. The ones that don’t will keep paying the hallucination tax.

How is your organization operationalizing its ontology? I’d like to hear what’s working — and what isn’t — in the comments.

#KnowledgeGraph #Ontology #SemanticLayer #DataArchitecture #EnterpriseAI #KnowledgeSpine

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views or positions of any entities author represents.

The Knowledge Spine: Why Your Ontology Needs to Grow a Backbone was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I explore what it will take for AI agents to become trusted advisors in regulated industries — and why governance, explainability, and accountability may matter more than intelligence itself.

Every week, a new AI agent claims it can advise customers, negotiate contracts, recommend investments, interpret regulations, or answer legal questions.

The technology is impressive. The real question is not “Can you trust the advice?”

More importantly: “Can you defend that advice in front of a regulator, auditor, judge, or customer?”

That is where the conversation around AI agents is about to shift.

For years, organizations evaluated AI based on accuracy. If an agent answered correctly 90% of the time, many considered it successful.

That standard is no longer sufficient.

When an AI agent advises a customer on an investment portfolio, recommends an insurance policy, determines eligibility for a loan, explains employment rights, or provides healthcare guidance, accuracy alone is not enough. The advice must also be explainable, auditable, compliant, and legally defensible.

The Investment Advisor Example

Imagine an AI investment advisor recommending that a customer move a large portion of their retirement savings into a specific ETF.

The customer follows the recommendation. Six months later, the investment performs poorly and a complaint is filed. The question regulators will ask is not whether the AI sounded convincing.

They will ask:

• Why was this recommendation made?
• What information about the customer was considered?
• Were suitability requirements met?
• Were conflicts of interest disclosed?
• Can the recommendation process be reconstructed?

A human advisor is expected to maintain records supporting the recommendation. An AI advisor must meet the same standard. Without an audit trail, the recommendation may be impossible to defend, regardless of how sophisticated the underlying model was.

For any customer-facing AI agent, especially in regulated industries, five controls become critical: accuracy, explainability, auditability, regulatory compliance, and liability ownership.

If an AI investment advisor recommends a portfolio allocation, the organization must be able to answer: Why was this recommendation made? What customer data was used? Was the recommendation suitable for that customer’s risk profile, age, income, investment horizon, and stated objectives? Can the same decision be reproduced later if a regulator, auditor, or customer challenges it?

The Legal Industry Example

Now imagine an AI legal assistant helping tenants understand their rights during an eviction proceeding. The agent cites statutes and case law, explains procedural requirements, and suggests next steps.

What happens if the advice is wrong? Who is responsible?

The challenge is not simply whether the answer was correct. The challenge is proving how the answer was generated and whether it was based on approved legal sources. A trustworthy legal agent cannot simply generate text. It must demonstrate that its guidance originated from verified legal authorities and current regulations. In other words, legal advice requires provenance, not just intelligence.

The Healthcare Example

Consider a healthcare agent advising patients about treatment options. A recommendation may be medically sound. However, healthcare organizations must also demonstrate compliance with privacy regulations, clinical guidelines, patient consent requirements, and documentation standards. An answer that is medically accurate but procedurally non-compliant may still create significant legal exposure. The healthcare industry has understood for decades that documentation is often just as important as the decision itself. AI agents will be held to the same expectation.

The Compliance Industry Example

Many organizations are already exploring AI agents that interpret regulations, perform control testing, identify policy violations, and recommend remediation actions. This appears to be an ideal use case. Yet compliance teams face a familiar problem. If an AI agent flags a violation, regulators may ask:”How did you determine this activity was non-compliant?”. An answer such as “the model determined there was elevated risk” will not satisfy an examiner.

The AI must provide evidence, reasoning, policy references, and decision lineage. Without explainability, there is no compliance.

The Trust Gap

This is where many organizations are making a critical mistake. They focus on model intelligence while overlooking governance. A highly intelligent agent that cannot explain its reasoning may be less valuable than a simpler agent operating under strict governance controls.

Agents must be able to answer:

• What decision was made?
• Why was it made?
• What data was used?
• Which policies were applied?
• Who approved the rules?
• Can the process be reproduced?

Those questions sound remarkably familiar because they are the same questions organizations already ask human employees.

The Future: Certified Digital Advisors

We may soon reach a point where AI agents are treated less like software and more like employees.

Imagine AI agents that have:

• Defined authority levels
• Approved knowledge sources
• Continuous monitoring
• Compliance certifications
• Decision audit trails
• Performance reviews

Before an agent can advise customers, it may need to demonstrate competency, compliance, and traceability, much like a licensed professional today. The organizations that embrace this model will unlock enormous value from agentic AI.

Those that do not may discover that an intelligent answer is not the same thing as a defensible one.

Because in regulated industries, AI agent can provide advice, but that advice must survive scrutiny when everything is on the line.

#AI #AgenticAI #AIGovernance #ResponsibleAI #Compliance #LegalTech #FinTech #InvestmentManagement #DigitalTransformation #DataGovernance #RiskManagement #EnterpriseAI #TrustworthyAI #AIAgents

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views or positions of any entities author represents.

Can You Trust Your AI Agent to Give Legally Valid Advice? was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

This time, I explored a question that AI is forcing every technology leader to revisit:

Is “build vs. buy” even the right question anymore?

For decades, organizations decided whether to build custom software or buy commercial products. AI is breaking that model.

Today, the smartest companies aren’t building everything. They aren’t buying everything either.

They’re assembling.

Foundation models, agent frameworks, vector databases, and AI platforms are rapidly becoming commodities. The real competitive advantage is moving elsewhere.

If your AI strategy still uses the same build-versus-buy logic from the ERP and CRM era, you may already be solving the wrong problem.

My latest article explores why the decision framework has fundamentally changed — and where organizations should actually invest their resources.

For decades, technology leaders faced a familiar question: should we build a solution ourselves or buy a commercial product? The answer was usually driven by cost, implementation timelines, maintenance requirements, and whether the capability was considered a competitive differentiator.

Artificial Intelligence has fundamentally changed this equation.

The traditional build-versus-buy framework assumed relatively stable software. A CRM system, ERP platform, or reporting tool might receive periodic upgrades, but the core functionality remained largely unchanged for years. AI operates differently. Models evolve monthly, new capabilities emerge continuously, infrastructure costs fluctuate, and yesterday’s innovation quickly becomes today’s commodity.

Organizations can no longer evaluate AI investments using the same criteria they used for traditional software.

Why Traditional Build vs. Buy No Longer Works

In the past, buying software meant purchasing a finished product. Building meant creating custom functionality from scratch.

AI blurs these boundaries.

A company can purchase a foundation model, build custom agents on top of it, integrate proprietary data, and deploy a solution that is partially bought and partially built. The result is often neither a pure build nor a pure buy decision.

Modern AI solutions are increasingly assembled rather than developed.

The question is no longer:

“Should we build or buy?”

The question has become:

“Which layers should we build, and which layers should we buy?”

What Organizations Should Buy

Most organizations should avoid building foundational AI capabilities.

Training large language models requires enormous investments in infrastructure, talent, data engineering, and ongoing maintenance. Even the largest enterprises struggle to justify competing with organizations that invest billions into model development.

These components are typically better purchased:

• Foundation models
• Vector databases
• AI infrastructure platforms
• Model hosting environments
• Agent orchestration frameworks
• Speech and vision APIs
• Evaluation and monitoring platforms

These capabilities are rapidly becoming commodities. Building them internally rarely creates lasting competitive advantage.

What Organizations Should Build

The real value lies closer to the business.

Organizations should focus on building:

• Proprietary business knowledge
• Industry-specific AI agents
• Decision intelligence workflows
• Data products
• Governance frameworks
• Business process automation
• Domain-specific reasoning capabilities

Every company has unique processes, policies, regulations, and operational knowledge. This is where differentiation exists.

A bank does not gain advantage by building its own foundation model. It gains advantage by creating AI systems that understand its products, risk frameworks, customer journeys, regulatory obligations, and internal operating model.

The same principle applies across healthcare, manufacturing, retail, and government.

The Rise of “Assemble and Differentiate”

A new strategy is emerging across leading organizations.

Instead of building everything or buying everything, they assemble platforms from proven components and invest their resources in differentiation layers.

Think of AI as a technology stack:

Commodity Layers (Buy)

• Models
• Infrastructure
• Frameworks
• Runtime platforms

Differentiation Layers (Build)

• Business knowledge
• Agent behavior
• Data products
• Governance controls
• Business workflows

This approach dramatically reduces time-to-market while allowing organizations to maintain strategic control over what makes them unique.

The Hidden Cost of Building AI

Many organizations underestimate the cost of AI development.

Building an AI solution is not simply writing code.

It requires:

• Prompt engineering
• Model evaluation
• Data quality management
• Hallucination monitoring
• Governance controls
• Security reviews
• Continuous retraining
• Performance optimization
• Cost optimization

Unlike traditional software, AI systems require constant tuning as models, data, and business requirements evolve.

The initial build cost is often only a fraction of the total ownership cost.

The New Decision Framework

In the AI era, organizations should ask three questions:

1. Is this capability a commodity?
If competitors can easily purchase the same capability, buying is usually the better option.

2. Does this capability create strategic differentiation?
If it directly impacts customer experience, operational excellence, or competitive advantage, building may be justified.

3. How quickly is the technology evolving?
The faster the technology changes, the greater the risk of building something that becomes obsolete within months.

Final Thoughts

The AI era is not eliminating the build-versus-buy decision. It is redefining it.

Building foundation capabilities that are rapidly becoming commodities is a losing strategy. Building unique intelligence around proprietary data, business processes, and organizational knowledge is where sustainable advantage will emerge.

In the age of AI, success is no longer about building everything yourself, but assembling intelligently and differentiating deliberately.

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views or positions of any entities author represents.

Build vs. Buy in the Era of AI: Why the Rules Have Changed was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years, organizations have treated data management as a discipline of control: define the data, document the rules, assign ownership, monitor quality, and remediate issues when something breaks.

That work is still necessary. But in the era of AI, it is no longer enough.

AI is changing the speed, scale, and expectations of data management. We now have the ability to automate metadata extraction, generate data quality rules, map data elements, summarize lineage, classify sensitive data, detect anomalies, and accelerate documentation that previously took weeks of manual effort.

That is a major opportunity.

But it also creates a serious risk: if AI is applied on top of weak data practices, it will not solve the problem — it will multiply it.

Bad definitions will become automated bad definitions. Inconsistent rules will become inconsistent rules at scale. Poorly governed datasets will be reused faster, by more people, in more critical decisions. And fragmented data ownership will become even harder to control once AI agents start acting across systems.

This is why I believe one of the most important questions in data management today is not simply: “How can we use AI to manage data?”

The better question is: “How do we use AI to improve data management without creating a new generation of data problems?”

In my experience working across data governance, metadata, data quality, reporting, and data architecture, the hardest part of managing data at scale is rarely the tool itself. The difficulty is consistency.

Different departments define the same term differently. Different systems apply different validation logic. Different reports calculate the same KPI in slightly different ways. Ownership is often unclear. Metadata is incomplete. Lineage is documented in one place, quality rules in another, business definitions somewhere else, and issue remediation in yet another tracker.

AI can help connect and automate this work, but only if it is guided by strong principles.

Otherwise, we are just accelerating disorder.

The real promise of AI in data management is not that AI will magically fix bad data. The promise is that AI can help us build the data foundation required for better AI.

In other words: AI will give you good data for AI — but only if you design the process properly.

That means using AI not as a replacement for governance, but as an intelligent accelerator of governance.

Here are the guiding principles I believe organizations should follow.

1. Start with business meaning, not technical structure

AI should not only scan tables, columns, and schemas. It should help connect data to business meaning.

A column name alone does not explain what the data represents, how it should be used, who owns it, what rules apply to it, or whether it is trusted for reporting. Organizations need AI-assisted metadata that links technical fields to business definitions, data owners, reports, controls, and usage context.

Without semantic clarity, AI may generate technically correct outputs that are still wrong from a business perspective.

2. Keep humans accountable for critical decisions

AI can recommend definitions, identify potential data quality rules, suggest mappings, and flag inconsistencies. But accountability must remain with the right business and technical owners.

For example, AI may propose that a field should be classified as a customer identifier or that a rule should check for completeness. But the Data Owner, Data Steward, or Technology Data Custodian still needs to validate whether that recommendation is accurate and appropriate.

The future of data management is not human versus AI. It is AI-assisted accountability.

3. Standardize before you automate

One of the biggest mistakes organizations can make is automating broken processes.

If every department manages metadata differently, AI will learn and reproduce those differences. If issue categories are inconsistent, AI-generated issue summaries will also be inconsistent. If data quality thresholds are not standardized, AI-generated rules may look sophisticated but remain difficult to compare across domains.

Before scaling AI automation, organizations need clear standards: naming conventions, metadata requirements, data quality dimensions, ownership models, issue classification, approval workflows, and escalation paths.

AI works best when the operating model is clear.

4. Treat AI outputs as governed assets

AI-generated metadata, rules, mappings, classifications, and summaries should not sit outside governance. They should go through review, approval, versioning, and monitoring.

If AI recommends a data quality rule, that rule should be traceable. Who approved it? When was it implemented? What dataset does it apply to? What business requirement does it support? What happens when the rule fails?

The same applies to AI-generated business definitions, lineage descriptions, and data classifications.

If AI is helping manage data, then AI outputs themselves become part of the data governance ecosystem.

5. Use AI to detect inconsistency, not just produce content

Many organizations think of AI as a content generator. But in data management, some of its highest value comes from comparison.

AI can compare definitions across systems. It can identify where the same data element is described differently. It can detect gaps between business metadata and technical metadata. It can flag reports using similar KPIs with different logic. It can review issue logs and identify recurring root causes.

This is where AI becomes more than a productivity tool. It becomes a consistency engine.

6. Build feedback loops

AI improves when it learns from corrections. If users reject a suggested definition, adjust a mapping, or modify a generated rule, that feedback should not disappear. It should be captured and used to improve future recommendations.

This is especially important in data management because every organization has its own vocabulary, systems, controls, and regulatory expectations.

Generic AI will not be enough. The best results will come from AI that learns the organization’s data language over time.

7. Connect AI automation to measurable outcomes

AI initiatives in data management should not be measured only by speed. Faster documentation is useful, but it is not the final outcome.

The better questions are:

Did metadata completeness improve? Did data quality rules become more consistent? Did issue remediation become faster? Did business users gain more trust in reports? Did audit readiness improve? Did AI reduce manual effort without weakening control?

AI should not just make data work faster. It should make data work better.

This is the transformation ahead of us.

Data management is moving from manual stewardship to intelligent stewardship. From fragmented documentation to connected context. From reactive issue management to proactive detection. From static governance artifacts to living, AI-assisted knowledge layers.

To conclude, AI will give you good data for AI — but only if governance, architecture, ownership, and automation work together.

That is where the real transformation begins.

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views or positions of any entities author represents.

Comments

Comments settings

Like

Comment

Share

Add a comment…

Open Emoji Keyboard

No comments, yet.

Be the first to comment.

Start the conversation

Transforming Data in the Era of AI was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

Knowledge graphs are a fantastic way to organize data for complex analysis because they give us what traditional data models often miss: context.

Not just tables, columns, dashboards, or reports, but entities, relationships, dependencies, business meaning, ownership, lineage, rules, and the “why” behind the data. This is exactly the type of foundation we need for advanced analytics, AI agents, regulatory reporting, risk analysis, customer intelligence, and complex enterprise decision-making.

But there is one uncomfortable problem: to create a traditional knowledge graph, organizations often need to move the data again.

Data is extracted from existing systems, transformed, mapped into graph structures, loaded into another platform, and then maintained as yet another enterprise data layer. That creates a familiar problem in a new form: another copy of the data, another synchronization process, another reconciliation burden, another security model, another governance process, and another place where business users may ask: “Which version is correct?”

So yes, knowledge graphs are powerful. But if building one means creating another massive data movement program, many organizations will hesitate — and honestly, they should.

The goal should not be to keep moving data into new architectures every time we discover a better way to understand it. The goal should be to make existing data more understandable, more connected, and more usable without unnecessary duplication.

This is where the conversation usually turns to federated knowledge graphs.

On paper, federated KGs sound like the perfect answer: keep the data distributed, query across multiple systems, and create a unified graph experience without centralizing everything.

But in practice, federated KGs often struggle with performance. When every complex query has to travel across multiple systems at runtime, interpret different schemas, resolve relationships, enforce access rules, and return answers quickly, the architecture can become fragile.

It may work for certain use cases, but it is not always strong enough as a high-performance enterprise data foundation.

So the real question becomes: how do we get the intelligence of a knowledge graph without moving all the data again — and without relying only on slow runtime federation?

My POV: the answer is a semantic virtualization layer built on an ontology-driven semantic model.

The ontology becomes the baseline. It defines the enterprise concepts, relationships, rules, constraints, and business meaning in a formal and reusable way. It tells us what a customer is, what a product is, what a risk exposure is, what a data quality issue is, how these concepts relate, and which rules govern them.

Without ontology, the semantic layer can easily become just another naming layer. With ontology, it becomes a structured model of business meaning.

A semantic virtualization layer then sits above existing systems and uses this ontology-driven model to expose data consistently without forcing all data into one physical graph store.

The underlying data can remain in databases, warehouses, lakehouses, applications, APIs, or operational systems. The semantic layer becomes the governed contract between the physical data landscape and the consumers of that data.

It tells consumers what the data means, how it connects, where it lives, who can use it, and how it should be interpreted.

This is where it is important to be precise: this is not the same as a federated knowledge graph.

A federated KG is mainly a query architecture. It tries to make distributed data behave like one graph at query time.

Semantic virtualization is broader. It is a governed semantic architecture.

It does not assume that every question should be answered through live distributed graph traversal. Instead, it allows the execution layer to choose the most efficient path.

Some queries may be pushed down to source systems. Some relationships may be cached. Some high-value joins may be precomputed. Some graph views may be materialized for performance. Some answers may come through APIs. Some use cases may still use federation where it makes sense.

That is the difference.

Federated KG asks:
“Can I query many distributed sources as if they are one graph?”

Semantic virtualization asks:
“Can I expose enterprise data through one governed semantic model while choosing the fastest and most reliable execution path underneath?”

That distinction matters because enterprises do not only need elegance. They need performance, governance, security, traceability, and operational reliability.

For AI, this becomes even more important.

AI agents do not only need access to data. They need context.

They need to know what a customer means, what a product means, what a risk exposure means, what a data quality issue means, what system is authoritative, which relationship is valid, and which rule should be applied.

Raw tables are not enough.

An ontology-driven semantic layer gives AI agents a governed map of the enterprise. It reduces ambiguity, improves explainability, and gives AI a better chance of producing answers that are not only fluent, but actually grounded in business reality.

That is the real opportunity: not another copy of data, not another massive integration layer, and not a pure federation model that sounds elegant but struggles under pressure.

The next-generation data foundation should be semantic, governed, ontology-driven, and execution-aware.

It should understand where the data lives, what it means, how it connects, and how to retrieve it efficiently.

Knowledge graphs showed us the value of meaning and relationships.

Now the next step is to bring that intelligence to the enterprise without forcing every organization to move the data again.

That is where semantic virtualization becomes powerful — not as a replacement for knowledge graphs, but as a more practical way to operationalize knowledge-graph thinking across complex, distributed enterprise data.

Knowledge Graphs Are Powerful. But Do We Really Need to Move the Data Again? was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are living the dream!

Seriously.

We are in that strange, exciting, golden window where tokens still feel cheap, experimentation feels almost unlimited, and entire teams are building things that would have sounded absurd just a few years ago. Want a strategy memo in seconds? Done. A research summary? Easy. A coding assistant, data analyst, reviewer, translator, planner, or agent swarm? Go build it.

This is the fun part.

This is the age of abundance, at least from the user side. We type, models respond, and somewhere behind the curtain an incredible amount of compute, infrastructure, and capital is being burned to make that experience feel normal.

And that is exactly the point.

Right now, many of us are benefiting from an economy that is still tilted in our favor. Tokens are relatively affordable, access is broad, and vendors are still fighting for market share, adoption, ecosystem gravity, and strategic position. They want us building. They want us integrating. They want us dependent. They want their model to become the layer we cannot live without.

So yes, we are living the dream.

But dreams have economics.

Because let’s be honest: this is not a forever model. It is very hard to believe that the long-term future of the LLM market is one where vendors keep pouring massive money into training, inference, infrastructure, chips, energy, talent, and global scale, only to price usage in a way that leaves little room for profit. At some point, the mood will shift. Growth alone will not be enough. Investors will want stronger margins. Boards will want clearer business discipline. And vendors will start charging not just to win, but to earn.

That is when the real economy of tokens begins.

And that economy may feel very different from today’s.

Today, many organizations are still building in a kind of cheerful wastefulness. Huge prompts. Bloated context. Repeated calls. Premium models for small tasks. Agents talking to agents talking to agents because it looks impressive in a demo. Entire workflows where no one is really asking whether the reasoning is necessary, only whether the output looks smart enough.

It works for now.

But when token economics tighten, a lot of today’s “innovation” will suddenly reveal itself as very expensive laziness.

That is why this moment is so important. We should absolutely use it. We should build, test, prototype, fail fast, learn, and push hard. This is the perfect time to explore the art of the possible. But while we are doing that, we should also prepare for the day when every token starts to feel less like confetti and more like currency.

So what should organizations do in preparation for the age of expensive tokens?

First, stop treating the LLM like the answer to every question.

Not every task needs generative intelligence. Some things need search. Some need rules. Some need a workflow engine. Some need SQL. Some need a graph query. Some need a small model. Some need no model at all. One of the biggest signs of AI maturity will be knowing when not to use the most expensive brain in the room.

Second, become obsessed with context quality.

In the cheap-token era, people often solve uncertainty by throwing more context at the model. More documents. More history. More instructions. More examples. More everything. But more is not always smarter. Often it is just noisier and more expensive. The organizations that will thrive later are the ones that learn how to feed models the right context, not the largest pile of context. Signal will matter more than volume.

Third, architect for tiers.

Success will come from smarter systems, where different components handle different jobs well. Small models for simple tasks. Larger models only when necessary. Caches for repeated patterns. Deterministic validators for quality control. Semantic layers to improve retrieval. Knowledge graphs and ontologies to reduce guesswork. Better orchestration. Better routing. Better judgment about what level of intelligence is actually needed for each step.

Fourth, make token spend visible.

A lot of companies still treat token consumption like background magic. It sits there somewhere in usage reports, vaguely important but not truly managed. That will not last. Soon, token economics will need the same discipline as cloud economics. Budgeting. cost attribution. usage monitoring. unit economics by use case. architectural review. optimization targets. The organizations that do this early will have a huge advantage later.

Fifth, build assets around the model, not just dependence on the model.

This one matters a lot. If your whole advantage comes from buying raw intelligence from someone else, your margins are at the mercy of their pricing. That is fragile. The stronger strategy is to build things that make your use of intelligence smarter, tighter, and harder to replicate: proprietary workflows, curated data, semantic models, domain ontologies, validation frameworks, human feedback loops, business rules, and context engineering that reflects your world. In the future, the real differentiator may not be who has access to the smartest model. It may be who knows how to use expensive intelligence with the least waste and the most precision.

That is the shift we should already be preparing for.

Because the next phase of AI will not just be about what models can do. It will be about what businesses can afford to do repeatedly, reliably, and profitably.

That is a completely different game.

And honestly, I think many organizations are not ready for it. They are celebrating impressive outputs without studying the economics beneath them. They are building token-hungry habits instead of sustainable AI operating models. They are enjoying the buffet without asking who will eventually pay the full bill.

But the smartest organizations will do both at once: enjoy the abundance and prepare for scarcity.

That is the real play.

Use this window. Build boldly. Experiment shamelessly. Learn fast. Let your teams explore. Let them discover what works. Let them stretch the technology while the economics are still generous.

But do not confuse today’s affordability with tomorrow’s reality.

We are living the dream, yes.

But the dream phase is exactly when smart builders prepare for the morning after.

THE ECONOMY OF EXPENSIVE TOKENS was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

We keep collecting more, labeling more, governing more, and still miss what actually matters. Why? Because data is not automatically context. And information is not automatically signal.

The real game is knowing what to ignore.

In a world flooded with raw facts, synthetic content, dashboards, alerts, and AI outputs, the real advantage belongs to those who can separate signal from noise based on intent.

That applies to humans.
That applies to Agentic AI.
And it is becoming one of the most important disciplines in modern data.

My latest article explores why signal is the atomic unit of context and why the future of data is not just about more data, but better signal selection.

One of the first things I learned about data was the difference between data and information.

Data is raw, unprocessed facts. Information is data that has been processed, organized, or interpreted so it has meaning and value.

That distinction is still useful. It is one of the first mental models many of us learn, and for good reason. It teaches us that data does not become valuable simply by existing. It becomes valuable when it starts to mean something.

But today, that lens is no longer enough.

We no longer live in a world where the main challenge is just turning raw data into information. We live in a world of data abundance, data duplication, data exhaust, synthetic data, streaming data, fragmented data, and machine-generated interpretations of data. The real challenge is no longer only how to process data, but how to recognize which data matters for the purpose at hand.

That is where the distinction between signal and noise becomes far more important.

A signal is a piece of data that meaningfully contributes to understanding, decision-making, or action for a specific intent. Noise is data that may be correct, complete, and even high quality, but does not help with that intent.

That last part matters.

Noise is not necessarily bad data. Noise is not the same as poor data quality. Noise can be perfectly accurate, well-governed, timely, complete, and still be irrelevant. A quarterly revenue trend may be a strong signal for a CFO trying to forecast performance. The same data may be noise for a fraud investigator looking for suspicious transaction patterns. A customer’s location history may be a signal for route optimization, but noise for a legal review of contract obligations.

Signal and noise are not fixed properties of data. They are relational properties. They depend on intent.

This is where many data conversations still fall short. We talk a lot about data quality, metadata, lineage, platforms, and governance. All of that matters. But even high-quality data becomes operationally useless if we cannot determine whether it is signal or noise for the question being asked.

So how do we extract signal from noise?

It starts with a discipline that is surprisingly simple, but rarely applied with enough rigor: define the intent before touching the data.

Intent is the filter. Intent tells us what matters, what does not, what should be surfaced, and what should remain in the background. Without intent, everything looks potentially relevant, which is another way of saying that nothing is properly prioritized.

Once intent is clear, signal extraction becomes a matter of deliberate selection.

First, identify the decision, action, or understanding you are trying to support. Not the general topic. The actual purpose. “Understand customer behavior” is too broad. “Detect likely churn drivers in the next 30 days” is much better. “Support a claims adjuster in validating this case” is better. “Help an agent resolve an invoice dispute without escalation” is better.

Second, isolate the smallest meaningful units of data that directly support that purpose. Those units are signals. They are not everything known about the entity. They are the pieces that change understanding in a useful way.

Third, assess relevance in context, not in isolation. Data does not become signal because it is important in general. It becomes signal because it is important here, now, for this intent.

Fourth, accept that signal for one intent can become noise for another. That is not a flaw. That is how context works. Data is not universally meaningful. Meaning is conditional.

And this is also why more data is not always better. Very often, more data simply means more noise wrapped in the false comfort of completeness.

This applies as much to humans as it does to Agentic AI.

We often speak about agents as if they have a special data problem. In reality, they have the same problem humans have, only faster and at greater scale. Neither humans nor agents benefit from drowning in undifferentiated information. Both need the right signals assembled into usable context.

That is why the future of data is not just about storing more, indexing more, or retrieving more. It is about constructing the right context compounds from the right signal atoms.

The chemistry analogy is useful here.

A signal is like an atom. On its own, it has specific properties and limited explanatory power. But when combined with other relevant signals, it forms something more powerful: a context compound. That compound is what enables understanding, judgment, and action.

One transaction amount by itself may not mean much. Combined with merchant type, time of day, customer profile, historical behavior, and device anomaly, it becomes context. One KPI rarely explains a business problem. Combined with process change history, ownership, timing, exceptions, and downstream impact, it starts to tell the truth.

This is exactly where Agentic AI either becomes useful or dangerous.

If agents are fed undifferentiated data, they do what humans do under informational overload: they overgeneralize, miss the important pattern, or act with misplaced confidence. But if agents are given curated signals assembled into context compounds aligned to intent, they become far more reliable.

The same is true for human decision-making. We do not need more dashboards, more tables, and more fields by default. We need environments that surface the signals that matter for the decision in front of us.

That is the art of “new” data.

Not just collecting it. Not just cleaning it. Not just governing it. But learning how to distinguish signal from noise in a world that produces both endlessly.

Because the real competitive advantage will not belong to the organizations that have the most data.

It will belong to the ones that know what to ignore.

And that may be the most uncomfortable truth in modern data: in an age obsessed with accumulation, intelligence is becoming a function of subtraction.

Everything else is just noise.

The Art of “New” Data: Signals and Noise was originally published in The Future of AI and Data on Medium, where people are continuing the conversation by highlighting and responding to this story.