Ask questions about your own files

This mini-book is for Level 1 User. You are asking questions over files for your own work, using a bounded document set and checking every cited claim yourself before you reuse it.

2. Forty files, twenty minutes

You have forty documents and twenty minutes before a meeting. Somewhere in them, two sources disagree about an important condition. Opening files one by one may consume the whole window, so you upload a permitted set to a document-question tool and ask for the conflict.

The answer is immediate and polished. It includes citations. That looks finished, but one citation points only to a page where the topic is mentioned, not where the claimed condition appears. The other source states the condition clearly. If you repeat the answer without opening both documents, the citation decoration has hidden a weak claim rather than supported it.

The useful workflow is not simply upload and ask. It is choose a safe boundary, ask a question the collection could answer, follow every citation into the original file, and keep only claims that the located text supports.

3. After this you can

• Get answers with citations from a small collection of your own documents.
• Locate each citation in its original source and decide whether it supports the claim.
• Recognise when the documents do not contain an answer.
• Explain whether an upload remains on an approved local system or is processed by a cloud service.

4. Prerequisites

• T01-L02 - Trust but verify, for checking names, numbers, claims, and source quality.
• T12-L01 - What you must never paste into AI, for deciding whether a file may be uploaded.
• One approved tool that can search a document collection and expose a source title, page, section, passage, or equivalent pointer.
• A local note in which to record questions, answers, citations, and verification results.

For the exercises, use the synthetic text on this page or public material. Do not upload personal data, confidential supplier terms, unpublished research, credentials, customer records, or production exports to a consumer service. If you cannot explain where the files and derived indexes go, use the supplied text offline and stop before a real upload.

5. The idea in one page

A document-question tool usually performs two jobs. First, it prepares the files for search, often by dividing them into smaller passages and creating a searchable index. Second, when you ask a question, it retrieves passages that seem relevant and gives them to a language model to compose an answer. This is often called retrieval-augmented generation, or RAG.

That sequence changes how you review the result. A wrong answer can begin when search retrieves the wrong passage, or when the model overstates a useful passage. You do not need to diagnose or tune those components at Level 1. You do need to open the original and check the evidence.

"With citations" normally guarantees only that the interface presents a pointer. It does not guarantee that the pointer opens, identifies the right version, contains the claimed words, supports the whole sentence, or comes from an authoritative source. Verify a cited claim with five moves:

1. Open the cited original, not merely the generated answer or a search snippet.
2. Locate the page, heading, paragraph, table row, or exact quoted words.
3. Compare every factual part of the answer with that passage.
4. Check the document title, date, and version when they affect meaning.
5. Mark the claim supported, unsupported, or not found.

Ask narrow questions. "What do these documents say?" invites a broad synthesis that is slow to verify. "Which sources state different delivery windows, and what exact wording does each use?" defines a visible search target. Also specify the fallback: if the collection does not answer, return Not found in the selected documents. A fallback does not force honesty, so you still inspect the result.

Keep the collection small enough to understand. A folder for one topic, project, or decision is easier to check than every file you possess. More documents can introduce duplicate versions, unrelated language, and noisy retrieval.

Finally, distinguish local-only from cloud processing. "Installed on my laptop" does not prove local-only operation. The application may send document text or retrieved passages to a hosted model, embedding provider, storage service, telemetry endpoint, or backup. Before a real upload, identify the application host, language-model provider, embedding provider, index location, logs, retention, deletion path, and who can access the workspace. Use the current product documentation and ask the deployment owner. If any part is unknown, treat the path as unknown rather than local.

6. The worked example: find a conflict, then open the sources

Both framings use exactly twenty synthetic documents, the same prompt, and the same verification method. The filenames make the original sources easy to open. Seventeen documents in each set discuss the topic but do not state the tested condition; the three relevant excerpts are reproduced below.

Use this prompt in an approved document-question tool, or simulate the retrieval by searching the text on this page:

Use only the selected twenty documents.

Question: Which documents disagree about the stated condition? Report each position
in one sentence. For every sentence, cite the filename and quote the exact supporting
words. If no selected document answers a part, write: Not found in the selected documents.

Do not reconcile the conflict or recommend a choice.

For each result, ignore the answer's fluency. Open the named file, locate the quoted words, and decide whether they support the complete sentence.

