Resources / technical

Why every grounding technique needs the same thing underneath

The reliability problem in enterprise AI is a grounding problem: making sure the model's answer is tied to a verifiable source rather than improvised from its prior knowledge. Several techniques handle parts of this — fine-tuning, RAG, tool use, Skills — each with its right use case. They have one thing in common, and enterprise teams routinely skip past it: every technique conditions on whatever data is actually in front of the model, and most enterprise data isn't coherent enough to condition on.

Two ways a model adapts

There are only two mechanisms by which a language model adapts to your domain:

• In-weight learning — fine-tuning, where domain knowledge is encoded into the model's parameters. Static, useful for tone and terminology, weak for facts that change.
• In-context learning (ICL) — prompts, retrieved documents, tool definitions, Skills. Anything in the context window is something the model conditions on at inference time. No training, no weight updates, immediate effect.

Most modern grounding strategies are ICL strategies. The "RAG vs. Skills" debate is really an argument about which kind of ICL — retrieval-packaged content vs. procedural-packaged content — to use. They are not different categories of learning; the model conditions on prompt content the same way regardless of how it got there.

Where each technique fits

Treating these as competing categories produces bad architectures. Treating them as complementary tools produces good ones.

• Fine-tuning is the right choice for tone, formatting, domain vocabulary, and behaviors you want consistent without prompt-engineering every time. It's the wrong choice for facts that change, because the snapshot you trained on is the snapshot you keep recalling.
• RAG is the right choice for unstructured content — policies, contracts, knowledge bases, long-tail documents that don't fit in the prompt and update independently. It's the wrong choice when near-match answers aren't acceptable, because vector retrieval optimizes for similarity, not identity.
• Tool use (including structured database queries) is the right choice when an answer needs to be verifiable and current — pricing, balances, contract terms, sensor readings. The model translates the question into a deterministic operation; the answer comes from execution, not generation.
• Skills are the right packaging for procedural knowledge — how to use a capability, which sequence of tools to call, what the company's terminology means in this context. Skills are themselves ICL: modular, reviewable markdown pulled into context when relevant. They tell the model how, not what.

Most production systems combine three or four of these. RAG retrieves a contract clause; a Skill tells the model how to interpret it; a tool call validates the figures against the system of record; a lightly fine-tuned base model handles the formatting. That's a sensible architecture.

What ICL actually conditions on

The mechanism every ICL technique shares: the model reads its context window and produces output conditioned on what's there. That is the entire learning step. Whatever's in the context is the truth the model will work with for that turn — not because the model "trusts" it, but because it has nothing else to go on at inference time.

This is why dirty data is the silent killer of grounding strategies. RAG retrieves three contradictory chunks describing the same customer; the model averages or picks one. A Skill tells the model to look up the customer's status in the CRM, but the CRM has three different statuses across overlapping records. A SQL tool runs a join, but the join path is ambiguous because the same customer entity exists in multiple tables with subtle key drift. The technique was applied correctly. The substrate sabotaged the result.

You can't prompt your way out of a data layer that contradicts itself.

ConnectSphere's contribution is structural

[TODO: diagram showing the four grounding techniques as parallel layers sitting on a shared data substrate — design asset gap]

ConnectSphere doesn't replace RAG, fine-tuning, Skills, or tool use. It addresses the layer underneath all of them — the normalized data foundation that every grounding technique implicitly assumes and almost no enterprise actually has.

When the underlying data is normalized — every fact in exactly one place, every join path deterministic — each grounding technique becomes more reliable in proportion to how much it depends on the data layer:

• RAG over schema docs, API specs, and operational data retrieves consistent, non-contradictory descriptions. The model gets a single coherent picture of the data model.
• Tool use runs against a 3NF model where joins are unambiguous. The same question produces the same query plan and the same answer.
• Skills can describe procedures the model can actually follow without disambiguation, because the targets they point at are themselves unambiguous.
• Fine-tuning for terminology and format works as advertised, because the training corpus has consistent ground truth.

The leverage isn't replacing anyone's grounding stack. It's giving that stack a substrate it can rely on.

Pick your technique. Fix your data first.

The choice between RAG, Skills, fine-tuning, and tool use is a real engineering decision with real trade-offs. There are good reasons to favor any of them, and good reasons to combine them. None of those reasons survive contact with a data layer that contradicts itself.

Stop optimizing the technique. Fix the substrate.

Make your data talk. The technique becomes a detail.