foundation data layer for enterprise AI
Everyone sells a layer. What does a real foundation data layer hold?
Everyone sells a layer.
A foundation is defined by what it holds.
In short
A foundation data layer is a traceable, justified, persistent record of what an organization's own documents say, public and private, built once and used by every application above it. Its real test is private data: the side letters, credit agreements and committee memos that no model was trained on and no data vendor has structured.
On this page
Two words have stopped meaning anything in enterprise AI. "Layer" now covers storage, virtualization, data access, knowledge graphs and agent orchestration. "Unstructured" now means "we can send your PDF to a language model." A foundation data layer is neither a pipe that moves data nor a conductor that directs agents. Capital markets learned the value of a foundation after 2008, when the data needed to measure exposure to Lehman existed but was scattered across documents no system could aggregate. Enterprise AI is about to relearn the same lesson.
Why does every AI vendor now sell a "layer"?
Vendors sell a "layer" because buyers are told it fixes AI projects that lack AI-ready data.
This year I have sat across the table from banks, asset managers, sovereign investors and rating agencies in Asia and the Middle East. The conversations start differently but tend to reach the same moment. Someone says they are evaluating "a data layer for AI." I ask what it holds. The room goes quiet.
There is a second moment that comes up just as often. When I explain what SageX does, more than one prospect has told me they have already come across one or two companies doing something similar. I believe them. But when we dig in together, "similar" usually turns out to mean the same vocabulary, not the same thing underneath. The differences come up the same way each time:
They retrieve passages. A foundation resolves values.
They link to a file. A foundation traces each value to its page and phrase, and shows why it was read that way.
They answer afresh on every query. A foundation answers from a record.
They forget corrections. A foundation keeps them.
Neither the silence nor the confusion is their fault. Read a week of enterprise AI announcements and you meet the same word on very different products. A storage vendor calls its file systems the AI data layer. A virtualization platform uses it for a query abstraction over existing databases. A data-connection tool claims it for linking every system so data can be queried where it sits, without copying it anywhere. A knowledge-graph startup uses it for a map of entities. And "operating layer" now mostly means agent orchestration.
Storage, virtualization, access, graphs, orchestration. Five different things, one word.
"When a word means everything, it stops helping anyone decide anything."
The word is doing real work in budgets. Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data [1]. Buyers are told the fix is "a layer." Which layer, and what it should produce, usually goes unsaid.
This piece is an attempt to say it plainly: what a foundation is, what it holds, and how to test for one. Along the way it deals with the second word that has gone hollow, which is "unstructured."
What does "unstructured" actually mean?
Unstructured data, such as contracts, filings and reports, has structure that is implicit, undeclared or changing, rather than fixed in fields and columns.
"Unstructured" has become the second hollow word. Because a language model can read text, almost every AI product now claims to handle unstructured data. In practice that often means one thing: the PDF gets sent to a model, and something comes back.
The stakes are not small. Gartner puts unstructured data, "such as documents and multimedia files," at 70% to 90% of organizational data [2]. If "handling" it just means reading it on demand, most enterprise knowledge stays exactly where it is today: in files.
Unstructured does not mean structureless
The word misleads. A contract, a prospectus or an annual report is full of structure. It is just implicit, undeclared or changing, rather than fixed in a schema. Consider what sits inside a typical fund document:
Layout that carries meaning. Two-column pages, headers that scope everything beneath them, tables that run across page breaks.
Definitions that change the words. "Net Asset Value" on page 40 means exactly what the definitions section on page 3 says it means.
Structure that is dynamic. A schedule that appears in some versions and not others. Tables whose columns change from one fund to the next.
Scans, stamps and handwriting. Many of the most important documents are still images of paper.
A language model can read every one of these pages. Reading them is not the same as knowing what they say.
"A first-year analyst can read a prospectus. That is not why you hire a senior one."
Reading versus processing
| What "we handle unstructured data" often means | What it actually takes |
|---|---|
| Send the file to a model when someone asks a question | Read each document once and record what it is and what it covers |
| Retrieve chunks of text that look relevant | Extract exact values with their metadata and context |
| Let the model work out the answer each time | Resolve which document and version prevails, with human validation where required |
| Return an answer with a link to the file, and maybe a chunk of text | Trace each value to its page and phrase, with a justification that attests to how it was interpreted |
| Start fresh on the next query | Keep the result as a record, with every correction carried forward |
The left column is a capability. The right column is what unstructured data processing actually requires, and what a foundation does. The difference between them is the subject of the rest of this piece.
Pipe, conductor, rebrand or foundation: what does each one hold?
Strip away the branding and almost every "layer" falls into one of four roles. One question separates them: what does it hold when the request is over?
| Pipe | Conductor | Rebrand | Foundation | |
|---|---|---|---|---|
| What it does | Moves, stores or exposes data | Directs agents and workflows | The same thing it did before it was renamed | Turns raw documents into a durable record, with lineage and justification |
| What it holds afterward | Nothing new. The file is still unread | Run logs and task state | Nothing new. Only the name changed | What the documents say, structured, traced and justified |
| What it can explain | Where the file is | What it did, not why | No more than before | Why each value was read the way it was |
| Where accountability lives | With the source system | With the agent's output | Nowhere specific | With the record: every value traced to its source or to the person who set it |
Pipes and conductors are genuinely useful, and most enterprises need both. They just do not create anything that did not exist before they ran.
Availability is not understanding
The most common confusion is between availability and understanding. A tool that connects every system without copying the data can give an agent instant access to ten thousand contracts. If nobody has read them properly, the agent reads them for the first time, every time, on every query. It may reach a different answer on Tuesday than on Monday, and nothing in the stack remembers which one was right.
Faster access to an unread document is still an unread document.
A note on layer-washing
The rebrand column deserves a sentence, because buyers meet it often. Gartner has already flagged the pattern in agents, calling it "agent washing": existing AI assistants, robotic process automation tools and chatbots rebranded without substantial agentic capabilities. It estimates only about 130 of the thousands of agentic AI vendors are real [3]. "Layer" is going the same way. Regulators have noticed the broader habit too; the SEC charged two investment advisers over "AI washing" in March 2024 [4].
You do not need to know who is doing it to spot it. For any product that leans on the word, one test is enough: delete layer from the description. If the sentence still makes complete sense, the word was decoration. The reverse is also true: a system with a real foundation may never use the word at all. That is why the definition matters more than the vocabulary. We have felt the pull of the word ourselves. It tests well in pitch rooms.
Haven't we had this conversation before?
Partly. It helps to see where the existing conversations stop.
Systems of record are being redefined. At a DOSS-hosted panel with leaders from Google, Rippling, Retool and Airtable, one idea kept emerging: "a tightly governed core of truth surrounded by flexible, AI-managed context" [5]. Close to our view, but it is about operational software, not documents.
Platforms publish AI-ready data checklists. Salesforce tells teams to keep source metadata, preserve traceability and designate a source-of-truth system [6]. The right hygiene, framed as a checklist rather than an architecture.
Master data management solved it for structured data. The golden record assumes data already arrives in fields and columns.
Everyone agrees there should be a governed core of truth that AI draws from. Almost nobody says how to build it from unstructured data, which makes up most organizational data [2].
"The idea of a foundation is old. Building one from documents is the new problem."
What did capital markets learn about foundations first?
Capital markets learned first that reference data needs a golden source: one maintained, governed record that every downstream system reconciles against.
I spent more than fifteen years in capital markets data, with buy-side, sell-side, banks. The debate enterprise AI is having now is one market data infrastructure settled long ago, and the way it was settled is instructive.
The golden source
Every serious trading firm runs on reference data: who an issuer is, what a security is, which entity owns which. The industry learned early that this could not be re-derived by each desk, each system, each time. It needed a golden source: one maintained, governed record that every downstream system reconciled against. Trading screens changed. Risk engines were replaced. The golden source stayed.
Nobody called the trading screen "the data layer." The data layer was the thing the screen could not function without.
Documents need the same discipline, because they override each other over time. A prospectus sets a fee. A supplement amends it. A side letter changes it again for one investor. The clause that applied last year may not apply today. Which number is true depends on which document governs, and when. A golden source records that answer once, so nobody has to rediscover it.
What 2008 exposed
When Lehman Brothers collapsed in September 2008, regulators and firms could not quickly work out the market's exposure to Lehman, or how participants were connected [7]. The striking part is why. The information was theoretically available. It was spread across thousands of regulatory filings made by Lehman's hundreds of subsidiaries, and without consistent identifiers no system could aggregate it [8].
Read that again with today's eyes. The data was there. It was in documents. Nothing had turned those documents into a record anyone could trust and add up.
The response was foundational, not cosmetic. The G20 and the Financial Stability Board created the Legal Entity Identifier, and the first LEIs were issued in December 2012 [7]. In January 2013 the Basel Committee issued BCBS 239, its principles for risk data aggregation and reporting, with global systemically important banks (G-SIBs) required to implement them in full by the beginning of 2016 [9]. Neither was a new application. Both were about the record underneath.
And it was hard. In November 2023, more than ten years after BCBS 239 was issued, the Basel Committee reported that "additional work is required at all banks to attain or sustain full compliance" [10]. Building a foundation is slow, unglamorous work. That is precisely why it is worth so much once it exists.
"Capital markets did not fix 2008 with better dashboards. It fixed the record the dashboards read from."
The same lesson, one level down
That lesson was learned for structured data: identifiers, prices, positions. AI moves the problem one level down, into contracts, filings, side letters and reports. This is where today's version of the Lehman question lives. What do all our agreements actually commit us to? Which counterparties carry which obligations? Few of the institutions I meet can answer from a trusted record.
What does a foundation data layer actually hold?
Here is a definition you can hold any vendor to, including us:
A foundation data layer is a traceable, justified, persistent record of what an organization's own documents say, public and private, built once and used by every application above it.
Each word in that sentence carries weight:
Traceable: every value leads back to its source, either a page and phrase or the human action that set it.
Justified: every value carries the reasoning behind its interpretation, plus a human verification where one is required.
Persistent: the record outlives the query, the model and the application.
Used by every application: it is shared, not rebuilt inside each tool.
Concretely, that record holds four things that pipes, conductors and rebrands do not.
1. The extracted truth
Not the file, and not a pile of text chunks. The actual values: the fee rate in clause 7.2, the counterparty on page 3, the covenant threshold in schedule B. Typed, dated and resolved, and verified by a human where required. A supplement that amends a prospectus is reflected in the number rather than left for a model to rediscover on every query.
2. The lineage
Every value carries its origin: which document, which version, which page, which words. Or, where an analyst set the value directly, which person set it and when. When an answer is challenged by a regulator, an auditor or an investment committee, it can be walked back to its source in seconds.
3. The justification
Context alone is not enough. A page reference shows where a value came from, not why it was read that way. The justification is the interpretation logic. It might explain why "Net Asset Value" follows the page 3 definition, why the supplement prevails, or why an analyst set the value by hand and on what grounds. It lets an auditor agree or disagree with the reading, not just find the page.
4. The memory of corrections
When an analyst fixes a wrong value, the fix becomes part of the record. Every future query and every future application benefits. Without this, the same error gets corrected by hand, again and again, in each tool that meets it.
"A foundation is defined by what it holds, not by where it sits in the diagram."
Models, agents and copilots sit on top of this record. As they improve, they draw on the same lineage and justifications instead of starting over. The record is what you keep.
Why is private data the real test?
Every definition sounds reasonable until you ask which documents it has to work on. For most institutions, the documents that matter most are the ones nobody else has.
Public data is already a commodity
Annual reports, regulatory filings and public prospectuses are available to everyone. Data vendors already structure them, and language models have read much of that public record in training. An AI strategy built only on public documents stands on the same ground as every competitor.
Private data is where the edge, and the risk, lives
The documents that decide outcomes are private: side letters, credit agreements and amendments, investment committee memos, client mandates, due diligence files. In insurance it is policy wordings and claims files; in healthcare, payer contracts; in law, matter files. No model was trained on them and no vendor has structured them. Most sit in shared drives, read once by whoever needed them that week.
This is where every word of the definition earns its place. Decisions made on private documents get audited, so every value must be traceable to its clause or to the person who set it. Their language is negotiated and specific, so every reading must be justified, with the reasoning recorded and verified where required. They are read once and forgotten, so the record must be persistent. And without one shared record, every tool re-reads your most sensitive files on its own terms, multiplying both cost and exposure, which is why it must be built once and used by every application.
Private and public, in one record
The greatest value comes when the two meet. A sovereign fund's exposure is set in private fund documents and confirmed by public filings. A lender's covenant sits in a private credit agreement and is tested against published accounts. A foundation that holds both, with the same lineage and justifications, answers questions neither source can answer alone.
One practical point follows, though it sits outside the definition. A record of what your private documents say is among the most sensitive assets you own. A foundation holds true wherever it runs, but most institutions will rightly want it built where their data already lives, inside their own environment.
"Public data tells you what everyone knows. Private data tells you what only you know. A foundation is how you make the second one usable."
Why does this matter more now?
For the last two years, enterprise AI mostly answered questions. A chatbot that misread a contract gave a wrong answer, and a person usually caught it before anything happened.
Agents change that. An agent that misreads a contract does not just answer wrongly. It acts: it books the fee, flags the breach, sends the notice, rebalances the position. The cost of a misread document moves from embarrassment to consequence.
Gartner expects agents to make at least 15% of day-to-day work decisions autonomously by 2028, up from 0% in 2024. It also expects more than 40% of agentic AI projects to be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls [3].
Those two forecasts point at the same gap. Agents will be trusted with decisions only when the data they act on can be traced, justified and corrected. An agent built on a pipe is guessing quickly. An agent built on a foundation is acting on a record.
"Chatbots made misreading documents embarrassing. Agents make it expensive."
What are the strongest objections?
A definition is only worth something if it survives pushback. Here are the four we hear most, with the part of each that is right.
"Isn't this just master data management or a data warehouse?"
Same purpose, different source. MDM and warehouses assume data arrives in fields and columns. A foundation data layer creates those fields from documents, resolves conflicts between them, and retains the lineage and justification for every value. It feeds your warehouse and MDM; it does not replace them.
"Long-context models can read the whole document every time. Why extract anything?"
This is the serious one, and models are improving fast. Four problems remain.
Reliability: peer-reviewed 2025 research found that "the sheer length of the input alone can hurt LLM performance," even when models can perfectly retrieve all the relevant information [11].
Consistency: reading afresh on every query means the same question can get different answers, and nothing records which was right.
Cost: every re-read of a long document is billed again in tokens. Caching discounts repeat reads but does not make them free, so a hundred questions over the same contract are still a hundred billed readings.
Memory: an analyst's correction, and the lineage behind each answer, vanish when the session ends.
Better models make extraction faster and more accurate. They do not remove the need to keep the result, or the need to keep costs down.
"Isn't retrieval-augmented generation enough?"
Retrieval is a good pipe. But it returns chunks, not resolved values, so it cannot tell you the side letter overrides the prospectus. More fundamentally, context by itself is not enough. A retrieved passage arrives without interpretation logic: nothing says why it applies, or how it should be read against the passages around it. A foundation keeps a justification with every value. RAG cannot. Retrieval works best on top of a foundation, not instead of one.
"We can build this ourselves."
Some firms can, and for differentiating work they should. But the foundation is the part every firm needs and none competes on, and most of its cost arrives after the demo: handling new document types, keeping extraction accurate as models change, and maintaining lineage and corrections at scale. So build what makes you different, and buy the foundation. We go deeper in Build vs buy: should you build your enterprise AI data pipeline in-house? and The hidden cost of building production AI in-house.
How do you test whether something is really a foundation?
You do not need to take any vendor's word for it, including ours. These five tests follow from the definition. A true foundation passes all of them.
| Test | The question to ask | A foundation | Everything else |
|---|---|---|---|
| 1. Trace | Pick any answer. Can you walk it back to the exact page, version and words? | Yes, in seconds | To a file or text chunk, if at all |
| 2. Justify | Ask why the value was read that way. | Shows the recorded interpretation logic and verification status | Gives an answer, or an explanation regenerated differently each time |
| 3. Repeat | Ask the same question 10 to 15 times. | Identical every time, because it comes from the record | Varies, because each run is a fresh reading |
| 4. Correct | Fix one value. Does the fix hold for every user and application? | Yes, the fix joins the record | Lost when the session ends |
| 5. Resolve | Give it conflicting documents and a hand-set value. Does it know which prevails, and why? | Yes, with the governing source or human justification recorded | Uses whichever passage it happened to retrieve |
How to run the tests
Take 50 of your own documents with known answers, including a set where a later document overrides an earlier one. Write 20 questions. Run each one 10 to 15 times, ask for the source and the reasoning behind every answer, correct two wrong values, and set one value by hand with a written justification. Then check what held.
A single run proves little. For example, if a supplement amends a prospectus fee, a retrieval-based tool may return either number, depending on which passage it retrieves and how the model reads it on that run. Fifteen runs will show you. The full plan is in the checklist below.
Where does SageX sit?
SageX is the system that builds this foundation for you, and we wrote the definition so we could be measured against it.
It applies golden-source discipline to documents, especially the private ones no model was trained on and no vendor has structured. It extracts the values that matter and resolves which document prevails when they conflict, with a human verifying where required. Where an analyst sets a value directly, with no single source document, SageX records that decision and the reasoning behind it. Every value carries its lineage and a justification for how it was read. Every correction is carried forward. Public filings sit in the same record, with the same lineage.
SageX also acts as a harness for the models that run on top. As better models arrive, they plug into the same record, inherit its lineage and justifications, and deliver better answers, decisions and workflows without starting over. The foundation evolves with the models instead of being rebuilt for each one.
Run the five tests on us. That is what they are for.
Put any layer to the test
Download the Foundation Test checklist. A five-test plan you can run on any vendor that claims to be your data layer, including us. It covers which documents to pick, the questions to write, what counts as a pass, and a one-page scorecard.
The Foundation Test checklist
- Free PDF, 2 pages
- Five tests and a scorecard
- Opens right after you submit
The Foundation Test
Five tests. A true foundation passes all of them.
References (11 sources)
[1] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk", press release, Feb 26, 2025.
[2] Gartner, "Gartner Data & Analytics Summit 2026 London: Day 2 Highlights", press release, May 12, 2026.
[3] Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", press release, June 25, 2025.
[4] U.S. Securities and Exchange Commission, "SEC Charges Two Investment Advisers with Making False and Misleading Statements About Their Use of Artificial Intelligence", press release 2024-36, Mar 18, 2024.
[5] DOSS Engineering Team, "Software Teardown: Systems of Record", Apr 9, 2026, panel with leaders from DOSS, Google, Rippling, Retool and Airtable.
[6] Salesforce Trailhead, "Assess Unstructured Data Readiness for AI", accessed October 2026.
[7] U.S. Office of Financial Research, Legal Entity Identifier FAQs, accessed October 2026; LEI Ireland, "History of the Legal Entity Identifier System", Jan 14, 2020.
[8] GovLoop Staff, "What the Legal Entity Identifier Means for Financial Regulation and Open Data", Mar 15, 2016.
[9] Basel Committee on Banking Supervision, "Principles for effective risk data aggregation and risk reporting - final document issued by the Basel Committee", press release, Jan 9, 2013.
[10] Basel Committee on Banking Supervision, "Basel Committee report on implementing Principles for effective risk data aggregation and reporting shows progress made but significant work still remains", press release, Nov 28, 2023; report: "Progress in adopting the Principles for effective risk data aggregation and risk reporting", Nov 28, 2023.
[11] Du et al., "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval", Findings of EMNLP 2025.
Frequently asked
What is a foundation data layer?
Why does private data matter so much for a foundation data layer?
What does "unstructured data" really mean?
How is a foundation data layer different from a data fabric, virtualization or RAG?
Can't long-context AI models just read every document when asked?
How can I tell whether a vendor's "layer" is really a foundation?
Models will change. The foundation is what you keep.