Lab framing: twenty papers on one topic

Mira creates a collection containing twenty synthetic papers about the fictional Northstar assay. The files are NS-P01.txt through NS-P20.txt. Papers 01-07 discuss materials, 08-13 discuss calibration, 14-17 discuss analysis, and 18-20 contain these storage statements:

NS-P18.txt, Results, paragraph 2
Northstar reagent retained the target signal after storage at 4 C for 48 hours.

NS-P19.txt, Methods, paragraph 4
All Northstar reagent was stored at -20 C and thawed once immediately before use.

NS-P20.txt, Discussion, paragraph 1
This study did not compare storage temperatures or storage duration.

She confirms that the source list contains exactly NS-P01.txt to NS-P20.txt, with no sample or previous files. She then asks the shared prompt.

An illustrative answer says:

NS-P18 reports successful storage at 4 C for 48 hours (NS-P18.txt: "retained
the target signal after storage at 4 C for 48 hours").

NS-P19 requires storage at -20 C (NS-P19.txt: "stored at -20 C and thawed once
immediately before use").

NS-P20 recommends testing both temperatures (NS-P20.txt: "did not compare storage
temperatures or storage duration").

Mira opens all three files. The first sentence is supported: the claim and quote match. She marks the second unsupported because the paper reports what its researchers did, not a requirement for everyone. She marks the third unsupported because "did not compare" is a limitation, not a recommendation. The citations were real pointers, but two generated conclusions exceeded their source passages.

Her verified answer is narrower:

The papers use different stated storage conditions. NS-P18 reports retained target
signal after 4 C storage for 48 hours [NS-P18.txt, Results, paragraph 2]. NS-P19
reports storage at -20 C followed by one thaw before use [NS-P19.txt, Methods,
paragraph 4]. Neither excerpt establishes a universal requirement. NS-P20 reports
that its study did not compare storage temperature or duration [NS-P20.txt,
Discussion, paragraph 1].

She has found the disagreement between the two reported practices without inventing which one is correct. Deciding the appropriate protocol would require an approved authority and belongs outside this personal retrieval exercise.

Company framing: twenty supplier documents

Jonas creates a parallel collection containing twenty synthetic documents for fictional Harbor Components. The files are HC-S01.txt through HC-S20.txt. Files 01-07 describe products, 08-13 describe quality checks, 14-17 describe contacts, and 18-20 contain these delivery terms:

HC-S18.txt, Delivery, clause 2
Standard orders must be dispatched within 5 business days after written acceptance.

HC-S19.txt, Schedule, clause 3
Standard orders must not be dispatched before 10 business days have elapsed after written acceptance.

HC-S20.txt, Scope, clause 1
This information sheet does not set dispatch times or cancellation terms.

He confirms that the source list contains exactly HC-S01.txt to HC-S20.txt, with no other documents, and asks the same prompt.

An illustrative answer says:

HC-S18 guarantees delivery within 5 business days (HC-S18.txt: "must be dispatched
within 5 business days after written acceptance").

HC-S19 requires waiting at least 10 business days before dispatch (HC-S19.txt: "must
not be dispatched before 10 business days have elapsed after written acceptance").

HC-S20 allows cancellation before dispatch (HC-S20.txt: "does not set dispatch
times or cancellation terms").

Jonas opens all three files. He marks the first unsupported: dispatch is not delivery to the customer, so the quote does not guarantee arrival. The second is supported: its requirement and timing match the located clause. The third is unsupported; an absent cancellation term is not permission to cancel.

His verified answer is:

The supplier documents state incompatible dispatch requirements after written
acceptance. HC-S18 requires standard orders to be dispatched within 5 business days
[HC-S18.txt, Delivery, clause 2]. HC-S19 prohibits dispatch before 10 business days
have elapsed [HC-S19.txt, Schedule, clause 3]. For the same standard order and
acceptance date, both requirements cannot be followed. HC-S20 sets neither a dispatch
time nor a cancellation term [HC-S20.txt, Scope, clause 1]. The excerpts do not show
which document is current or governing, so resolving the conflict requires checking
the originals' dates, versions, and authority rather than choosing the preferred term.

The two variants follow the same path: twenty bounded files, one conflict question, exact quotes, original-file checks, and a narrower final answer. Neither person forwards the result as a decision. The Lab result does not choose a storage protocol, and the Company result does not resolve which supplier document governs.

7. What goes wrong

A citation is trusted without being opened

Symptom: the source title looks relevant, so you accept the sentence without locating its evidence.

Fix: open the original and record the page, heading, paragraph, clause, table row, or exact words that support every factual part.

Red-tier material goes into a consumer tool

Symptom: confidential, personal, regulated, security-sensitive, or unpublished files are uploaded because document chat feels like private reading.

Fix: classify the material first using T12-L01. Use only approved systems and permitted data; use synthetic text when the processing path is uncertain.

The collection cannot answer, but the model does

Symptom: the answer supplies a plausible number, policy, result, or recommendation absent from all selected files.

Fix: require the not-found response, test it with a deliberately absent question, and verify that any retained answer exists in the originals.

One giant collection returns noise

Symptom: citations come from unrelated projects, duplicated versions, or files that merely share vocabulary.

Fix: create a fresh, purpose-specific collection and inspect its source list before asking.

Reported practice becomes a requirement

Symptom: "we stored at -20 C" becomes "you must store at -20 C," or a dispatch statement becomes an arrival guarantee.

Fix: preserve the source's verb, scope, and qualifiers. Do not convert description into instruction, permission, or promise.

"Local" is inferred from the interface

Symptom: a desktop or self-hosted screen is treated as proof that no provider receives document text.

Fix: trace the application, model, embedding, storage, logging, backup, access, retention, and deletion path with current documentation and the deployment owner.

8. Do it yourself: three verified answers in 30 minutes

Minutes 0-5: choose one small collection of public, synthetic, or explicitly approved files. Keep it to one topic and record the exact filenames. Confirm the selected tool exposes citations you can open. Record whether its application, model, embedding, index, and logs are local, cloud, or unknown. If the path is unknown, use only synthetic files.

Minutes 5-9: create a fresh collection and add only those files. Inspect the source list for old, sample, duplicate, or unrelated documents. Remove them before asking anything.

Minutes 9-14: write three narrow questions the selected files should answer. Require a filename, exact quote, and not-found response. Make one question test a disagreement, version difference, condition, exception, or missing fact.

Minutes 14-22: ask all three questions. Save the answers exactly as returned. Open every citation in the original file and locate the supporting words. Do not count a citation preview as the original.

Minutes 22-27: mark each cited claim supported, unsupported, or not found. Rewrite or remove unsupported wording. Preserve distinctions such as dispatch versus delivery, observed versus required, and absent versus allowed.

Minutes 27-30: complete one record with this structure and check that another reader could repeat every source lookup:

9. Exit check

Deliver exactly one artifact: one completed record containing three answers, with every citation located in the original source document.

It passes when all three questions are present; every factual claim is supported by exact located words or marked unsupported or not found; the original filename and location are sufficient for another person to repeat the check; and the record states whether the upload path was local, cloud, or unknown. It fails if a citation is accepted from its title or preview alone.

10. Rule to remember

A citation is a pointer, not a proof.

11. Further reading & tools

• Taught: T01-L02 - Trust but verify - applies the source-checking habit to each retrieved claim.
• Taught: T12-L01 - What you must never paste into AI - determines whether a document may cross the selected processing boundary.
• Taught: Chat with your own documents - demonstrates bounded retrieval, one supported question, one absent answer, and citation review.
• Taught: Open Notebook - demonstrates selected notebook context and reviewed notes over sources.
• Taught: AnythingLLM - demonstrates a bounded workspace and asks you to record its model, embedding, storage, and access path.
• Catalogued: Open Notebook repository (opens in a new tab) - current project and deployment documentation; self-hosting still requires a data-path review.
• Catalogued: AnythingLLM documentation (opens in a new tab) - current product documentation for retrieval, privacy, deployment, and access settings.
• Taught: Anthropic file uploads (opens in a new tab) - provider guidance for current file handling in Claude; confirm organisational approval and account terms before use.
• Catalogued: OWASP prompt injection guidance (opens in a new tab) - explains why instructions found inside retrieved documents must be treated as untrusted content.
• Catalogued: Tools index - current product references; verify capabilities, approval, and data controls before choosing one.