Grounding rules for work that has to be right

Three failures shape the AI setups I build for law practices.

In the first, Claude cannot open a web page it needs, so it answers from an older summary and never says so. In the second, it reads the text of an org chart and misses the reporting lines, which exist only in the image. In the third, asked to review a folder of documents, it opens only one of them.

None of the three is an invented citation. In each, hallucination does not look like invention. It looks like substitution, where the model works from less than the task requires and the answer hides the difference.

I am an immigration lawyer. Starting with no coding background, I built a verification stack for my own practice. I now consult for other attorneys through SolveWork, my AI consulting company. A basic version of that stack goes into the kits I build for them.

The habits below need no code. I use them in Claude, and in June I built a version for Microsoft Copilot.

Write the grounding rules before the first prompt

Grounding rules are standing instructions the model reads at the start of every session. In Claude Code they live in a file named CLAUDE.md. In a Claude Project they go in the project instructions.

The kits I build carry five accuracy rules. Every fact about a client traces to a file and a page, and if the model cannot point to one, it says so. Missing stays missing, so no assumption fills an empty field. Every citation to a statute, a regulation, or published guidance stays UNVERIFIED until a lawyer checks the source.

The last two rules govern how the model talks about its own limits. It must say "I could not check this" in plain words. It may not claim a tool can do something until that has been tested. In a setup session, we test a capability on a synthetic file before anyone relies on it.

Three source rules answer those failures, one each. Read the whole source, and say so when it cannot be read. For a page that changes, keep a dated copy in a templates folder. Look at images, because extracted text drops whatever was drawn. Open every file in scope and list what was read.

Two more lines carry much of the weight. One intake rule reads, "When a client document and a consult note disagree, list both and flag the conflict. Do not pick one." Every report ends with a line headed "Could not read or do," listing anything not completed, or "none." A report without that line is incomplete.

With that line in place, an unreadable page would appear as an entry the lawyer can act on.

Primary sources outrank agreement

In April, I hit a failure on an Arizona bar reciprocity question. Every secondary source agreed on the answer. The authoritative PDF said something different.

The rule I wrote afterward now sits in my standing instructions. A primary source outranks secondary sources, however many of them agree. Agreement among secondary sources measures how often a claim was repeated. It says less about whether the claim is true.

Deep research tools raise the stakes. They gather dozens of pages in minutes, and a stack of matching summaries reads like confirmation. Often those pages trace back to one original, or to each other.

The kits carry three research rules on the same point. The model does not cite from memory. When the research tool returns no source, the model says so. Absence from a search is not proof the rule does not exist. A result stays UNVERIFIED until a person opens the link and confirms it.

Run the research in separate tools and read the disagreements

The research loop I build into content systems requires every published piece to rest on research run in at least two separate tools from one brief. The disagreements between their reports are the point.

1. Claude writes a research brief from an interview with the author. Questions and claims to verify are numbered, and any background is labeled unverified and kept free of client facts. The author reads the brief before it runs.
2. The same brief runs in separate sessions, in Claude with Research turned on and in Perplexity's Deep Research, with ChatGPT Deep research as an option. Each tool gets an identical run line. It answers every question by its ID, marks NOT FOUND where no source answers, and adds no conclusion the sources do not support.
3. A fresh Claude chat lines the reports up by question ID. It flags every disagreement, every NOT FOUND, and every claim only one report makes, and it names the primary source that would settle each flag.
4. Each flag gets checked in the statute, regulation, decision, docket, or agency guidance itself. It ends VERIFIED, CORRECTED, or OPEN, and only the author can mark a claim VERIFIED.
5. Anything still open goes into a narrower brief that keeps the original question IDs, and the loop runs again.

The merged file keeps a claim register. Two of its columns record whether each source is PRIMARY or SECONDARY and which reports agreed.

Drafts may use only claims marked VERIFIED or facts the author supplied.

Sandbox the material before you analyze it

