The challenge of comparing two versions of a data contract can be overwhelming. The first time I took on this task, I discovered forty lines of differences between the two contracts. Out of those, only three changes would have caused serious issues downstream. It took me nearly twenty minutes to pinpoint those critical differences.

Twenty minutes, for just one contract!

The problem is not the diff. It is the judgment.

A data contract serves as a promise to those who rely on the data. However, these contracts often undergo edits. Sometimes, producers add new fields, change names, adjust types, or even remove columns that might seem unused. While some edits are harmless, others can disrupt systems relying on that data, especially when everything seems fine at 3 a.m. on a Saturday.

A simple YAML diff won’t clarify which changes are significant. You need to recognize that changing a logical type from string to integer is a more serious issue than merely rewording a description. Being able to make those judgments consistently is difficult, especially when deadlines loom and there’s pressure to deliver before the sprint ends.

To solve this problem, I developed the Schema Drift Advisor, a tool designed to evaluate these changes reliably. Here’s how it works:

1. Grading Changes: When you input two contract versions, the tool checks each field and categorizes the differences as major, minor, patch, or unknown based on the OMDS specification. Major changes—like dropping required fields or altering logical types—are clearly marked, so you see “three major changes” rather than sifting through forty lines on your own.

2. Merging Contracts: The tool doesn’t just highlight differences; it also suggests a combined version of the contracts, indicating what the new version number should be. This means you receive actionable insights rather than a list you need to decipher.

3. Side-by-Side View: You can view both original contracts and the proposed merge side by side, which makes it easier to understand the changes at a glance.

# v1.2.0
properties:
  - name: email
    logicalType: string
    physicalType: varchar(255)

# v1.3.0
properties:
  - name: email
    logicalType: string
    physicalType: varchar(320)

For example, if one version of a contract specifies the `physicalType` for an email field as `varchar(255)` and another as `varchar(320)`, the widening might seem concerning at first glance. However, since the logical type remains unchanged, it’s a minor patch rather than something that would break functionality.

The rules live in a file, not in the code

The severity decisions sit in a YAML rules file that the running service reloads on the fly. Nobody has to rebuild anything to change how a category of change is graded.

This mattered more than I expected. Grading rules are precisely the thing people argue with once they start using a tool like this, and if every disagreement required a rebuild and a redeploy, nobody would have bothered telling me they disagreed.

Try it out!

It is live at tools.actianlabs.com/schema. Just upload any two versions of a contract and see what it finds.

Note: The tool only accepts Open Data Contract Standard (ODCS) YAML files

In the end, it’s about sorting through forty lines to find the three that truly matter—let the tool help you do just that!

Apache Ossie entered the Apache Incubator in July, formerly Open Semantic Interchange (OSI), backed by Snowflake, Dremio, dbt Labs, and Salesforce (only vendors, no end users, no consultants). It standardizes metrics and dimensions so that a metric means one thing across your data warehouse, your BI tool, and whatever agent is querying them.

Google introduced Open Knowledge Format (OKF) on June 12. An OKF bundle is a directory of markdown files with YAML frontmatter, one file per concept, cross-linked. Double parsing is required to get it all.

Both are vendor-neutral and both are also solving a slice of a problem the data contract community has been working on since 2021, which raises a question worth answering carefully rather than territorially: what is the relationship between these specifications and the combination of Open Data Contract Standard (ODCS) and Open Data Product Standard (ODPS)?

A few other initiatives are announcing themselves as the definitive layer for AI-ready data every few weeks. Let's hurry to wait.

A Meta Standard to Rule Them All

Let's define what a meta standard is.

A meta standard is where information is authored and the source of truth. Everything else is derived from it.

If ODCS is where the information originates, then every other representation of that dataset, every semantic model, every knowledge bundle, every catalog entry, should be a projection of the contract, generated for a specific need.

And projections can be lossy. Let me walk you through one.

Walkthrough

Here is a contract in ODCS v3.2. It describes a very basic orders table with an id and an amount. It includes a context block for AI/agentic consumers: instructions for usage guidance, verifiedStatements for curated hints/question and answer pairs, and constraints for the things a consumer must not do.

apiVersion: v3.2.0
kind: DataContract
id: c176de03-8503-4859-bd0f-218cc413d958
name: orders
domain: sales
status: active
schema:
  - name: orders
    properties:
      - name: order_id
        logicalType: string
        primaryKey: true
        description: Unique order id.
      - name: amount
        logicalType: decimal
        description: Order total.
        quality:
          - rule: nonNegativeCheck
            description: Order total must not be negative.
            dimension: validity
            severity: error
            businessImpact: operational
            schedule: 0 20 * * *
            scheduler: cron
context:
  instructions: "Use for revenue analysis and order trends. Do not use for individual customer PII queries."
  verifiedStatements:
    - question: "What counts as a completed order?"
      answer: "An order with status = 'shipped' or 'delivered'."
  constraints:
    - "Always aggregate to at least country level."
    - "Do not join with PII tables without approval."

Now project it two ways.

The OKF Bundle

To OKF, as a bundle:

orders_bundle/
├── index.md
└── tables/
    └── orders.md

And then the description in orders.md:

---
type: BigQuery Table
title: Orders
description: Order transactions for the sales domain.
resource: warehouse://sales.orders
tags: [sales, orders]
timestamp: 2026-06-01T00:00:00Z
---

# Schema

| Column   | Type    | Description      |
|----------|---------|------------------|
| order_id | STRING  | Unique order id. |
| amount   | NUMERIC | Order total.     |

Use for revenue analysis and order trends. Do not use for individual
customer PII queries.

The columns survive with their descriptions intact, and OKF’s # Schema convention gives them a proper home. After that, the projection thins out fast. The nonNegativeCheck rule is gone, along with its severity, its business impact, and the fact that it runs nightly on a schedule. OKF has no frontmatter field and no body convention for any of that. The instructions text survives as prose in the body, with no field boundary marking it as guidance rather than description. verifiedStatements has nowhere to go at all. Neither does constraints, so a rule about aggregating to country level becomes a sentence in a paragraph, indistinguishable from a simple commentary.

To Ossie, as a semantic model:

