AfterDesk
EN
Apply

Working with AI

Grounding a model in your sources

Most people ask a model what it knows, then spend an hour proving the answer wrong. Grounding is the alternative: you supply the text, and the model is allowed to answer only from it. This course teaches how to hand over a corpus, demand a locator on every extracted fact, spot the lines that drifted outside it, and sample the result. Verification becomes a spot check, not a redo.

8
lessons
~67
minutes
12
exam questions

Free · No paid tier · No certificate fee

After this course

Everything, and what is in it.

Ask the document, not the model

~8 min

Two questions that look alike

There are two questions you can put to a language model, and on the screen they look almost identical. The first is what do you know about supplier payment terms in this industry. The second is what does this contract, supplied below, say about payment terms. The first draws on everything the model absorbed in training, blended together, undated, impossible to trace. The second draws on four thousand words sitting in front of it. Same tool, same session, completely different risk. The first answer has to be researched from scratch before you can use it. The second answer can be confirmed by reading one paragraph. Almost every task you claim can be rewritten from the first shape into the second.

Recall fails without a warning

When a model answers from memory it is producing text that fits the question, and fitting is not the same property as being true. It will name a payment term of thirty days because thirty days is the most common thing to write there, not because your contract says thirty. Nothing in the output marks the difference. You get one confident sentence, correctly punctuated, in the same voice it uses when it is right. So every fact in a recall answer arrives as a job for you: find the real source, read it, confirm or correct. That is the whole task again, performed twice. Recall saves you no time at all on anything you are accountable for.

Reading is a smaller job

A grounded answer is different in kind. The material is in front of the model, the answer is supposed to be a transformation of that material, and you already hold the source. When it tells you the payment term is forty-five days from invoice date, you open your own file, search for the word invoice, and you are finished in twelve seconds. You are not researching. You are matching one claim against one place. That is the whole promise of grounding, and it is why this course sits where it does in the curriculum. The model does not become honest. Your ability to catch it becomes cheap enough that you actually do it, every time, on every row.

Say it out loud in the prompt

Grounding is not automatic because you happened to paste something. You have to instruct it. The sentence that does the work is blunt: answer only from the text below, and if the text does not contain the answer, write not in the document. Put the material after that instruction, clearly fenced with a line reading SOURCE BEGINS and a line reading SOURCE ENDS, so it is obvious where your own words stop. Then ask your question. Without that instruction the model is free to blend what it just read with what it already carried, and it will, because blending usually produces a better-sounding answer. You are trading a smooth answer for a checkable one. Take that trade every time.

What this buys you tonight

Consider a task with a 60-page policy manual and eleven questions the client wants answered from it. Ungrounded, you would ask the model, receive eleven fluent paragraphs, and then read the manual anyway to confirm each one, which is the original task plus an hour of typing. Grounded, you supply the relevant chapters, demand a page and a short quote with every answer, and then verify eleven quotes by searching for them. The second version finishes in half the time and is more accurate than working by hand, because searching for an exact phrase never gets tired at four in the morning. The speed comes from the checking being cheap. Nothing else.

Remember

  • Recall answers must be researched. Grounded answers only need matching.
  • Say it explicitly: answer only from the text below.
  • Fence your source so the model knows where your words end.
  • Grounding does not make the model honest. It makes catching it cheap.

Paste the text, not a description

~8 min

A description is an invitation

The commonest mistake is describing the material instead of supplying it. I have a client onboarding email, write me a follow-up that references the discount we mentioned. The model has no email. It has your six-word sketch of an email, and it will fill the rest with the most typical onboarding email in existence, complete with a discount percentage you never mentioned. Every gap you leave gets filled with an average. That is not carelessness on the tool's part, it is what generation does when nothing constrains it. If the material exists and you are permitted to use it, supply it in full. If you cannot supply it, understand that you have asked for an invention and treat the output as one.

Check the lane before you paste