A sandbox is a workspace that holds only the material for one task. Bounding the material does two jobs. It keeps unrelated files out of the answer. It also makes the inputs countable, so a checker can compare what was read with what was there.

My case tracker holds no personally identifiable information. Matters go by a code built from the year, the case type, and a sequence number. My content systems carry a similar rule. No client information enters the project, and a client's matter reaches a draft only from the public record and only with the client's informed consent.

Before a live setup session, I build a synthetic client file for a fictional client, with five planted traps. One is an org chart whose reporting lines exist only in the image. Another is a scanned page saved as a picture, and a third is a photo too blurry to read. Two more carry file names that do not match what is inside.

The answer key sits in a separate folder the test run is told never to open. The rehearsal runs on a copy, so the originals stay clean for the live session. Real client files enter a skill only after a lawyer approves them for that skill, and the approval goes in a log.

Every work order I write carries halt conditions. One reads, "Any file that looks like real client data. Halt and report it without opening further." The settings in my kits block deletes and anything that sends. When an action is blocked, the model's instructions tell it to stop and report, and never to try another tool to get the same result.

The verifier never wrote the draft

A session that drafted a piece has already settled on its reading of the sources. Asked to check its own work, it tends to confirm that reading. So verification runs in a fresh session that did not write the draft.

The rehearsal follows that pattern. A second work order runs in a fresh Claude Code session that did not do the rehearsal. It reads the answer key and counts the files in each folder. It compares those counts with the key before it compares the run report's statuses. The work order reads, "Propose skill fixes, and do not apply them."

The same pass runs on my own writing. On one recent set of my deliverables, an independent reviewer agent caught stale citations to ethics rules and facts the drafting session had overstated. In the content systems I build, the author approves fixes by number.

My own work also splits planning from execution. One Claude plans and writes work orders in the Claude app, and Claude Code executes them in my repository. I sit between the two with the legal judgment. At each Tier 1 gate, the work order tells the executor to halt until I type DECIDED.

What grounding has bought so far

Every morning at 8:43, a scheduled task builds my daily docket. It reads my calendar, email, and Drive, plus the Federal Register, the Visa Bulletin, and the news. Then it names the one thing to do first. On October 21, the one thing was an item that had become ready to go, because the last pieces it was waiting on had come in.

Before the docket, I checked those sources by hand and asked Claude about my day. So far the docket runs with little intervention from me. I think that is because of the grounding I did on those tasks before I built it. It has not run long enough to show an error. Next I want my verification stack on it.

My kits add light telemetry. Each run appends one line to a log. It records the date, skill or work order, matter code, files in scope, items flagged, could-not-read count, and result. The kit owner reviews the log monthly. A rising could-not-read count shows which skill needs work.

A starter rule set

This is the general version of what I install for clients. Rules 6 to 8 are the three source rules above. Rule 6 exists because of an outdated summary. Rule 9 exists because of Arizona. Paste it into a Claude Project's instructions or a CLAUDE.md file. Add a rule each time something fails, and write the rule from the failure.

## Accuracy rules
1. Every fact traces to a file and a page. If you cannot point to one, say so.
2. Missing stays missing. Never fill an empty field with an assumption.
3. Mark every citation to law, regulation, or published guidance UNVERIFIED until I check it against the source.
4. Say "I could not check this" in plain words.
5. Never claim a tool can do something until it has been tested, on a synthetic file first.

## Source rules
6. Read the whole source. If you cannot open or read it, say so before going further. Never substitute a summary or an older version.
7. Look at images and scanned pages. Extracted text alone misses what was drawn.
8. Open every file in scope and list what you read.

## Research rules
9. Primary sources override secondary sources, however many secondary sources agree.
10. When a client document and a note disagree, or two primary sources conflict, list both and flag the conflict. Do not choose between them.
11. Never cite from memory. A search that finds nothing is not proof that nothing exists.

## Report
12. End every report with "Could not read or do," listing anything not completed, or "none."

The rules will not catch everything on their own. Pair them with a verification pass in a fresh session, and keep each task's material in its own bounded workspace.