semantic_model:
  - name: sales_analytics
    datasets:
      - name: orders
        source: sales.public.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            description: Unique order id.
          - name: amount
            description: Order total.
        ai_context:
          instructions: "Use for revenue analysis and order trends. Always aggregate to at least country level. Do not join with PII tables without approval."

Columns and descriptions again map cleanly: fields was here for this. The quality rule again has nowhere to land, because Ossie’s field object has no key for quality, severity, or schedule, and the spec is explicit that it defines meaning rather than trust.

The context block is the interesting part here. Ossie has ai_context, which is aiming at the same target, and instructions maps across almost exactly. But ai_context supports instructions, synonyms, and examples, and nothing else. So the constraints get flattened into the instructions string, where a prohibition reads identically to a suggestion. And verifiedStatements, which exists so that an agent stops re-deriving an answer someone already curated, maps to nothing. Ossie has example questions. It does not have curated answers.

Both projections drop the same information, for entirely reasonable reasons. Neither specification set out to carry governance. Ossie’s own community has already opened a discussion about whether a semantic model should carry a reference back to its contract.

Summary of the Loss

If I look a little deeper at both specs, I can list the losses by OKF and Ossie, categorically:

• Quality rules and their execution metadata,

• Service-level agreements (SLA),

• Ownership, roles, accountable parties,

• Contract status and version,

• Curated question-answer pairs,

• Machine-readable prohibitions,

• Terms of use and access restrictions, and

• The identity link back to the contract.

Many other rich concepts in the Bitol standards, like authoritativeDefinitions and customProperties do not have an equivalent. Governance by tags, a popular ODCS/ODPS practice, is also not doable.

Adopt the Bitol Standards

A friend of mine in Sydney and I have a running joke: if a project has “Open” in the name, it usually is… not. Bitol and OpenLineage survive the joke, which is convenient for me but… suspicious for you?

ODCS and ODPS are part of Bitol. They are truly open standards under the Linux Foundation AI & Data, governed in the open, with no vendor holding the pen or users dictating their will. Thank you to that community, and to the Bitol TSC, for keeping it that way.

I welcome new standards and initiatives. It fosters the dialog and the co-construction of something better. This dialog often happens on Bitol's Slack channels, which are part of the 8900+ members of the DML community.

Come and join us in this community, adopt the Bitol open standards to maximize the return on your investment.

Read more on the Web

• Bitol, a graduated Linux Foundation project, https://bitol.io with links to its Slack and GitHub

• ODCS v3.1 specification, https://github.com/bitol-io/open-data-contract-standard

• ODCS v3.2 specification, https://github.com/bitol-io/open-data-contract-standard/tree/dev-v3.2.0

• Apache Ossie core specification,
  https://github.com/apache/ossie/blob/main/core-spec/spec.md