Grounding only works on material the model is holding, so the first question on any AfterDesk task is what you are permitted to hand over. Client files, client text and client data do not go into third-party tools. That is the promise the client was given, and silence in a brief is not permission. Three lanes are open to you. A brief can grant written permission naming a tool and a purpose, and that named material is then yours to supply. Material that is public, invented, or your own is always available. And the AfterDesk assistant inside a task you have claimed is built for method questions: it never sees the task record, the client, the files or the price, only what you type. Check the lane, then ground.

Paste enough, and paste it whole

When you are permitted to supply the material, supply all of the part that matters. Half a table is worse than no table, because the model will answer from the visible half and speak about the whole. Do not trim the boring rows. Do not remove the header row, which is the thing that tells it what column three means. Do not supply page 4 and describe pages 5 and 6 in a sentence, because that sentence then becomes the source for pages 5 and 6, and it is your paraphrase rather than the document. If the passage runs long, that is a chunking problem and lesson seven handles it. It is never a reason to summarise a source before the model has read it.

Fence it and name it

Put a visible boundary around the material. A line reading SOURCE BEGINS above it and a line reading SOURCE ENDS below it is enough, and it does two jobs. It tells the model which text is material and which text is instruction, which stops it treating a sentence written inside a contract as an order to follow. And it gives you something to point at: answer only from what falls between SOURCE BEGINS and SOURCE ENDS. If you supply more than one document, name each one, Document A, Document B, with a line saying what it is and what date it carries. Named documents are what make locators possible later, because a fact can then be tagged to Document B rather than to nothing.

Keep the shape of the data

Text that arrives as a table should stay a table. When you copy forty rows out of a spreadsheet and they land as one run-on paragraph, the model loses the column boundaries and starts guessing which value belongs to which field, which produces errors that are wrong in a way that is very hard to see. Paste as tab-separated or comma-separated lines, one record per line, and check that the first three lines still look like records before you continue. The same applies to headings in a long document: leave them in, because they are the locators you will ask for later. Formatting is not decoration here. It is the skeleton the model uses to know where things are.

Remember

  • A description gets filled with averages. Paste the material itself.
  • Check the lane first: permission, public, invented, or the in-product assistant.
  • Never summarise a source before the model has read it.
  • Fence the source so instruction and material cannot be confused.
  • Paste rows as rows. A flattened table produces invisible errors.

Demand a locator for every fact

~9 min

A fact needs an address

An extracted fact with no address attached is not much better than a guess, because you cannot tell the two apart. Suppose the model returns 45 findings from a 30-page audit report and every line reads like a finding. To check them you would reread the report, which is exactly the work you were trying to compress. Now suppose every line carries a page number and eight words quoted from the source. Checking one line is a search and a glance, roughly ten seconds. Checking all 45 is under ten minutes, and you would have spent longer than that reading the report once. The locator is not bureaucracy. It is the thing that converts verification from rereading into matching.

Name the locator you want

A locator is whatever lets you land on the exact spot in seconds. In a paginated document it is the page number, plus the section heading if the page is dense. In a spreadsheet it is the row number and the column header, and if the file has a stable identifier column, that identifier instead, because row numbers shift the moment someone sorts. In an email thread it is the sender and the date. In a transcript it is the timestamp. In a web page you were permitted to use, it is the heading above the paragraph. State which kind you want in the prompt, in the same sentence as the task. Vague requests for sources produce vague sources, which are worse than none because they look like diligence.

Make it quote, not paraphrase

Ask for a short exact quote alongside the locator, five to fifteen words, copied verbatim. This is the strongest single technique in the course and it works for a mechanical reason. A quote can be searched. You take the phrase, press find in the original file, and either it is there or it is not, and no judgement enters into that test. A paraphrase cannot be tested this way, because you have to read the surrounding text and decide whether it is a fair rendering, which is slow and arguable. Demand verbatim and say so plainly: quote the exact words from the source, do not tidy them. Tidied quotes are the ones that fail your search, and a failed search is a finding worth having.

Put it in a table

Ask for the output as rows with fixed columns: the claim, the locator, the quote, and a confidence field if the task warrants one. A table forces a locator for every single item, because an empty cell is visibly wrong in a way that a missing citation inside a paragraph is not. It also makes your own check mechanical. You work down the locator column instead of through prose. And it hands the operator a delivery that can be reviewed at speed, which matters when your work is read against a written standard before the client ever sees it. Ask for tab-separated rows if you intend to paste the result into a sheet, and name the columns in the prompt exactly as you want them.

