Stravoris
← Back to Insights

From Product to Dossier: Building Case-Level Retrieval (The Paralegal Pattern)

·AI Industry Insights

AI Tactical Playbook

Most RAG systems behave like a search box with better adjectives.

You give them a question, they vector-search across everything, pull back "relevant" chunks, and hope the model can stitch something together. That's fine for shallow FAQs. It fails immediately in environments where people work around cases:

  • a product and its entire manufacturing history
  • a contract and all its amendments
  • a property and everything that's ever been filed against it
  • a claim, a patient, a project, an incident

Ask a product engineer, paralegal, or claims investigator how they actually work. They don't say, "I ran a good search." They say, "I pulled the file," or "I built a pack for that case."

That's the pattern this article is about: case-level retrieval, or what I'm calling the Paralegal Pattern. Instead of retrieving documents, we build a dossier.

If last week's "librarian" article was about how to ingest knowledge intelligently, this one is about how to pull it back intelligently—anchored around two ideas:

  • a Case Key that everything hangs off
  • an Answer Pack that looks a lot more like a case folder than a search result list

And, once you have those in place, how to let the system remember what it learns about a case over time.

1. Start with the Case Key

Everything in this pattern starts with something very boring and very powerful: a stable identifier.

In different domains it looks like:

  • ProductID or AssemblyID in manufacturing
  • MatterID in legal
  • ClaimID or PolicyID in insurance
  • PropertyID in real estate
  • PatientID / EncounterID in healthcare

Whatever you call it, this Case Key is the anchor. It's the thing you can point to and say:

"All of this—these tests, these deviations, these diagrams, these emails, these clauses—belong to that."

During ingestion, every artifact that logically belongs to a case needs to be tagged with its Case Key:

  • test reports and logs
  • BOM fragments and part records
  • SOPs and work instructions that apply to this product only
  • regulatory filings tied to this device or drug
  • contracts, amendments, side letters that all refer to the same matter

Sometimes you'll have multi-case artifacts (e.g., one regulatory change affecting several products). Tag them with multiple keys. That's fine. The point is: when a question comes in about Product 3142, you don't want to be searching the entire universe. You want to pull the 3142 dossier.

Without a Case Key, retrieval is just "semantic fishing." With one, you have a spine.

2. From "a pile of documents" to "a dossier graph"

Once everything is tagged with a Case Key, you can start organizing the case the way a paralegal or investigator would: as a web of connected evidence, not a bucket of files.

For a single product, that might look like:

  • this deviation belongs to that test run
  • that test run applies to this revision
  • this revision was introduced because of that supplier change
  • this clause in the regulation applies to that product category
  • this diagram shows that valve and that loop

You don't need a PhD-grade ontology here. A simple set of relationships is enough:

Source → relationship → target "Deviation 76 → occurred in → TestRun 443" "Amendment 2 → supersedes → Clause 5.2"

The result is a dossier graph: a small subgraph per case that tells you what belongs in the file and how it connects.

This graph is what turns "find me some chunks" into "build me the case."

3. Retrieval like a paralegal, not a search box

Once you have a Case Key and a dossier graph, retrieval stops being a single vector search and becomes a short, deterministic process.

A paralegal does something like this:

  1. Confirm which case we're talking about.
  2. Pull the summary sheet and key structured facts.
  3. Pull the supporting documents and evidence.
  4. Assemble a pack that the lawyer can actually work from.

Your retrieval pipeline should do the same.

Step 1 — Identify the case

Given the user's question, figure out which case it refers to:

  • sometimes it's explicit ("Show me all open issues on Product 3142")
  • sometimes you infer it ("Valve V-17" → look up in BOM → find its product)
  • sometimes you use a small LLM classifier to choose the Case Key

If you get this wrong, everything else is wrong. So treat it as a real step, not an afterthought.

Step 2 — Pull structured facts first

Before you touch any documents, go to the systems of record:

  • ERP / PLM for product and part metadata
  • SQL / LIMS for test results and measurements
  • MDM for lineage and hierarchies

Build a small structured summary: revision, status, key flags, test counts, applicable regulations—whatever matters in your domain.

This is what a human expert "knows in their head" before they even open a document. Your system should give the LLM the same luxury.

Step 3 — Expand to narrative and evidence

Now use the dossier graph and semantic search within this case to gather:

  • the specific test logs involved
  • SOP steps that mention the relevant parts or limits
  • diagrams where the component appears
  • clauses and amendments that apply
  • investigation notes or CAPA records

Notice what you're not doing: you're not letting the model sift through semi-random snippets pulled out of the entire enterprise. You're assembling the case file.

Step 4 — Turn that into an Answer Pack

The final step in retrieval isn't "hand everything straight to the LLM." It's to build an Answer Pack: a structured bundle that says, in effect:

"Here is what we know about this case, and here is the evidence you're allowed to use."