• OKF v0.1 specification (frontmatter fields, # Schema / # Citations conventions)
  https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md

Read more in the Data Intelligence Platform

Thank you to all the Bitol users, fans, and LF AI & Data for making this possible. Last week, Bitol graduated.

A unanimous TAC vote made it possible and wiped the suffering of arguing about the name of a property at 11 pm on Slack.

Scorecard

Graduating is a serious process with strict rules; here are Bitol's results:

• Sandbox (Sept 2023) → Incubation (Nov 2024) → Graduated (July 2026). Data-standards years are apparently longer than dog years.

• Code contributions from 11+ organizations, more than the 5 required. Actian, Entropy Data, Data Catering, Pickle, enChoice, Alliander, Agile Lab, Datashift, Protective Life, Barcelona Supercomputing Center, ALH Gruppe, and way more.

• 1,053 GitHub stars on ODCS alone, 1,166 combined with ODPS (and it keeps growing)

• OpenSSF Gold Badge (we had Silver at Incubation).

• 480+ commits in 12 straight months, every month.

• Two sibling-project collaborations (Egeria and Unity Catalog embed ODCS; Unity Catalog embeds ODPS too), against a bar of one.

• A two-thirds vote requirement at both TAC and Governing Board. Try getting two-thirds of anyone to agree on lunch. We got unanimous.

The number I keep re-reading

Organizations adopting ODCS and ODPS went from 9 to 114 in fourteen months. Thirteen times. Employees touched went from 1.1 million to 4.5 million. Countries went from 3 to 21. And, per the BARC 2026 study, 61% of organizations now report using data contracts at all, with 41% of those practitioners specifically on ODCS.

Linux Foundation Graduation

It is not a badge someone slaps on a repo because the vibes are good. It’s a checklist with teeth: contributor diversity, star thresholds, security posture held and re-earned, sustained commit activity, cross-project collaboration, a named technical lead on the TAC (hi, that’s me now), and a supermajority vote at two separate governing bodies. Clear all of it, or you don’t graduate. We cleared all of it.

Teamwork at Its Best

A twelve-person TSC that meets monthly and a working group that meets twice a week is at the root of this success: Andrea Gioia, Andrew Jones, Andy Petrella, Atanas Iliev, Diego Carvallo, Dirk Van de Poel, Jochen Christ, Martin Meermeyer, Patrick Beitsma, Simon Harrer, Tom de Wolf, and me, currently holding the gavel. Eleven companies, three flavors of stakeholder, nobody steering alone.

We also wrote the industry’s working definition of a data product. It’s on Wikipedia now. Nobody tells you that counts as a critical milestone. It needed to be before we created ODPS.

So: thank you to the TSC for the reviews, the respectful exchanges, and the Slack threads and meetings at hours no reasonable person should be awake for. Thank you to the TAC and the Governing Board for scrutiny rather than a rubber stamp.

The standard is finding its way into production, one contract at a time. It just got a lot harder to ignore. Full announcement, RFC trail, and the fine print: bitol.io/bitol-graduates. Come build with us: bitol.io and chat on Slack.

Today that number is 114

That is not a typo. In fourteen months, as of May 31st, 2026, Bitol adoption went from 9 organizations to 114, nearly a 13-fold jump, spread across 21 countries, three regions, and 15 sectors. The people within reach of these standards grew from 1.1 million to 4.5 million. The map lit up: EMEA leading with 75 organizations, the United States close behind, and a striking density in the Nordics and Benelux, where Norway alone shows roughly 1.5 organizations per million inhabitants.

Here is what I want you to feel as you read this: you are early. Early enough that adopting an open data standard still makes you a pioneer, not a follower. The frontier is open, and the people planting flags now are the ones the rest will follow.

The trust that made it real

If I am honest, the numbers are not what moves me most. The part that moves me is the trust.

When Bitol was nothing more than a charter and a good idea, the original Technical Steering Committee bet on it anyway. A deliberately diverse group of vendors, consultants, and practitioners from around the world chose to spend their evenings and weekends on a standard with no guarantee it would matter. They disagreed in public, argued about schemas, and shipped anyway. That trust, given before any of this was obvious, is the reason there is anything to celebrate today.

What the numbers are actually saying

Look closely, and the growth tells a story about momentum, not a plateau.

By count, this is a technology crowd. 50 of the 114 organizations are in software, IT, and information services; they are building services and tools around Bitol. But in terms of reach, the weight is with retail, industrial, and logistics giants, some of which employ hundreds of thousands of people. The giants moved first, and the builders are right behind them. That is exactly the shape you want to see early in an adoption curve.

And it is accelerating. ODCS reached version 3.0 in 2024 and 3.1 in 2025. Its sibling, the Open Data Product Standard (ODPS), hit its 1.0 milestone in 2025. More than a thousand GitHub stars now sit across the two repositories, a signal of developer mindshare that keeps climbing week over week.

Thank you, and come build with us

None of this belongs to any one person. So let me say it plainly.

Thank you to the Technical Steering Committee, past and present, for the trust and the tireless work. Thank you to the community, everyone who filed an issue, opened a pull request, corrected my thinking, or simply told a colleague this was worth a look. Thank you to the Linux Foundation AI & Data for giving these standards a neutral, durable home. And thank you to the Actian CTO Office for backing the belief that open standards make the whole industry stronger.

Which brings me to you.

The gold rush has not happened yet. What you are seeing is the frontier before the crowds, the moment when a small, determined group is proving that data contracts and data products do not have to be reinvented in every company, in every silo, forever. We can share the map.

If you have been watching from the sidelines, this is your invitation. Visit Bitol.io, read the standards, and adopt them. Then tell us how you use them. Share your ODCS data contracts, your wins, your workarounds, even the parts that made you argue with a schema at midnight. Every use case you post becomes a map for the next person. Bring your questions, your disagreements, your use cases. The best time to join a frontier is before everyone else realizes it is open.

Appendix: The Raw Numbers

Finding practitioners is hard. It is not like going to a major aircraft builder corporate website and seeing that they use ODCS in production. Numbers come from public testimonies, requests, RFPs, contributions to the codebase, and more. Help us. You can reach out and share confidentially with me.

Aggregate figures; each organization counted once. Reconciles with the workbook roll-up of 4.5 million, up from 1.1 million only 14 months ago.

At a glance

• 114 organizations across 21 countries, 3 regions, and 15 sectors use the Bitol standards.

• EMEA dominates: 75 of 114 organizations and roughly 60% of headcount.

• Size ranges from one-person tools to a retailer with around half a million staff; the median is ~2,600 employees and the top 10 are ~65% of headcount.

Reach by region

By organization size

Reach by sector

Where adoption is concentrated

Per capita, adoption looks densest in the Nordics and Benelux: Norway sits around 1.5 organizations per million inhabitants, with Belgium, Switzerland, and the Netherlands not far behind. Country attribution is best read loosely, since many of the larger names are multinationals.

How to read these numbers

Two lists, two stories. By count, this is a tech crowd: 50 of 114 are software, IT, and information services. By headcount, the weight sits with leaders in retail, industrial, and logistics giants.

The average lies. Mean headcount is ~40,000; median is 2,600, and the top 10 organizations account for ~65% of the people.

Methodology

Source. Figures come from the Bitol adoption register, an internal tracking sheet I maintain as the chair of the Bitol TSC, current as of 31 May 2026. Each organization that manifests interest in the Bitol standards (ODCS and ODPS) is counted once. Reporting is aggregate; individual organizations and their exact headcounts are kept confidential.

Why headcount. Company size is total company headcount, a consistent and publicly comparable proxy for reach, not the number of people actively working with ODCS or ODPS. Read it as potential reach. It is the framing we agreed on; it weighs larger companies more, but those are also where decisions are most strategic.

Baseline. “Date added” marks when an organization entered the register, not a precise adoption date. The March 2025 column is the first structured pass (9 organizations); the growth since is the register catching up.

What the stars mean. A GitHub star is a bookmark, not a deployment: someone flagged the ODCS or ODPS repo as worth watching. Read the combined count as developer mindshare and momentum, not proof anyone shipped to production. The stars row sums both repositories (1,038 combined as of 9 June 2026). Go star!

That assumption no longer holds. The consumer is now, increasingly, an LLM or an agent that has never met your data dictionary and never will. So the next versions of both Bitol standards, ODCS v3.2 (in progress) and ODPS v1.1 (draft), share a single theme: AI is no longer a use case bolted on at the end. It is the baseline.

ODCS 3.2 is dedicated to the memory of Peter Flook, a longtime contributor whose work shaped our data quality testing, the negative-test suite, schema validation, and more vendor onboarding than most of us will ever do. This release carries his contributions forward. Merci, Peter.

The headline: a context block for both standards

The centerpiece of this cycle is RFC-0038, a new optional context block that lands in ODCS and ODPS at the same time. Same shape, same intent, both layers of the stack. It exists for one reason: to give AI agents, LLMs, BI tools, and semantic layers the interpretive guidance that schema and quality rules never captured.

Three sub-fields, all optional:

• instructions: how this thing should be used, in plain language. “Use for revenue analysis and order trends. Do not use for individual customer PII queries.”

• verifiedStatements: canonical business questions, each with an optional curated answer. Entries with an answer should be returned verbatim when a query is semantically close; entries without a question can be used to prime text-to-SQL and help with disambiguation.

• constraints: the negatives. “Always aggregate to at least country level.” “Do not join with PII tables without approval.”

If you have ever watched an LLM cheerfully hallucinate a join, that last field is the one you have been waiting for. Positive descriptions tell a model what a column is. They do not stop it from doing something stupid with it. Negative guidance does.

And before anyone accuses me of selling vibes, the research is nicely detailed:

• Semantic catalog enrichment improved SQL accuracy by 27% (Tiger Data, 2026).

• Column type annotations alone bought 8%; semantic descriptions, 12%; hybrid metadata, 20%-25% (Mishra, 2025).

• Negative guidance and verified answers, the heart of Microsoft Fabric’s “Prep for AI,” prevent whole classes of hallucinated joins that positive descriptions never catch (Microsoft, 2025).

By standardizing, Bitol avoids having to write it in a dozen incompatible proprietary formats.

The pipeline behind it: more AI-native building blocks

The context block is the part that is merged. Behind it sits a cluster of proposed RFCs, all targeting 3.2, that pull the same thread: make the contract legible to a machine that has to reason about meaning, not just structure. None of these are sealed yet, and a couple still have open decisions, but the intent is unmistakable.

Measures and dimensions (RFC-0034). Today, a contract describes columns. It does not describe the metric a business actually argues about, the “Total Revenue” or “Average Basket Value” that every dashboard recomputes slightly differently. This RFC lets a property declare itself a measure or a dimension, so a KPI is defined once and read the same way by BI tools, catalogs, and an AI assistant trying to answer a question in business terms.

Synonyms (RFC-0041). Nobody asks an LLM for the chiffre_d_affaires_eur column. They ask about turnover, or sales, or TO, or, in my native language, the chiffre d’affaires. A synonyms field attaches alternative names to any object, so a natural-language tool can map the human word to the right field, across teams and locales. The exact shape is a rich object, which the TSC just ratified.

Vector type (RFC-0042). This is the one that makes a contract truly AI-native. A new vector logical type, with the dimensionality, element type, distance metric, normalization flag, and the embedding model that produced the values. Right now, an embedding column gets smuggled in as a generic array, losing everything a retriever needs to know. Standardize it, and a RAG pipeline can discover, from the contract alone, how to query the vectors and which model to embed the question with. No reverse-engineering of someone’s conventions.

Read together, the through-line is the same as the context block: the contract stops being a description a human reads and becomes an instruction set a machine can act on.

ODPS v1.1: products that announce what they are

On the product side, two changes are worth your attention beyond the shared context block.

• A top-level type field (RFC-0029): sourceAligned, aggregate, consumerAligned, or your own taxonomy. It sounds modest. It is the difference between a catalog you can filter and one you scroll through.

• Friendlier ports: every array object now carries an optional stable id, and input and output ports require only a name. Versions and contract IDs become optional, which makes early, iterative drafts far less ceremonious.

What this means if you are shipping data

• Practitioners: Start adding context.instructions and context.constraints to your most-queried contracts first. That is where text-to-SQL accuracy is bleeding today, and where you will feel the lift fastest.

• Leaders: This is the cheap insurance you keep asking for. AI projects fail due to trust and ambiguity far more than due to model quality. A context block is governance that an agent can actually read.

A word about how the sausage is made

None of this fell from the sky. It came out of the Bitol Technical Steering Committee, that small, stubborn, cross-company crowd who argue in public so you do not have to. I will let you in on a secret about running an open standard by consensus: pure democracy is slow, but it is remarkably efficient. The entire TSC once burned real cycles deciding what to name a single field, the whole room cycling through request, statement, question, example, and prompt before landing on verifiedStatements. Glacial? Occasionally. But nothing ships until everyone in the room can defend it, and that is exactly why you can build on it. To the TSC: thank you, sincerely, and please do not read this paragraph at the next meeting.

Neither version is final, and the two labels mean slightly different things. ODPS 1.1 is a draft: the shape is still being formed, and fields can still come and go. ODCS 3.2 is in progress: the big decisions have been made, and approved RFCs are landing, but the release is not yet finalized. In both cases, the work continues in the open. The direction, though, is set, and it is worth getting ahead of: your contracts and products are about to acquire a second audience that does not read documentation, does not attend the kickoff, and does not forgive ambiguity. Best to write things down where it can find them.

Early JSON Schemas can be found in the ODCS dev branch and the ODPS dev branch. Don’t forget to star ODCS and ODPS!

Sources

• ODCS specification and changelog, Bitol / Linux Foundation: github.com/bitol-io/open-data-contract-standard

• ODPS specification and changelog, Bitol / Linux Foundation: github.com/bitol-io/open-data-product-standard

• RFC-0034, Measures and Dimensions (Chabane, Arnaud, Guglielmoni, Perrin): github.com/bitol-io/tsc/blob/main/rfcs/0034-measures-and-dimensions.md

• RFC-0041, Synonyms (Chabane, Arnaud, Guglielmoni, Perrin): github.com/bitol-io/tsc/blob/main/rfcs/0041-synonyms.md

• RFC-0042, Vector Type (Perrin): github.com/bitol-io/tsc/blob/main/rfcs/0042-vector-type.md

• RFC-0038, Context Block for AI and Semantic Interoperability (Perrin et al., approved 2026-05-19): github.com/bitol-io/tsc/blob/main/rfcs/approved/odcs-v3.2.0/0038-context.md

• RFC-0029, Data Product Type Field (Harrer): github.com/bitol-io/tsc/blob/main/rfcs/approved/odps-v1.1.0/0029-data-product-type.md

• Tiger Data, Self-describing Postgres for LLMs (2026): tigerdata.com/blog/the-database-new-user-llms-need-a-different-database

• Microsoft Fabric, Semantic Model Best Practices: Prep for AI (2025): learn.microsoft.com/en-us/fabric/data-science/semantic-model-best-practices

• V. Mishra, When Tables Finally Started Making Sense (2025): medium.com/@vijayshankar.mishra

These articles are co-written by Anis Aknouche and Ole Olesen-Bagneux, the first one dives into LLMs, the second dives into KGs, and the third dives into their synergy. All three articles contain tangible ways that are useful for enterprise data management and science.

This article is part of a series of 3 articles to explain LLM + KG patterns. In this last part (3/3), we will talk about how Knowledge Graphs (KGs) and Large Language Models (LLMs) can mutually enhance each other in the same framework.

You can find the first article (1/3), where we talk about Large Language Models (LLMs) and how they can be enhanced using Knowledge Graphs (KGs) at KG-enhanced LLM (part 1/3), and the second article (2/3) where we talk about how Knowledge Graphs can be augmented using LLMs at LLM-augmented KG (part 2/3).

1. Synergized LLM + KG

In the previous two articles, we explored two complementary but one-directional integration patterns: KG-Enhanced LLMs, where structured knowledge is injected into language models, and LLM-Augmented KGs, where language models help build, complete, or query knowledge graphs. Both approaches are powerful in their own right, but they treat the relationship between LLMs and KGs as a one-way integration.

This article takes a different stance. Rather than asking “how can one technology serve the other?”, we ask: “how can they serve each other simultaneously?” This is the core idea behind Synergized LLM + KG, a fully bi-directional fusion where each modality continuously informs and improves the other.

The synergy of LLMs and KGs, as defined in Pan et al. [1], frames LLMs and KGs as a unified, mutually reinforcing system. LLMs provide KGs with language understanding and generalization capabilities, while KGs provide LLMs with explicit, structured, and interpretable knowledge. Neither technology is subordinate to the other, they act as dual engines driving a single, more capable system.

2. Synergized LLM + KG Approaches

The synergized paradigm materializes through two main technical directions: 1) Unified Knowledge Representation and 2) Joint Reasoning. Let’s walk through each.