Refuse a bare answer

The habit that makes this stick is refusing to accept output that lacks locators, even when you are in a hurry and the answer looks right. If you asked for page numbers and half the rows have none, do not fill them in yourself and do not let them through. Send it back: every row needs a page and a quote, write not in the document where you cannot find one. Rows that come back still bare are the rows to distrust first when you spot-check. Over a few tasks you will notice something useful. The items a model cannot locate are, far more often than chance, the items it invented. An empty locator column is a confession, and you should read it as one.

Remember

  • A fact with no address cannot be checked faster than it can be redone.
  • Name the locator you want: page, row, heading, timestamp.
  • Demand a verbatim quote. A quote can be searched. A paraphrase cannot.
  • Ask for a table. Empty cells are visible. Missing citations are not.
  • Rows that arrive without locators are the rows most likely invented.

Spot the moment it left the text

~8 min

Smoothness is the tell

Real documents are lumpy. They contradict themselves between sections, they use the same word for two different things, they leave a clause hanging, and they contain a sentence clearly written by somebody who was angry at four in the afternoon. When your extraction reads as though one calm person wrote it with a style guide open, something has been smoothed. Watch for output where every finding has the same length and the same grammatical shape, where three different departments suddenly share one vocabulary, or where a messy handwritten form turns into tidy title case. Smoothness is the sign that generation has taken over from reading. Go and look at the source for two of the smoothest lines. If those are paraphrases, the rest are too.

A confident answer to a gap

The second tell is a complete answer to something the document does not address. You ask what the notice period is for termination and receive a clean sentence about ninety days, when the contract you supplied covers renewal and pricing and never mentions notice at all. Nothing in the reply signals the absence. The model produced the shape of an answer because a question was asked, and answering is what it does. This is why you should read your own questions before you read the answers, and mark the ones you already suspect the document may not cover. Those are the answers to check first. A document that answers everything you ask is rarer than a model that will pretend it does.

Round numbers are suspicious

Real figures from real files are ugly. Invoices land on 4,287.60. Headcounts come out at 143. Percentages sit at 37.4. When your extraction is full of 5,000 and 20 percent and half the customers, look hard, because roundness is a signature of generation. The same goes for dates that all fall on the first of the month, ranges that run neatly from 2020 to 2024, and counts that arrive as a tidy 100. None of this proves anything by itself, since real round numbers exist and a contract really can say 30 days. It is a flag telling you where to spend your checking. Take every suspiciously round figure and search the source for it. That is five minutes of work and it catches the worst errors.

Words the file never used

Skim the output for vocabulary that does not belong to the source. A warehouse operations log does not contain the phrase key stakeholders. A supplier writing a hurried email does not say pursuant to. When a term shows up in your extraction that you never saw in the material, search the source for that exact word. If it is absent, the sentence containing it was written rather than read, and everything around it deserves the same suspicion. This tell is easy to use because it costs one search. It is also the tell that survives when you are tired, since you do not need to hold the whole document in your head. You only need to notice that a word feels imported, then check whether it is.

The half-grounded answer is the dangerous one

The output that harms you is not the obviously invented one. It is the answer where nine details are lifted correctly from the source and the tenth is not, sitting in the same sentence, in the same voice, beside a locator that points to a real page. The correct nine buy your trust and the tenth rides in behind them. This is precisely why you check individual rows rather than judging the output as a whole. Judging as a whole means judging the average, and the average of a grounded extraction is good. What reaches the client is one wrong number in one row. So never write that the extraction looks right. Write which rows you opened, and what you found in them.

Remember

  • Real sources are lumpy. Uniform, tidy output means something was smoothed.
  • A clean answer to a question the document ignores is generated.
  • Round numbers are a flag for where to spend your checking.
  • Search for words that feel imported. An absent word marks a written sentence.
  • Nine correct details buy trust for the tenth. Check rows, not impressions.

