How Knowledge Hub keeps MyDataTalk from making things up

Ask an AI to explain a number from your database and it will happily do it, even when it's guessing. The schema tells it what columns exist, not what your business means by them. Is a "churned" customer one with status = 0, or one with no orders in 60 days? Which of the three amount columns is the one finance actually reports on? A model with no way to know the answer will still answer, confidently, and sometimes wrong.

Knowledge Hub is how we close that gap, and it's worth explaining exactly how it works, because the mechanism is what makes it trustworthy.

It's retrieval, not training

Nothing you add to Knowledge Hub trains or fine-tunes a model. There's no "teaching" step at all. Instead, every note or document you add (a definition, a policy, a past write-up, an SOP) is chunked and embedded into a vector index that's private to your account. When you ask a question, that specific question is embedded too, and the handful of most relevant chunks are pulled back and handed to the model as context, fresh, every single time.

That distinction matters: retrieval means the model's answer is only ever grounded in text you can point to. There's no black box "the model just knows this": if an answer cites a definition, that definition exists somewhere in your Knowledge Hub, and you can go read it.

Context comes before the schema, not after

When MyDataTalk builds the prompt for a question, your retrieved Knowledge Hub excerpts are placed ahead of the database schema, framed explicitly as business context. The model reads "here's what this business means by these terms" before it ever sees a single table name. That ordering is deliberate: it's the difference between a model that maps your question onto raw columns, and one that maps it onto your business first.

The part that actually stops hallucination

Grounding alone isn't enough: a model can still be handed good context and ignore it. So when a question has no connected database (you're asking Knowledge Hub something directly), the instruction it's given is explicit:

Answer the user's question using ONLY the knowledge-base excerpts provided below. If the excerpts don't contain enough information to answer, say so plainly rather than guessing. Do not invent facts beyond what's given.

That last line is the whole point. If nothing relevant has been indexed, you don't get a fabricated answer dressed up in confident language, you get told, plainly, that there isn't enough information. An honest "I don't know" is a feature, not a failure.

Two layers of context, working together

Knowledge Hub is one half of the picture. Each connection also carries its own business-context notes: the kind of thing that maps a domain pack's vocabulary onto your actual column names for that specific database. Knowledge Hub is broader (it applies across every connection you have) and retrieved fresh per question; connection context is narrower and always included. MyDataTalk merges both, knowledge-base excerpts first, before either ever reaches the model.

Why this is also a governance story

Because grounding is pure retrieval with no training loop, reasoning about what's safe to add is straightforward: policy documents, SOPs, metric glossaries, and chart-of-accounts exports belong in Knowledge Hub. Real transaction exports, customer statements, or anything containing PII or PCI data never do, the same way you wouldn't paste that into a shared doc. The index only ever holds what you explicitly chose to put there, which is what makes it possible to trust in the first place.