2.1. Unified Knowledge Representation

The first direction focuses on learning shared representations that simultaneously encode both textual information and graph-structured knowledge. Rather than keeping language and graph modalities separate and only bridging them at inference time, these approaches train models that natively use both signals.

ERNIE [2] is one of the earliest and most influential examples. It introduces a textual-knowledge dual encoder architecture composed of two components: a T-Encoder, which processes the input sentence using transformer-based language modeling, and a K-Encoder, which separately processes a relevant subgraph from a knowledge graph. The two encoders are then fused, allowing entity mentions in the text to be grounded in their corresponding KG representations. The result is a model that understands both the linguistic context of words and the structured relationships between the concepts they refer to.

DRAGON [3] pushes this idea further with a self-supervised pre-training approach that jointly learns from text and KG data without requiring any labeled examples. The model takes as input a text segment alongside a relevant KG subgraph, and bidirectionally fuses information from both modalities throughout the encoding process. To optimize its parameters, DRAGON is trained on two complementary tasks: masked language modeling, which teaches the model to understand text, and KG link prediction, which teaches it to reason about relational structure. This dual pre-training objective forces the model to develop representations that are simultaneously grounded in language and in structured knowledge.

For enterprises, this kind of approach has real value, imagine a model pre-trained on your internal documentation and your company’s ontology at the same time. Queries that require both understanding natural language intent and navigating structured data relationships become tractable in a single forward pass.