Make it say not in the document

~8 min

Give it a way to fail

A model will answer every question you ask, because that is the default behaviour and nothing in your request tells it otherwise. If you leave no acceptable way to fail, it will succeed at all costs, and the cost is invention. So give it an exit and make the exit explicit. The instruction is one clause: if the answer is not stated in the source, write not in the document and nothing else. That clause changes the output more than any amount of careful phrasing elsewhere in the prompt, because it converts a gap from something to be papered over into a legitimate result. You are not asking the tool to be modest. You are giving refusal somewhere to go.

Say what a non-answer looks like

Be specific about the form the refusal takes, because a vague permission to say you do not know produces hedged prose instead of a clear blank. Fix the exact string: write NOT IN DOCUMENT in the claim column and leave the quote column empty. Fixed strings are searchable, countable and sortable, which means you can filter a 200-row extraction down to the twelve gaps in one move and hand the operator a precise count. Forbid the middle ground as well: no inference, no likely, no the document implies. If a fact requires two steps of reasoning across two pages, you want that flagged rather than silently performed. Inference belongs to you, because you are the one accountable for it.

Test it with a question that must fail

Before you trust a grounded run, slip in one question you already know the source cannot answer. Ask a 12-page catering contract for the supplier's VAT registration number when you have read it and know it is not there. If the reply is not in the document, the grounding is holding and you can proceed with the rest. If it produces a plausible number, you have learned that everything else in that run is suspect, and you learned it in thirty seconds instead of at QC. Run this check whenever you change how you are asking, and whenever a document is unusually long. It is the cheapest single test in this course, and almost nobody does it.

Never seeing a refusal is a warning

Track how often the refusal actually appears. Across a real working week of grounded extractions from real documents, some questions will simply not be answerable, because documents are incomplete and people forget to write things down. If you have run thirty extractions and never once seen not in the document, that is not a run of luck. Either your instruction is not landing, or your questions are so soft that anything counts as an answer, or the tool is filling gaps and you are not catching it. A model that refuses sometimes is a model whose other answers mean something. A model that always answers has told you nothing about any of them.

Deliver the gap, do not fill it

The last step is yours, and it is the one that bends under deadline pressure. When the extraction comes back with nine gaps out of sixty, you deliver nine gaps. You do not use the industry norm, you do not carry a value down from the row above, and you do not insert a general figure because an empty cell looks unfinished. In your note to the operator, name them: rows 12, 19 and 44 have no stated payment term in the source, and I searched the document for term, days and net. That note is one minute of typing. It tells the operator exactly what to check and what to ask the client, and it is the difference between an honest delivery and a quiet fabrication.

Remember

  • A model with no way to fail will invent rather than refuse.
  • Fix the exact refusal string so gaps are countable and searchable.
  • Plant one unanswerable question. A plausible answer condemns the whole run.
  • A tool that never refuses is not telling you anything.
  • Deliver nine honest gaps. Name them in the note to the operator.

Spot-check a grounded extraction

~9 min

Sampling replaces rereading

Once every row carries a locator and a quote, you no longer verify by rereading the source. You verify by sampling, the way a factory checks a batch. The logic is simple. A grounded extraction either has a systematic problem, which shows up quickly in any sample, or it is broadly sound with occasional slips, which a sample of the right size will also surface. What sampling cannot do is guarantee that every row is correct, and you should never claim that it does. What it gives you is a defensible statement: I opened fourteen of the ninety rows, chosen across the whole document, and all fourteen matched the source at the stated locator. That sentence is worth far more to an operator than a confident nothing.

Decide how many rows to open

For a run under 30 rows, check all of them, because the whole check takes under ten minutes and sampling saves you nothing worth having. Between 30 and 200 rows, check about fifteen, and add more when the task is high stakes: money, legal terms, medical detail, anything the client will act on directly. Above 200 rows, twenty to twenty-five well-chosen rows will tell you what you need. These numbers are not statistics, they are a working floor built for the hours you actually have on a night shift. Adjust upward when one error would be expensive, and never adjust below ten on an extraction you did not read in full. Ten seconds a row is the budget you are working inside.