That pack becomes the search space—and the thing an SME can inspect and critique.

4. The Answer Pack: a machine-readable case file

Think about the last time you had to brief someone on a complex issue. You didn't forward twenty attachments and hope for the best. You prepared a pack:

  • "Here's the current status."
  • "Here's the key data."
  • "Here are the relevant documents and excerpts."
  • "Here's how it all hangs together."

The Answer Pack is that, but for your RAG system.

It usually includes four kinds of material.

4.1 Grounding: the case summary

First, a short, structured picture of the case:

  • what entity we're talking about (Case Key and basic metadata)
  • which revision or version is current
  • what state it's in (released, under review, deprecated, etc.)
  • any obvious flags (open deviations, pending approvals, major incidents)

This is the "cover sheet" of the dossier. If this section is wrong, the answer will be wrong, no matter how fancy your embeddings are.

4.2 Structured facts: the backbone

Next, facts pulled from your systems of record:

  • counts (how many tests, how many failures)
  • numerical limits and thresholds
  • dates, timestamps, effective-from / effective-to
  • references to other systems (supplier IDs, batch IDs, related cases)

These are the things you don't want the model hallucinating. They give the answer a skeleton that's measurable and verifiable.

4.3 Evidence excerpts: the human context

Then you add the narrative and visual material:

  • the specific paragraphs from test reports that explain a failure
  • the SOP step that describes the operation in question
  • the snippet from the regulatory filing that defines the requirement
  • the part of the diagram where the valve or circuit appears
  • the investigation note that explains the deviation

You're not dumping entire PDFs. You're pulling the salient excerpts tied to this case and this question.

4.4 Relationship hints: how it all connects

Finally, a little bit of relational glue:

  • "This deviation belongs to TestRun 443, which is part of Qualification Phase 2 for Product 3142."
  • "Clause 5.2 is superseded by Amendment 2 for this product line."
  • "Valve V-17 appears in Diagrams P-004 and P-005 and is referenced in SOP-17 Step 7."

These are short, declarative statements that help the LLM follow the same chains of reasoning a human would normally articulate.

Put together, the Answer Pack becomes:

  • the search space for the answer
  • the artifact you can show to a domain expert and ask, "Is this the right material?"
  • the thing you debug when the answer is wrong ("Did we pull the right tests? The right clause?")

The model's job is to read the pack, synthesize, and explain. The heavy lifting is how you built the pack in the first place.

5. Case Memory: "What do we already know about this?"

In real work, people rarely ask one question per case and walk away. They circle back:

  • "Wait, why did we change that supplier again?"
  • "Remind me which revision fixed the leak issue?"
  • "Didn't we already test this condition in the previous campaign?"

Humans accumulate context. Most RAG systems don't.

Once you have case-level retrieval and Answer Packs, you can start treating each interaction as a chance to enrich the case.

After an answer is generated (and ideally, after a human has validated it), you can:

  • Extract durable facts from the Q&A, e.g.:
  • Normalize and store them in a simple Case Facts document or table, attached to the Case Key.
  • Pull those facts back into future Answer Packs so the system starts every new question with:

You're not just caching answers. You're building up a small, structured memory per case—like an investigator's notebook.

Done well, Case Memory:

  • reduces repeated searching and re-explanation
  • keeps answers consistent over time
  • makes follow-up questions much easier to handle
  • slowly turns the AI into "the one that remembers the entire history of this case"

It's also a great bridge between RAG and more traditional knowledge management.

6. Permissions: who's allowed to see what in the dossier?

One more practical constraint: in real organizations, not everyone is allowed to see everything in the case.

Some examples:

  • financial terms hidden from vendors
  • personally identifiable information hidden from non-clinical roles
  • internal-only test logs hidden from external auditors

In a paralegal pattern, permissions are not a wrapper you bolt on at the end. They shape the dossier itself.

That means:

  • filtering candidates by ACL before they enter the Answer Pack
  • ensuring the Case Facts document respects the same rules
  • never letting the LLM see documents the user wouldn't be allowed to open directly

Done right, this gives you a comforting property:

"If it wasn't in the user's world before, it won't suddenly appear because they asked a creative question."

Closing: Retrieval that feels like working with a real person

The Paralegal Pattern is, at heart, very simple:

  • Start with a Case Key, not a query string.
  • Maintain a small dossier graph around that key.
  • Retrieve like a professional: structured first, evidence second.
  • Assemble a curated Answer Pack that a human could review.
  • Let the system build Case Memory over time so it stops acting like it has amnesia.
  • Treat permissions as part of what the case is, not a bolt-on.

When you do this, retrieval stops feeling like "fancy search" and starts feeling like working with a junior analyst or paralegal: someone who knows where the files are, can pull the right ones, remembers what you figured out last week, and hands you a coherent pack to think from.

That's the level of behavior we need if we want RAG to survive contact with real work.