Why "ready" depends on who's asking: a consumer-aware framework

The question nobody asks before starting

Most "ready" conversations start with a question about the data itself: is it clean, is it complete, is it in the warehouse. That question is necessary, but it isn't the one that determines whether a project ships. The question that actually determines it is: ready for whom.

A RAG index, an MCP tool, a knowledge graph and a feature store can all be built from the exact same source records, and still be almost unrelated engineering problems. Treating them as the same task, "get the data ready," is where a lot of otherwise well-run projects lose months: teams build one general-purpose pipeline, discover three sprints in that it serves none of the actual consumers well, and start over.

Same source, five different answers

Take a folder of support tickets. Five different consumers asked to use it will each need something structurally different back:

• RAG needs the tickets chunked by topic, embedded, and indexed with enough metadata to filter by product line or account before ranking similarity.
• An agent behind MCP needs typed tools: look_up_ticket, get_customer_history, each scoped to what the calling user is allowed to see.
• GraphRAG needs entities extracted from the ticket text (customers, products, people) and the relationships between them, not just the text itself.
• AI learning needs none of that: it needs numeric features derived from ticket volume and resolution time, computed as they looked at each point in time, not as they look today.

None of these is a better or more complete version of another. They're different shapes, built for different questions.

What "consumer-aware" changes in practice

A consumer-aware pipeline doesn't ask "how do we get this data ready" once. It asks "what does this consumer need" for every data product, and lets the answer determine the architecture: which fields get extracted, whether relationships matter, how fresh the output has to be, and what "correct" even means for the evaluation step.

That's the difference between building one pipeline and hoping it generalizes, and building the right pipeline for the job in front of you, from sources you've already connected once.