Never take the first ten

The first rows are the worst possible sample, and everybody takes them because they sit at the top of the screen. Early rows come from the beginning of the document, where the material is freshest and the model performs best. They are also the rows most people check, which means anything wrong there was likely to be found anyway. Choose deliberately instead. Take a few from the middle, a few from the very end, every row with a suspiciously round number, every row whose quote is unusually short, every row about money, and the rows whose locators cluster on a single page, because a page carrying twelve findings is either very dense or partly invented. Pick the rows an error would hide in.

Let the failure rate decide

The result tells you what to do next, and the thresholds are worth memorising. Zero failures in fifteen means proceed, deliver, and state in your note what you sampled. One failure means fix that row, then check fifteen more, because one is either bad luck or the first sign of a pattern and you cannot yet tell which. Two or more failures in fifteen means stop sampling. The extraction is not trustworthy at row level, so either check the whole thing by hand or discard it and rerun with a tighter prompt and smaller chunks. Do not deliver a file where you found two wrong rows and fixed exactly those two. You did not fix the file. You fixed the two you happened to see.

Record the check in the note

Write down what you did, in the delivery note, in one or two lines. Grounded extraction from the supplied document, every row carries a page and a quote, I verified fifteen of eighty-eight rows chosen from the middle and the end plus all currency rows, and all fifteen matched. That note does three things. It tells the operator reviewing your work exactly where the risk sits and where it does not. It protects you if an error turns up later in a row you did not sample, because you stated your method honestly instead of implying you had read everything. And it makes you actually run the check, because writing a false sentence is much harder than skipping a silent one.

Remember

  • Under 30 rows, check them all. Above 200, check 20 to 25.
  • The first ten rows are the sample an error hides from.
  • Zero in fifteen, proceed. One, check fifteen more. Two, stop.
  • Fixing the two rows you found does not fix the file.
  • State your sample in the delivery note. It protects the operator and you.

Long documents and honest chunking

~9 min

The middle goes soft

When you hand over a very long document in one piece, the quality of the reading is not even across it. The beginning and the end are handled well. The middle is where facts thin out, where a section quietly gets skipped, and where the model starts describing what a document of this kind usually says. You can watch this happen. Ask for findings from a 90-page report and count how many come from pages 30 to 60. If the answer is two, you did not get an extraction of the middle, you got an extraction of the edges. Do not fight this with a sterner instruction. Fight it by making each piece of material small enough that there is no soft middle.

Cut on the document's own seams

Chunk where the document already divides itself. A chapter, a numbered section, one vendor's block, one month of transactions, one meeting inside a transcript. Cutting at an arbitrary word count is what splits a table from its header row, or a clause from the definition three lines above that gives it meaning, and the model will then answer confidently from the half it can see. Keep each chunk to something you could read yourself in a couple of minutes. Repeat the same instruction, the same question list and the same output columns for every chunk without editing them in between, because a prompt you improved halfway through produces two incompatible halves of one deliverable.

Never summarise a summary

The tempting shortcut with twelve chunks is to summarise each one, then summarise the twelve summaries into a final answer. Do not. Each pass strips the specific and keeps the general, because that is what compression does, and the specific is exactly what the client is paying for. The invoice number survives one pass and dies in the second. The one sentence where the supplier admits the delay was theirs becomes performance issues were discussed. What you deliver then reads well and contains nothing anyone can act on. Extract from each chunk directly into the same final table, locators intact, and let the table run long. A long table with real detail beats a tidy paragraph every time.

Carry the address through every chunk

Chunking breaks locators unless you repair them yourself. If you supply pages 40 to 55 as chunk six, the model will number them from one and hand you page 3, which points at nothing in the client's file. Tell it the real range in the prompt: this is pages 40 to 55 of the source, cite the true page number. Then label the chunk in your working file so you can trace any row back to it. When you paste rows from twelve chunks into one sheet, keep a column recording which chunk each row came from. That column costs nothing and saves the hour you would otherwise spend hunting for one row's origin when the operator asks about it.

Check the seams and the totals

