Get Started
Chapter 310 min read

Working With Your Own Material

How to get grounded, checkable answers from your own documents — and why this is where generative AI is genuinely most reliable.

There is a large difference in reliability between asking a model what it knows and asking it about material you have given it. The first is a memory test with no guarantee of accuracy. The second is a comprehension task, which these systems are much better at.

If you take one practical habit from this course, make it this one: give it the source.

Why grounded questions work better

When the answer is present in the text you supplied, the model does not have to construct anything — it has to locate and restate. That is a far easier job with a far lower failure rate.

It also makes verification cheap. If you asked about a document you have, you can check the answer against the document in seconds. When you ask about the world in general, checking means going and finding a source.

Ask it to cite where it found things

Requesting the location — the page, the section, the exact sentence — changes the behaviour of the answer. It becomes traceable, and you catch invented details immediately because there is nothing to point at.

A grounded document prompt

I am attaching a document. Answer only from it.

For each answer:
1. The answer
2. The exact sentence it came from, quoted
3. The section or page

If the document does not contain the answer, say "not stated in this document" rather than using general knowledge.

My questions:
- [question one]
- [question two]

The 'not stated' instruction

This one line does a lot of work. Without it, a model asked a question the document does not answer will often answer anyway, from general knowledge, and the shift is invisible to you.

With it, the boundary between what your document says and what the model assumes becomes explicit — which is exactly the boundary that matters when the document is a contract or a policy.

Separating sourced from unsourced

For research work, structure the whole output around this split: claims you can support from the supplied sources, and everything else quarantined in its own section.

The second section is not useless — it is often where the useful leads are. But it must never be mixed into the first, because a reader cannot tell them apart afterwards.

Long documents and the context window

Chapter one covered the context window; here is where it bites. A very long document may not fit, and what does not fit does not exist for the model.

Practical approach: work section by section rather than uploading everything and hoping. Ask about chapter three by giving it chapter three. Where a tool advertises a very large context, test it on a document you know well before trusting it on one you do not.

The one thing it still cannot do

Judging what matters. A model can tell you what a contract says about termination; it cannot tell you whether that clause is acceptable for your business. It can summarize a research paper; it cannot tell you whether the study design is strong enough to act on.

Comprehension it can do. Consequence is yours.

What to take from this chapter

  • Asking about supplied material is far more reliable than asking about general knowledge
  • Request quoted sources and locations so answers are traceable
  • Add an explicit 'say not stated' instruction to stop silent fallback to general knowledge
  • Keep sourced and unsourced claims in separate sections, always

Try it

Take a document you know thoroughly. Ask five questions about it using the grounded prompt above, including one the document does not answer. Check whether the model correctly says 'not stated' — and note what it does if you remove that instruction.