2.2. Joint Reasoning

The second direction focuses not on representation learning but on reasoning: how can LLMs and KGs collaborate to answer complex, multi-hop questions that neither could handle well alone?

Two distinct strategies have emerged here. The first tightly integrates the two modalities within a shared architecture. The second keeps them separate and uses the LLM as an intelligent agent that queries the KG on demand.

2.2.1. LLM-KG Fusion Reasoning

In this strategy, the LLM and the KG are wired together so that they can interact at a fine-grained level during inference. The intuition is that when a language model processes a question, it should be able to “look up” relevant KG entities and relations in real time, and those entities should in turn influence how the model attends to the text.

JointLK [4] formalizes this intuition through a framework that enables fine-grained, token-level interaction between the language model and the knowledge graph. Specifically, it introduces a bi-directional attention mechanism with two components: LM-to-KG attention, which allows tokens in the text to attend to relevant KG entities, and KG-to-LM attention, which allows KG entities to attend back to the text tokens that are most relevant to them. This two-way flow of information allows the model to continuously align its linguistic understanding with the structured knowledge available in the graph, leading to more precise and grounded answers.

GreaseLM [5] takes a similar philosophy but implements it more deeply. Rather than adding an interaction layer after the LM, GreaseLM integrates rich, layer-wise interactions between text tokens and KG entities at every layer of the transformer. As the model processes input at each depth, it exchanges information with the graph, making the reasoning process progressively more informed by structured knowledge. This design is particularly effective for commonsense question answering, where answers often depend on implicit knowledge that must be retrieved from a graph rather than inferred from the text alone.

Both approaches share a key insight: the most powerful fusion is not a post-hoc bridge between two separate systems, but a deep architectural integration where language and knowledge co-evolve during inference.

2.2.2. LLMs as Agents Reasoning

A second and increasingly popular strategy takes a more modular approach. Rather than fusing LLMs and KGs at the architecture level, it uses the LLM as an intelligent agent that decides when and how to query the KG, interprets the results, and incorporates them into its reasoning chain. This is closer in spirit to how a human expert uses a reference database: not by memorizing it, but by knowing how to search it.

KSL [6] (Knowledge Selective Learning) teaches LLMs to actively search a knowledge graph for relevant facts before formulating an answer. Instead of relying solely on parametric knowledge baked into the model’s weights, KSL trains the LLM to issue targeted queries to the KG, retrieve the most relevant triples, and integrate that information into its response. This reduces hallucination and improves factual reliability, especially in domains where the underlying knowledge changes over time.

StructGPT [7] takes a more programmatic approach by designing a set of structured API interfaces that allow an LLM to directly access and navigate relational data. When faced with a question that requires traversing a KG, the LLM can call these APIs to retrieve neighbors, filter by relation type, or follow multi-hop paths, all within a single reasoning session. The strength of this approach is its generality, the same LLM can be used across different KGs simply by providing the appropriate API specification.

Think-on-Graph [8] goes even further by framing KG-grounded reasoning as a beam search problem. Given a question, an LLM agent iteratively explores the knowledge graph by selecting the most promising paths at each step, using the LLM’s language understanding to score and prune candidates. This process continues over multiple hops until a confident answer is found. Think-on-Graph is particularly compelling because it is fully plug-and-play: any LLM can be used as the reasoning engine, and any KG can serve as the knowledge backbone, without requiring any model fine-tuning.

