The two halves of enterprise data AI, and why almost nobody joins them

Ask a procurement lead why landed cost went up on one lane last quarter and you will watch them open two things: a BI dashboard, and a PDF of the carrier agreement. The dashboard has the number. The agreement has the reason. Nobody has a tool that reads both, so the analyst is the integration layer, and the answer takes two days.

That gap is not an accident of any one product. It is the shape of the market.

The document half

One category of tools indexes the document estate — contracts, reports, filings, wiki pages, tickets, email — and answers questions from it. Enterprise search and retrieval products such as Glean and Hebbia sit here, and they are good at what they do: find the passage, cite the page, summarise across a thousand files.

What they are not is connected to your governed numbers. They can find the clause that says surcharges are passed through at cost. They cannot tell you that the surcharge line on the Chengdu–Rotterdam lane moved 3.4 points last quarter, because that figure does not live in a document. It lives in a warehouse table, behind a metric definition, behind a permission model.

The metrics half

The other category starts from the warehouse. Text-to-SQL and conversational analytics tools — Dot, Zenlytic, Tellius, Snowflake’s Cortex Analyst among them — take a question in plain language, generate a query against a semantic layer, and return a number. The good ones are careful about it: they lean on defined metrics rather than guessing joins, and they show the SQL.

What they are not is aware of your documents. The system can tell you margin fell 3.4 points. It cannot tell you the July carrier change is the reason, because the carrier change is a clause in an agreement and a paragraph in a logistics review, and no amount of SQL reaches it.

The question always spans both

Here is the thing that makes this more than a product-comparison exercise. The questions that are cheap to answer sit entirely inside one half. The questions that are expensive to answer — the ones people actually escalate — sit across the join.

• What is our margin? One half.
• Why did our margin move, and does the contract let us recover it? Both.
• How many suppliers are past due? One half.
• Which past-due suppliers have a penalty clause we have not enforced? Both.
• What did we spend on this project? One half.
• Is that spend inside what the statement of work authorised? Both.

Every question in the second column is the one a director asks. Every one of them requires a system that can hold a number and a clause in the same reasoning step.

Why buying one of each does not work

The obvious move is to buy a document tool and an analytics tool and let people use both. It does not produce the join, for three reasons.

Nobody reconciles. When the report says one thing and the table says another — and at enterprise scale they disagree constantly, because the report was written against last quarter’s definition — two separate tools give you two confident answers and no signal that they conflict. A system that spans both can notice, and the useful behaviour is to surface the disagreement rather than average it away or silently prefer the source that happens to be indexed better.

The permission models do not compose. Your document tool has its own access control. Your analytics tool inherits the warehouse’s. Ask a question that spans both and there is no single place that decides what this particular person is allowed to see. In practice one of the two systems ends up more permissive than the other, and that is how an internal rollout gets stopped.

The reasoning is not recorded anywhere. If the join happens in an analyst’s head, then the method — which sources they checked, which they trusted, what they adjusted for — leaves with them. Next quarter the work is done again, slightly differently, and the two numbers do not match.

What spanning both actually requires

It is not a matter of pointing one model at two data sources. Four things have to be true at once, and each is unglamorous:

1. Documents parsed structurally, not flattened. A merged cell that becomes the wrong number is worse than a document you never indexed, because it fails silently. This is its own engineering problem.
2. Metrics that are defined, versioned and reproducible, so that the number the system quotes today is the same number it quoted in April, or it can tell you exactly what changed.
3. One permission model across both channels, applied server-side on every retrieval — not asked of the model in a prompt.
4. The analytical method itself stored as a reusable object, not improvised per question. This is the part almost nobody does, and it is the difference between a fast answer and a defensible one.

Where DataFact sits

We built for the join, which is why the architecture looks the way it does: one intake for documents and databases, one governed memory over both, and agents that plan retrieval across the two and cross-check what they find. Deployed as a subscription, or inside your own network when the data cannot leave.

That last option matters more than it sounds. The enterprises with the most valuable version of this problem — twenty years of contracts, a warehouse nobody fully understands, a regulator with a schedule — are frequently the ones who cannot send any of it to a third-party cloud. A join that only exists in someone else’s tenancy is not available to them at all.

If you want to see whether the join holds on your material rather than ours, send us one report and one table you actually argue about. That is the test worth running.