Claude Project Using the Wrong Source? Build a Claim Check Before You Draft

Claude Projects are useful when the same background material comes up again and again. They also make a common mistake harder to spot: Claude can produce a polished brief while using the wrong document, missing a file, or filling a gap from general knowledge.

This guide gives you a small check to run before you ask for the final draft. You will create a claim map from fictional project material, then decide whether the source set is ready.

Intermediate lesson. Evidence label: documentation-based guide with fictional inputs and illustrative output. This workflow was not executed here. The sample files and output are editorial examples, not a Claude result.

What you need

A Claude account with access to Projects. Anthropic’s Projects guide says Projects provide a workspace with chat history, a knowledge base, uploaded files, and project instructions. Availability and the current project experience can change.
One project containing only approved, non-sensitive sample files.
A final artifact you can check against the source, such as a project status brief or supplier summary.

Do not start with confidential contracts, customer records, or a project that can send messages or change files. Use fictional material until the check is familiar.

The fictional source pack

Create these two plain-text files and upload both to a new project.

launch-notes.txt

Project: Northstar onboarding refresh
Review date: 2026-10-06
Owner: Mira Demir
Confirmed status: The new welcome email is approved. The help-center article is in review.
Open question: The training video owner is not assigned.
Next review: 2026-10-10

old-launch-notes.txt

Project: Northstar onboarding refresh
Review date: 2026-09-29
Owner: Mira Demir
Confirmed status: The welcome email is in review.
Open question: The help-center article needs a reviewer. The training video owner is not assigned.
Next review: 2026-10-03

The newer file says the welcome email is approved. The older file says it is still in review. That conflict is deliberate. A good check should expose it instead of choosing the sentence that sounds most complete.

1. Set the project boundary

Create a project and add the two sample files to its knowledge base. In the project instructions, paste this short rule:

Use only the files in this project for project facts.
When files conflict, show both statements and use the review date to describe which is newer.
Never turn an open question into a completed task.
If a claim has no supporting source, label it UNKNOWN.
Do not send messages, edit files, or make commitments.

Project instructions are not a replacement for source review. They tell Claude how to handle the material, while the files provide the material itself.

2. Run the claim-map check first

Open a new chat inside the project. Paste this prompt:

You are checking source coverage before a workplace brief is drafted.

Use only the two files in this project: launch-notes.txt and old-launch-notes.txt.
Create a table with these columns:
1. Proposed claim
2. Supporting file and exact line or field
3. Status: supported, conflicting, or UNKNOWN
4. What a human must confirm

Check these proposed claims:
- The welcome email is approved.
- The help-center article is approved.
- Mira Demir owns the project.
- The training video has an owner.
- The next review is on 2026-10-10.

Rules:
- Quote only text that appears in the files.
- Treat the file review date as evidence about which statement is newer, not as proof that the older statement was false when written.
- Do not draft the final brief.
- Do not infer an owner, approval, deadline, or completion.

The output you want is a claim map, not a confident paragraph. An illustrative result could look like this:

Proposed claim	Supporting source	Status	Human check
Welcome email is approved	`launch-notes.txt`, Confirmed status	supported by newer file; conflict found	Confirm the approval still stands
Help-center article is approved	Neither file	UNKNOWN	Ask the reviewer
Mira Demir owns the project	Both files, Owner	supported	Confirm owner is current
Training video has an owner	Neither file; both say unassigned	conflicting with claim	Assign an owner before stating one
Next review is 2026-10-10	`launch-notes.txt`, Next review	supported by newer file	Confirm the meeting remains scheduled

This table is an illustrative expected output. It was not generated by Claude in this article.

3. Fix the source problem, not the prose

Use the table to choose one of three actions:

Supported: keep the claim, but retain its source reference.
Conflicting: show the conflict and ask a named human to resolve it. Do not silently merge the two versions.
UNKNOWN: leave the claim out of the brief or include it in an open-questions section.

For the sample pack, the help-center article should remain unapproved, the training video should remain unassigned, and the older welcome-email status should stay visible as historical context.

If the table names the wrong file, upload a corrected version or remove the duplicate after checking that no needed information will be lost. If it invents a fact that appears in neither file, tighten the project instruction and rerun the check.

4. Draft the brief only after the check passes

Once a human has reviewed the claim map, use this second prompt:

Using the approved claim map and the two project files, draft a short Northstar onboarding status brief.

Include:
- confirmed work
- unresolved conflicts
- open questions
- the next review date

For every factual sentence, add the source filename in parentheses.
Keep the welcome email approval qualified as current according to the newer file.
Do not call the help-center article approved.
Do not assign an owner to the training video.
Do not add recommendations, deadlines, or commitments that are not in the files.
End with a human review checklist containing no more than four items.

The acceptance artifact is the final brief plus its source references. A reader should be able to trace every factual sentence back to one of the two files.

Acceptance checks

Before sharing the brief, check it against the source pack:

It says the welcome email is approved only with the newer file’s date or an equivalent qualification.
It does not say that the help-center article is approved.
It keeps the training video owner as unassigned.
It does not turn the next review date into a completed meeting.
Every project fact names a source file.
Unknowns and conflicts appear in a review section.

If one check fails, return to the claim map. Asking for a more polished rewrite will not repair missing or conflicting source material.

Troubleshooting

Claude cites a file that is not in the project: stop and check the project knowledge list. Do not assume a file from another chat is available here.
Claude chooses the newest sentence without showing the conflict: rerun the first prompt and require both statements, their review dates, and a human check.
Claude writes a plausible owner or deadline: mark the claim UNKNOWN and add the exact instruction against inventing owners, dates, or commitments.
The project interface looks different: Anthropic is rolling out changes to Projects in stages. Follow the current help article for the surface you actually use instead of relying on a screenshot or an old menu name.
The files contain sensitive material: stop and replace them with fictional or approved redacted inputs. This check is not a permission review.

Limits and safe use

A source map reduces one kind of error. It does not prove that a file is correct, current, or safe to share. A human still owns approval, access decisions, and consequential commitments. Project knowledge can also grow stale, so record the review date when the source matters.

TRY this with two short, conflicting sample files. SKIP it for confidential material until your data and access policy is clear. USE a Claude Project when the same approved context recurs and the source map saves review time without hiding uncertainty.

Sources and next step

For a broader workflow, read Use Claude Projects to prepare a client kickoff brief from approved notes. This guide adds a source check before the brief, rather than repeating the kickoff workflow.