Together, these agentic approaches represent a pragmatic and scalable path toward synergized LLM + KG systems, one that is already finding its way into enterprise search, data exploration, and automated knowledge base maintenance.

The synergy of LLMs and KGs is still an active and evolving research frontier. The approaches described above illustrate a rich design space: from tightly coupled architectures that fuse representations at training time, to loosely coupled agent systems that collaborate at inference time. Each point in this space comes with its own trade-offs in terms of accuracy, interpretability, scalability, and ease of deployment.

What is clear is that neither technology alone is sufficient for the most demanding enterprise applications. LLMs are powerful but opaque and prone to hallucination. KGs are precise but brittle and expensive to maintain. Their combination, when done thoughtfully, can address the weaknesses of each.

3. Challenges of Synergized LLM + KG

Despite the promise of synergized LLM + KG systems, several important challenges remain that both researchers and practitioners should be aware of.

1. Scalability is the first concern. Deep fusion approaches like GreaseLM and JointLK are computationally expensive. The tight coupling between LLM layers and KG entities requires running graph neural network operations at every transformer layer, which significantly increases memory usage and inference time. Scaling these approaches to large enterprise KGs with millions of entities is non-trivial.

2. Up to date knowledge is a second challenge. KGs are snapshots of knowledge that require ongoing curation to stay up to date. In real-world deployments, there is always a lag between the world changing and the KG reflecting that change. LLMs, trained on static corpora, face the same problem. A synergized system inherits the staleness of both, and no existing approach fully solves the problem of continuous, low-friction knowledge update.

3. Alignment and grounding remain difficult. Even in well-designed fusion architectures, it is hard to guarantee that an entity mention in text correctly maps to the right node in the graph, especially when entity names are ambiguous, domain-specific, or expressed in ways the model was not trained on. Poor alignment leads to noise being injected into the reasoning process rather than signal.

4. Interpretability is also a concern. While KGs are inherently interpretable (a fact is a triple: subject–relation–object), the fusion of KG representations with LLM activations produces intermediate states that are no longer human-readable.

5. Evaluation is hard. Most benchmarks used to evaluate synergized LLM + KG systems focus on question answering tasks that may not reflect the complexity and messiness of real enterprise data. Progress on these benchmarks does not always translate directly into production-ready improvements.

Conclusion

KGs and LLMs are not competing technologies, they are complementary ones. LLMs bring language understanding, generalization, and the ability to reason over unstructured text. KGs bring structure, precision, and interpretable relational knowledge. Alone, each has significant blind spots. Together, they can cover each other’s weaknesses in ways that neither can achieve independently.

The synergized LLM + KG pattern explored in this article represents the most ambitious expression of this complementarity. Rather than letting one technology serve the other in a one-directional handoff, synergized systems allow both to co-evolve: the LLM grounds its reasoning in the KG’s structured facts, while the KG benefits from the LLM’s ability to navigate language, ambiguity, and context.

To fully realize this potential, the field will need to incorporate additional advances, including multimodal learning to handle images and tables alongside text and graphs, graph neural networks to improve the expressiveness of KG encoders, and continual learning to keep both LLMs and KGs current without costly full retraining.

The practical upside is substantial. Synergized systems are already being applied to enterprise search, where both semantic relevance and factual accuracy matter, to recommender systems, where structured user and item attributes must be combined with behavioral signals; and to drug discovery, where navigating vast biomedical graphs and interpreting scientific literature are inseparable tasks.

The dual-engine metaphor is apt: with knowledge-driven graph search running in parallel with data-driven language inference, and with each engine validating and informing the other, synergized LLM + KG systems can tackle problems that single-modality approaches simply cannot. We expect this integration pattern to attract growing attention and growing adoption in the years ahead.

Key Takeaways

Synergized LLM + KG important advantages:

• Continuous Bi-directional Knowledge Enrichment

• Grounded Reasoning with Natural Language Fluency

• Reduced Hallucination with Verifiable, Traceable Outputs

• Unified Representation of Structured and Unstructured Knowledge

• Adaptive Knowledge Systems

References

[1] PAN, Shirui, LUO, Linhao, WANG, Yufei, et al. Unifying large language models and knowledge graphs: A roadmap. IEEE Transactions on Knowledge and Data Engineering, 2024, vol. 36, no 7, p. 3580-3599.

[2] ZHANG, Zhengyan, HAN, Xu, LIU, Zhiyuan, et al. ERNIE: Enhanced language representation with informative entities. In : Proceedings of the 57th annual meeting of the association for computational linguistics. 2019. p. 1441-1451.

[3] YASUNAGA, Michihiro, BOSSELUT, Antoine, REN, Hongyu, et al. Deep bidirectional language-knowledge graph pretraining. Advances in Neural Information Processing Systems, 2022, vol. 35, p. 37309-37323.

[4] SUN, Yueqing, SHI, Qi, QI, Le, et al. JointLK: Joint reasoning with language models and knowledge graphs for commonsense question answering. In : Proceedings of the 2022 Conference of the North American Chapter of the Association for Computational Lin.

[5] ZHANG, Xikun, BOSSELUT, Antoine, YASUNAGA, Michihiro, et al. Greaselm: Graph reasoning enhanced language models for question answering. arXiv preprint arXiv:2201.08860, 2022.

[6] FENG, Chao, ZHANG, Xinyu, et FEI, Zichu. Knowledge solver: Teaching llms to search for domain knowledge from knowledge graphs. arXiv preprint arXiv:2309.03118, 2023.

[7] JIANG, Jinhao, ZHOU, Kun, DONG, Zican, et al. Structgpt: A general framework for large language model to reason over structured data. In : Proceedings of the 2023 conference on empirical methods in natural language processing. 2023. p. 9237-9251.

[8] SUN, Jiashuo, XU, Chengjin, TANG, Lumingyuan, et al. Think-on-graph: Deep and responsible reasoning of large language model on knowledge graph. arXiv preprint arXiv:2307.07697, 2023.

I'll be presenting at the ACM SIGMOD/PODS Conference 2026 in Bengaluru, India next week.

It's a milestone for me.

This is an incredibly prestigious conference, and it's my first presentation in Bengaluru - the amazing Indian tech hub with so many brilliant people and enterprises.

