A bill of materials is one of the oldest ideas in industrial engineering. Before it was a compliance artefact, it was just a list: if you’re building a car door, someone needs to know it takes four bolts, one hinge, one panel, and one gasket, sourced from specific suppliers, in a specific order.
The bill of materials exists because complex things are made of simpler things, and if you don’t track the simpler things, you can’t answer basic questions later. Such as:
What’s in this object?
Who made the part that failed?
Can we build another one exactly like it?
Notice what the BOM is actually doing at its core: it converts an opaque finished object into a traceable graph of dependencies. That’s it. Everything else like compliance, audits, and recalls is downstream of that one move.
Software inherited this idea as the Software Bill of Materials (SBOM). A modern application isn’t hand-written from scratch. It’s assembled from hundreds of open-source packages, each with their own dependencies, licenses, and vulnerabilities.
The SBOM is the parts list for that assembly. It got real regulatory teeth after supply-chain attacks like SolarWinds made “what’s in this software” an urgent question rather than an academic one, and it accelerated further once the U.S. government mandated it for software procurement.
Once you accept that software is assembled from parts, it’s clear that so is a dataset, and so is a model trained on that dataset.
A training corpus is stitched together from scraped web pages, licensed archives, user-generated content, synthetic augmentation, and third-party feeds, each with its own provenance, license terms, and quality problems.
If a downstream model does something wrong, you want to ask the same question you’d ask about a faulty car door: which part caused this, and where did that part come from?
This is the reasoning that produced the Data Bill of Materials (DBOM), sometimes DataBOM, sometimes DBoM. The idea has been converging on a small number of teams from a few different directions:
Authors: Yue Liu, Dawen Zhang, Boming Xia, Julia Anticev, Tunde Adebayo, Zhenchang Xing, and Moses Machao (2024), out of Data61, CSIRO and IM&T, CSIRO, Australia's National Science Agency.
Concept: Ports the SBOM concept into a blockchain-based registry, where every dataset transformation (partition, merge, correction) gets recorded as a new on-chain version with its own metadata: identifiers, licenses, operation history, and the identity of the stakeholder who made the change. The explicit goals are traceability, verifiability, reproducibility, and accountability across a chain of custody.
Authors: Petar Radanliev, Omar Santos, Carsten Maple, and Kayvan Atefi (2026). Radanliev is at the Department of Computer Science, University of Oxford, and also affiliated with The Alan Turing Institute, London; Maple is affiliated with the Alan Turing Institute and University of Warwick (WMG); Santos is at Cisco Systems.
Concept: Pushes one layer up the stack, from data to the model itself: a CycloneDX-based schema that captures model lineage, training provenance, and disclosure metadata, with an automation pipeline that continuously inspects the environment, checks reproducibility, and flags vulnerabilities.
When we reduce each of them to their primitive operation, they converge to a similar shape:
Document a static artefact.
A DBOM is generated about a dataset or model, usually after the fact, and it describes a state: this model was trained on these sources, under these licenses, with this lineage.Built for a human or an institution to read.
The consumer of a DBOM record is an auditor, a regulator, a CISO, a data scientist searching a catalogue, or a compliance officer preparing a filing. Even the CSIRO paper’s protocol assumes a human researcher querying a registry before deciding whether to use a dataset, and a human data scientist reviewing an error report before publishing a new version.Trust, where it exists at all, is a one-hop check. You look up this dataset’s record, or this model’s record. Nothing in any of the four treats trust as something that has to be computed by walking a chain (dataset A feeds dataset B feeds model C feeds decision D) and asking whether the trust signal at the bottom of that chain is still valid at the top.
That third point is the important one.
Go back to the founding move of the BOM: it exists to answer questions for a reader, at the moment the reader needs the answer. On the factory floor, the reader is a technician holding a broken door. In software, the reader is a security team responding to a CVE.
In every DBOM example so far, the reader is a person, working on a timescale of hours, days, or audit cycles, deciding whether to trust something before they act on it, but with plenty of slack to look things up, ask a colleague, or wait for a report.
Now change the reader.
Suppose the consumer of a data product isn’t a compliance officer filing a quarterly report but an autonomous AI agent, mid-task, that has to decide in the next few hundred milliseconds whether to ingest a data feed, act on another agent’s output, or hand a decision downstream to a third agent it has never directly interacted with.
This is no longer a hypothetical: agentic pipelines already chain retrieval systems, tool calls, and sub-agents together, each one consuming the output of the last as if it were raw material.
Ask the fundamental question again: what does the reader need?
A human auditor needs a static, defensible record they can attach to a report. An autonomous agent needs something else entirely: a dynamic, cheap-to-check signal that answers “can I trust this input enough to act on it, right now, given everything that produced it,” and it needs that signal to survive being passed three or four hops down a chain of other agents, none of whom it can interrogate directly.
No research or implementations so far have built for that reader. And that’s not a criticism of them because it’s simply outside the problem they set out to solve.
If you take the BOM’s original insight seriously (a complex thing is a traceable graph of simpler things) and you take seriously that the reader has changed, three requirements fall out that none of the existing work covers together:
Trust has to propagate through the graph. A BOM for a car door doesn’t just say “hinge: sourced from Supplier X.” It implies that if Supplier X’s steel is later recalled, everything built with that hinge is suspect.
Existing DBOM work never takes this step for data: there’s no notion of a trust score on dataset A automatically discounting the trust score of model B trained on it, which in turn discounts agent C’s confidence in a decision built on model B’s output.
Trust today is looked up per-node. It needs to be inherited down the chain, the way a defect in raw material propagates to every finished part made from it.
Agents check signals in real time, which is very different from the timeline of a human reading a report. Every artefact surveyed here is point-in-time.
An agent operating on a dynamic decision can’t wait for the next audit cycle; it needs a signal cheap enough to check inline, and current enough that it reflects the state of the world now instead of the state of the world when the BOM was last generated.
The schema has to answer a different question. Every field in every schema reviewed here (license, lineage, operation history, disclosure metadata) is designed to answer “can a human justify having used this to a regulator or an auditor.”
None of them is designed to answer the narrower, more operational question an autonomous system actually needs answered before it acts: is this input, and everything upstream of it, trustworthy enough right now for me to proceed autonomously, without a human in the loop?
That’s a different schema, because it’s a different consumer with a different tolerance for latency and a different threshold for what “enough” means.
Put the three together and what’s missing is a relevant category of BOM application: Infrastructure for Agent-to-Agent Trust.
Where a trust signal is generated once, close to the source, and then propagates (composably, in real time) through however many autonomous hops a data product passes through before it reaches the agent that finally has to act on it.
The existing DBOM and AIBOM work has been necessary for us to build on these fronts of the new AI era. Let one part’s trustworthiness follow automatically into everything built from it at the speed an agent aspires to operate in.
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
Got questions? Find Animesh on LinkedIn or drop a comment below. 💬
Animesh authors frequently on Modern Data 101 alongside a growing community of Data and AI Experts who wield their pens to advance the field. Follow along or grab yours🖋
From the Modern Data 101 Team ❤
If two AI systems deliver identical business outcomes, why does one cost ten times more to run? Worth figuring out before your next budget review, read this to understand it better: Lean AI: Building a Scalable AI Foundation
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.