Everything Matters. Not Everything Gets Read.
We slashed our ingestion costs just by understanding our data. Here's how: we instrumented every retrieval call our AI makes against live construction projects — and turned what we learned into an ingestion pipeline that adapts as usage evolves.
Arbel Haiman
Every number in this post is measured on this corpus — live capture of real production retrieval, no sampling, no synthetic data.
Construction projects generate a staggering amount of paper. Drawings, specs, submittals, RFIs, contracts, schedules — a single mid-size project can easily hold hundreds of documents and tens of thousands of pages. Our platform ingests all of it, and our AI answers questions on top of it.
That gives us a rare vantage point: we can measure not just what a project contains, but what its people actually ask about. So we instrumented every retrieval call our AI makes in production — live capture, no sampling — over an extended window, and traced each one down through the data hierarchy we ingest: projects → documents → pages → chunks.
This post is what we found. Every percentage is unmodified production data; customer organizations are anonymized to their trade, and we've kept absolute figures to rough scale on purpose.
The experiment
What retrieval touched — live production traffic
Against that corpus, thousands of queries were executed against hundreds of live projects — making tens of thousands of retrieval calls under the hood. That's the dataset for everything below.
The anatomy of a question
Start at the smallest unit. A typical retrieval call is remarkably narrow: it reads about 10 chunks, from 7 pages, in a single document. Even a typical query — which usually makes several retrieval calls under the hood as it reasons — settles at 29 chunks across 19 pages in 3 documents. And of what gets retrieved, only about a third survives into the final answer as a citation.
The anatomy of a question
What a typical question actually reads.
A query is one end-to-end question; it typically makes several retrieval calls under the hood as it reasons. Roughly a third of retrieved chunks survive into the final answer as citations.
Here's what that looks like against a real project. Watch the questions come in — and how little of the corpus each one opens:
Watch a project get questioned
A real project is a wall of documents. Every question lands on a tiny slice of it — a couple of documents, a few pages each.
Each question is a needle-in-a-haystack exercise: a tiny, focused slice of an enormous corpus. Which raises the obvious question — after thousands of needles, how much of the haystack has been touched?
All the queries combined barely scrape the corpus
Pool every retrieval event across every active project and weigh it against those projects' combined corpus, and the aggregate answer is: still a small slice. How small? Before we show you — care to place a bet?
Across the combined corpus of every active project, what share of all pages did retrieval touch?
The funnel narrows fast as you go down the hierarchy: 14.2% of documents were retrieved from at least once, but only 8% of pages and just 2% of chunks. Citations narrow it further — 6.7% of documents, 3.2% of pages, 0.7% of chunks ended up cited in an answer.
So we shouldn't ingest all that data, right?
Not quite. The pooled view hides what happens inside each project — zoom in to individual projects, and the story flips completely.
The bigger the project, the smaller the slice
Pooled totals weight every chunk equally, so a handful of giant projects dominate them. The honest way to look at it is one project at a time: for a typical project of a given size, how much of its own corpus do its queries end up touching? Time for your second bet.
In a typical small project (up to 20 documents), how many of its documents end up being queried?
Two patterns jump out:
- In small and mid-size projects — about three in five projects — every single document gets queried. 100% document coverage, again and again. Meanwhile the typical share of pages touched drops to the teens, and chunks to low single digits.
- The bigger the project, the thinner its queries spread. As projects grow, the share of their own corpus that questions touch collapses — a typical large project sees only a few percent of its documents and around 1% of its pages queried. And it's exactly those large projects that hold roughly four-fifths of everything we ingest. The corpus's weight sits precisely where usage density is lowest — not because that data doesn't matter, but because a large project's questions at any given phase concentrate on the working set that phase needs.
Documents are sampled exhaustively. Pages and chunks are not.
Across enough questions, users reach into virtually every document they have — you cannot predict at ingestion time which document won't matter, because empirically, they all do. But within documents, usage drops by an order of magnitude at the page level and another at the chunk level.
That asymmetry is the core finding. Coverage is total at the document level and sparse below it — which means the ingestion question is never whether to process a document, only how deeply.
Contractors focus on their trade — but read everyone's documents
Retrieval isn't just structurally concentrated; it's semantically concentrated too. We classified every retrieved chunk by the discipline of the document it came from, and broke it down per organization:
Where each contractor's questions land, by discipline
How each organization's retrieved information distributes across document disciplines. Each cell: % of that org's own retrieval; color is log-scaled per row.
Organizations are anonymized to their trade. Hover any cell for the exact share. Ring = the org's own primary trade.
The diagonal you'd expect is there: electrical contractors retrieve most heavily from electrical documents (34–49% of their activity), mechanical contractors from mechanical documents (21–59%), the flooring contractor from architectural finishes, the civil contractor from civil drawings.
But the more interesting finding is everything around the diagonal. No organization's primary trade exceeds 59% of its retrieval — for most it's a third or less. General/project-wide documents pull 8–46% everywhere, and nearly every row has meaningful activity across plumbing, structural, electrical, and mechanical alike. A mechanical contractor bidding coordination questions needs the electrical drawings. An electrical estimator needs the architectural set.
Trade focus, cross-trade awareness
Contractors show a significant focus on their own trade, but consistently reach into other trades' information. Half to two-thirds of what a typical contractor retrieves lives outside their primary discipline — cross-trade context isn't an edge case, it's the norm.
And this matrix carries an ingestion lesson of its own. You cannot know, before ingesting, which document will end up mattering — a mechanical contractor's next question may land on an electrical drawing. But you can know what kind of information each document carries: its discipline and type are visible on day one, and usage patterns like this matrix arrive right after. That's the difference between treating all information equally and ingesting it intelligently.
What this means for ingestion
Three lessons, straight from the telemetry:
- Never skip a document. The typical small-to-mid project ends up querying 100% of its documents — full awareness from day one is non-negotiable.
- Never spend equally. The overwhelming majority of pages and chunks are never touched — uniform deep processing is pure waste.
- You can't know upfront — but you can get close, then adapt. No classifier can predict the pieces of data nobody will ask about. What does work is a combined approach: predict the probably-less-touched data from feature signals — discipline, document type, and a few ingredients of our secret sauce — to set each document's initial processing tier, then let live usage adapt those tiers as the questions actually arrive.
So our pipeline is tiered: every document is ingested, indexed, and retrievable on day one — and depth is earned. Here's the whole idea in one interactive picture — ask it a few questions and watch what happens:
The tiered pipeline, simulated
Every document flows through ingestion on day one and lands in a tier — how deep is decided by a blend of signals. Queries hit pages on every tier; touch a shallow one, and that document earns its way deeper.
Tier placement blends discipline, document type, project phase, usage telemetry — and a few ingredients we keep to ourselves. No document is ever dropped; depth follows demand.
Be aware of everything. Deepen what earns it.
Full-corpus awareness is non-negotiable — the data proves users eventually reach everywhere. But retrieval telemetry tells us, org by org and project by project, exactly where deeper ingestion pays off. That feedback loop, from usage back into the pipeline, is how the system gets smarter about its own data.
We're already feeding these diagnostics back into how we prioritize ingestion work. The corpus keeps growing — but growth is exactly why intelligence about how data gets used matters more than raw processing power ever will.
Methodology: live capture of all production retrieval events over an extended recent window, measured per query. Organization names are anonymized, absolute figures are deliberately kept to rough scale, and all percentages are unmodified production data.
Related Posts
The New Product Development Flow
How we ship fast without losing alignment — code as the source of truth, AI-driven feedback loops, and lightweight quality gates that compound over time.
The Filing Cabinet Trap: Why Subcontractors are Losing Margins in the Cloud
Why Systems of Record aren't enough, and how Systems of Decision are the new competitive advantage for construction subcontractors.
The Death of Static Content: Why Traditional Articles Are Becoming Obsolete
An experiment in sharing technical knowledge differently. This article exists in two forms: a classic Medium-style piece and an interactive version. We're exploring what works when AI can generate endless content.