My readers know that I am all about search.

My presentation "How AI is Changing Enterprise Data Search" will accordingly be about search. And there is a lot to tell. The very first use case for the AI revolution we currently find ourselves in was search - the battle of the bots, as The Economist has named the reconfiguration of the biggest business on the web; search. The era of the search engine has ended, and something new is emerging.

The AI-fueled reconfiguration of search is also hitting your enterprise data, and the way you search for data, and in data, is changing. This has consequences, and - if you architect with intelligence - it has advantages. Your enterprise will get ahead of your competitors, and deliver on data & AI agendas like never before, because of speed, precision and usability in searching data. For data, at the metadata layer, and in data, at the data layer itself. That's what I will be presenting, there is a sneak peak in the illustration below.

I present on the basis of our patented, technological advancements in Actian. Actian is the Data & AI division of HCLSoftware, again part of the entire HCLTech family. With our increasing number of customers, we build data Intelligence and AI solutions that are making a difference.

I also present on the basis of my two books published at O'Reilly :

📖 The Enterprise Data Catalog, and
📖 Fundamentals of Metadata Management.

My books are tech agnostic. This is important to me. I wrote my first book as an enterprise architect, not as an employee in a software company. I have written my books to provide simple, pragmatic, independent advice on how to set up data catalogs for success and effectively manage metadata altogether. I have the honor of having readers all over the world, this is my first time I get to present for my readers in India. I will be signing copies of Fundamentals of Metadata Management at our booth *D2* and I really hope to see you!

Also, because of continuous demand, I am writing the 2nd edition of The Enterprise Data Catalog, exactly because AI is changing how we search for data. I would love to engage in conversations on that, at SIGMOD.

This is a practical guide to making the topology decision correctly, before you’re committed to something that won’t survive contact with your production requirements.

Start with constraints, not preferences

The single most common mistake I see is teams starting the topology conversation with performance benchmarks or vendor comparisons. Those matter, but they’re the wrong starting point. Constraints come first, because constraints are non-negotiable and preferences are not.

Work through these six questions for each workload you’re building. Not for your AI system as a whole, but for each distinct workload, because they often have different answers and need to be mapped independently.

1. What is your latency requirement?

This is the question that eliminates options fastest. If you need sub-5ms retrieval, cloud is off the table regardless of everything else. The physics of a network round-trip don’t bend. A well-optimized cloud vector search returning results in 20ms is a genuinely impressive engineering achievement, and it’s still four times too slow for industrial fault detection or autonomous vehicle scene classification.

If your latency requirement is between 5ms and 50ms, on-premises is viable and cloud may be viable depending on your network topology. Above 50ms, cloud is typically fine and is often the lowest-friction option.

Be honest about this number. “We’d prefer fast” is not a requirement. Go talk to the product team or the operations team whose system you’re building for, find out what actually breaks if retrieval takes 100ms instead of 10ms, and use that as your constraint.

2. Where can your data legally sit?

This one catches teams off guard more than any other. GDPR, CCPA, HIPAA, FedRAMP, sector-specific financial regulations in various jurisdictions are non-optional. They constrain where data can physically reside and, in some cases, what infrastructure it can touch at all.

If you’re in financial services and building on transaction data, customer behavior models, or anything touching the trading ledger, assume data cannot leave your regulated perimeter until proven otherwise. If you’re in healthcare and working with anything that touches patient records, PHI controls apply. If you’re building for defense or critical infrastructure, you may be looking at air-gapped requirements that preclude cloud connectivity entirely.

Cloud providers have made significant investments in compliance certifications, and many regulated workloads can run in cloud with appropriate configuration. But “can” and “does in your specific jurisdiction with your specific data classification” are different questions. Get a definitive answer from your legal and compliance teams before you architect around a cloud deployment.

3. How large is your corpus, and how fast does it change?

Corpus size and update frequency interact in ways that affect both topology choice and index design within that topology.

Edge devices typically support 10,000 to 1 million vectors given their memory constraints. If your corpus is larger than that, edge-only retrieval isn’t viable without significant pruning or tiering. On-premises deployments handle up to hundreds of millions of vectors comfortably on modern hardware. Cloud is elastic and effectively unbounded.

Update frequency matters because it determines how stale your index will be under different sync architectures. If your corpus updates continuously throughout the day, an edge deployment with nightly sync is going to be operating on yesterday’s data for most of its working hours. That may be acceptable for some use cases and unacceptable for others. A product recommendation index at a retail POS can tolerate a day of staleness. A fraud detection system querying recent transaction patterns cannot.

The combination to watch out for is a large corpus with high update frequency at the edge. That’s the hardest operational problem in this space, and if your workload has both characteristics, be very deliberate about your sync architecture before you commit to edge deployment.

4. What is the connectivity model?

Cloud deployment requires reliable internet connectivity. That’s obvious when stated directly, but the implications are easy to underestimate. “Reliable” means reliable at the p99 or p999 level for production systems. Intermittent connectivity that causes an occasional slow page load in a consumer app causes a system outage in a real-time retrieval pipeline.

For edge deployments, the question is whether intermittent connectivity is an expected operating condition or an exception. Retail point-of-sale systems in locations with unreliable connectivity need to serve product recommendations whether or not they can reach the cloud. Industrial systems on a factory floor need to keep running during network maintenance windows. If intermittent connectivity is a first-class operating condition rather than a failure mode, your retrieval system needs to be designed for it, not around it.

On-premises sits in the middle. Your vector search runs on your internal network, which you control. External internet connectivity is typically not required for retrieval, though it may be needed for model updates, telemetry, or tooling.

5. What ops model does your organization support?

This is the question that gets the least attention in architecture discussions and causes the most problems in production.

Cloud-managed vector databases hand operational responsibility to the vendor. You don’t patch the infrastructure, manage the hardware refresh cycle, or handle the scaling events. The tradeoff is that you’re dependent on the vendor’s availability, pricing, and roadmap decisions.