Two things go wrong at assembly. Duplicates, because an item near a boundary appears in two chunks, sometimes worded differently enough that you do not notice. And gaps, because one chunk was pasted twice and another never ran at all. So run two mechanical checks before you deliver. Sort the assembled table by locator and look for the same fact appearing under two different page numbers. Then confirm that every chunk you planned actually contributed rows, and that the pages covered run continuously from the first to the last with nothing missing between them. This takes four minutes on a 200-row file. A missing chunk is the failure most likely to reach QC, because everything that is present looks fine.

Remember

  • Long inputs go soft in the middle. Small chunks have no middle.
  • Cut on the document's own seams, never on a word count.
  • A summary of a summary keeps the general and kills the specific.
  • Tell each chunk its true page range, or the locators point nowhere.
  • Check for duplicate rows at boundaries and for chunks that never ran.

When grounding does not save you

~8 min

Faithful to a wrong source

Grounding guarantees one thing only: that the answer matches the material you supplied. It says nothing about whether the material is right. If the client's price list carries a typo and shows a product at 1,290 pesos instead of 12,900, a perfectly grounded extraction will carry that typo through with a locator and a verbatim quote, and every check you run will pass. Your spot-check confirms the quote, not the world. So keep a second question running quietly while you work: does this number make sense beside the others. A price ten times below its neighbours, a date before the company existed, a total that does not match its parts. Grounding protects you against invention, not against error.

Old and true is still wrong

A document can be accurate and useless at the same time. A rate card from 2022, a staff list from before two people left, a policy superseded by a memo you were never given. The model has no way to know any of this, and it will answer from what it holds with complete confidence, because inside the supplied text the fact is true. Your defence is to check the date on every source before you use it, and to look for a version number or a revision line. When you cannot establish how current something is, say so in the delivery note: the source document carries no date, figures are as stated in it. That is one sentence, and it moves a real risk from hidden to visible.

When the source fights itself

Long documents contradict themselves regularly. Page 4 says invoices are due in 30 days, appendix B says 45, and both are inside the file you were given. Ask a model for the payment term and it will hand you one of them, usually the one it met first, and the contradiction disappears without a trace. Guard against this by asking in a form that surfaces conflict: list every place the source states a payment term, with page and quote, even where they agree. Now you get two rows instead of one, and the problem is visible. Then do not resolve it. Choosing between them is a decision about the client's own business, and you have no way to know which version governs.

Scans corrupt before reasoning starts

Some material is unreliable before anyone reasons about it at all. A scanned invoice where an 8 reads as a 3. A table inside a document that flattens when copied, so the value from column four lands under column two. A screenshot pasted as text. A transcript where automatic captions guessed at a name. Grounding cannot help here, because the corrupted version has become the source, and the extraction will be faithful to the corruption. Check these against the original image with your own eyes, not against the text you pasted, and check the awkward cases specifically: currency columns, anything with a leading zero, names, and rows near a page break. If you cannot read it reliably, say so rather than transcribing your best guess.

Flag it, keep your hands off

When the material is wrong, stale or self-contradictory, your job is to report it precisely and stop. Not to correct it from general knowledge, not to pick the version that seems more sensible, and not to leave it out because it complicates an otherwise clean deliverable. Write it into the note: page 4 states 30 days, appendix B states 45, both quoted in rows 12 and 13, and I have not chosen between them. The operator reviews your delivery against a written standard before the client sees it, and a flagged contradiction is something they can settle in one message. A silently resolved one becomes a wrong number inside a client's system, found in a month, traced back to your delivery.

Remember

  • Grounding proves the answer matches the source. It does not prove the source.
  • Check the date and version of every document before you work from it.
  • Ask where a fact is stated, plural. Contradictions only appear when you look.
  • Scans and copied tables corrupt before reasoning starts. Check against the image.
  • Report the conflict. Choosing between two client versions is not your call.

Sit the exam

The courses are free. The work is real.

Twelve scenario questions. Pass at ten. Three attempts a day. The bar is the point.

No paid tier. No certificate fee. No upsell. Not now, not later.

Create a free account

You can start the first course tonight.

The curriculum

Everything, and what is in it.