On-premises means you own the operational lifecycle. Hardware provisioning, OS patching, index rebuild scheduling, capacity planning for growth, and the operational burden of keeping embedding models in sync across environments. This is manageable, but it requires investment in tooling and people. Teams that underestimate on-premises operational complexity end up with systems that were fine at launch and gradually degrade as indices go stale, hardware ages, and nobody has clear ownership of the maintenance cycle.

Edge is the most operationally complex of the three, because you’re managing a distributed fleet of devices that may number in the thousands, each running a local vector index that needs to stay reasonably fresh and running the right model version. Delta sync infrastructure, versioned snapshots, rollback capability, and fleet management tooling are all required, not optional. If your organization doesn’t have experience operating distributed device fleets, build that capability before committing to edge-first retrieval.

6. What does the cost structure need to look like?

Cloud vector search is operational expenditure: predictable per-query or per-storage pricing, but with egress costs that scale with data movement and can become significant at production scale. If you’re running millions of queries per day against a large corpus and paying per-query pricing plus data transfer, model the costs carefully before assuming cloud is the cheaper option.

On-premises is capital expenditure: servers, storage, networking, and the amortized cost of the people operating them. The per-query cost at scale is often lower than cloud, but the upfront investment is higher and the break-even horizon matters.

Edge hardware is a different category. You’re investing in compute at the device level, plus the infrastructure to manage it. The cost model depends heavily on whether the devices already exist for another purpose or are being provisioned specifically for AI retrieval.

Mapping workloads to topologies

Once you’ve worked through the six questions, the mapping is usually clearer than it seemed at the start. A customer-facing search or recommendation system with no data residency constraints, a corpus that updates continuously, and latency tolerances above 50ms is a good cloud workload. A fraud detection system for a regulated financial institution with strict data residency requirements and a stable corpus at high query throughput belongs on-premises. A field service application that needs to operate without connectivity, respond in under 5ms, and run on constrained hardware belongs at the edge.

Most enterprise AI systems have multiple workloads that map differently. A healthcare AI platform might have a patient-facing assistant that needs HIPAA-compliant on-premises retrieval alongside a research workload querying public literature that’s perfectly fine in cloud. Map each workload independently, then design the tier interactions: how data flows between tiers, what the sync architecture looks like, and how query routing decides which tier to hit for each request.

The decision you make second: index architecture

Once topology is settled, index architecture follows from the constraints you’ve already identified. At the edge, your memory envelope determines your index type. 256MB to 1GB typically forces you toward flat or product-quantized indexes. 2GB to 4GB opens up HNSW with aggressive quantization. Your recall ceiling is set by the memory you have available, not by what you’d prefer.

On-premises, you have enough memory to run HNSW at the recall levels you need, but you need to tune for your specific query patterns and hardware profile. The operational question is rebuild scheduling: when and how you rebuild the index as your corpus grows, without taking the retrieval system offline.

In cloud, index type is often an abstraction the managed service handles, but you still need to understand the recall versus latency tradeoffs in the service you’re using and ensure the SLAs it offers match your application requirements.

One thing to decide before any of this

Before you finalize your topology decision, settle your embedding model strategy. The model you use to generate vectors at index time must be the same model you use at query time. In a hybrid deployment where different tiers might be updated at different times, model version management is a real operational problem. If you upgrade your embedding model and re-embed your cloud corpus but haven’t yet synced to edge, queries hitting the edge tier return results from a different semantic space than queries hitting cloud. The results are silently wrong, with no errors thrown.

This isn’t a reason to avoid hybrid deployments. It’s a reason to treat embedding model versioning as infrastructure, not as an afterthought, and to build the coordination mechanisms before you need them.

The decision tree in one paragraph

If your latency requirement is under 5ms or connectivity is intermittent, edge is required for those queries. If your data legally cannot leave a defined perimeter, on-premises is required for that data. Everything else is eligible for cloud. Start with the constraints that eliminate options, then evaluate the remaining choices against corpus size, update frequency, ops capability, and cost. Most real deployments end up spanning more than one tier. Design for that from the start rather than trying to retrofit it when the first constraint you ignored shows up in production.

The topology decision is worth spending time on. It’s one of the few early architectural choices that genuinely constrains everything that comes after it.

I'm hosting the London edition of our dinners with leaders and thinkers in data & AI.

I think one of the most interesting consequences of AI is that it is making us reconsider so many elements of data - data management, governance, engineering, science, architecture. And we should discuss this more. So - let's do it!

It is my pleasure to host a dinner in the stunning Viñoly Room in the Fenchurch Restaurant in May, just before Gartner D&A London kicks off. You can join me

We can't guarantee room for everyone, as seats are limited.

One of the most interesting consequences of AI is that it is making us reconsider so many elements of data - data management, governance, engineering, science, architecture. And we should discuss this more. So - let's do it!

It is my pleasure to host a dinner in the exquisite Operakällaren in Stockholm in May, just before Data Innovation Summit kicks off.

There are so many people I would like to meet or meet again in Stockholm to discuss the changing reality in data and AI - you can sign up here

is a data & AI visionary that blends technical expertise with a deep understanding of human psychology. I happen to think that's a great combination, and I have enjoyed his books a lot - Humanizing Data Strategy and Humanizing AI Strategy. Thousands of readers all over the planet have too.

There are some things I want to hear him out about, regarding the strategies for data in the era of A, and I also have something to say to him. We decided to turn this into a meetup in Munich, with:

📖 Books
🍹 Drinks & Snacks
👀 Short, concise Data+AI talks and
💬 Interesting conversations!

It’s all for free - sign up in the comment below.

A personal - human - perspective: Tiankai Feng can get pretty rough with you, if you call him too friendly. Because he believes in starting with being friendly. Always. And I’ve seen my own values reflected in that, and even explained in that. I can't really see why we should address each other in any other way, as humans. Therefore I look so much forward to taking the stage with Tiankai. And I dare you - call us too friendly once, just once!

We will also be joined by the Chief Product Officer and tech visionary from Actian, Guillaume Bodet, as well as Tim Schäfer from Myposter, for compelling presentations.

Sign up here

I will be in London next week for an important conversation about Metadata in the age of AI. The role of metadata is changing, and really only for the better. It is getting increasingly strategic to manage metadata as guiding structures for AI.

Key takeaways from the panel will follow next week.

If you want to follow the book in the making, you can, right here.