# Capturing evidence for a prospect, end to end

Evidence capture is the step that decides what a prospect record is allowed to say. A source is read, a statement is extracted, the statement and its source are stored together by `prospect_evidence`, and only then may a claim appear on the record. A statement that arrives without a source is discarded at this point rather than kept with a caveat.

- **Status:** Available
- **Audience:** both
- **In the app:** #/prospects
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/prospect-evidence-capture/

## One fact, end to end

1. Trigger — a research pass on one prospect reaches a source worth reading.
2. External event — the source is fetched; it is public material about a business, not anything the business sent you.
3. Authentication and workspace resolution — the prospect already belongs to a workspace, and the evidence inherits it and its row-level security.
4. Ingest — the fetched material is read; what is kept is the statement, not the whole page.
5. Canonical record — the evidence row is written with the statement, the source it came from, and the moment it was captured.
6. Reasoning — the statement is matched to the claim it would support, and the claim's contribution to the fit reason is assessed.
7. Knowledge, memory and rules — the workspace's own knowledge decides whether this claim matters here; a fact that changes nothing for your brief is not worth storing.
8. Autonomy and approval — no approval is involved; capture writes to a record and sends nothing to anybody.
9. Action through a provider — reading and extraction are model work, booked to the workspace's usage like every other call.
10. Result — a claim appears on the prospect with its evidence attached, or nothing appears at all.
11. Relationship and timeline — evidence stays on the prospect and is linked from anything the prospect becomes; it is never copied onto a second record.
12. Audit and usage — the capture is part of the research run's record, so a claim's age and origin are both answerable later.

## What is stored, and what is not

**The statement** — Kept, in a form that can be read back and understood without the original page.
**Its source** — Kept alongside it. A claim and its evidence move together, always — replacing one without the other is not offered.
**When it was captured** — Kept. This is what freshness measures; without it, ageing would be guesswork.
**The whole page** — Not kept. Storing a copy of somebody's site would create a second thing to age, and a second thing to be wrong.
**An unsourced impression** — Not kept. This is the rule, not a preference: `prospect_evidence` refuses the claim rather than annotating it.

> **Note** The refusal is what makes the record defensible. A prospect list where some claims are proved and others are impressions is worse than one with fewer claims, because a reader cannot tell the two apart and will eventually repeat the wrong one to a stranger.

## The three ways capture ends with nothing

1. The source says nothing relevant. Most pages about a business do not answer the question a brief is asking, and reading one that does not is a normal cost of research.
2. The statement cannot be tied to a source with confidence. An inference assembled from two half-facts is not evidence, and it is dropped.
3. The claim would change nothing. A fact that neither supports nor undermines the fit is not stored simply because it was found.

None of those is an error state and none is reported as one. A research pass that read several sources and captured two claims has done its job; a pass that captured twelve claims about an organisation with a large public footprint has done the same job.

## Reading evidence months later

1. Open the claim and follow its evidence.
   - Result: You see what was read and when. If the source has changed since, that is a freshness question rather than a fault in the capture.
2. Check the capture date against the claim's class.
   - Result: Named people and recent activity age fastest; registration facts effectively do not.
3. Where it matters, re-research rather than re-reading manually.
   - Result: A re-check replaces the claim and its source together, so the record never holds a new assertion pointing at an old page.

> **Careful** Evidence captured from a source that later disappears does not make the claim untrue, but it does make it unverifiable. A re-check that cannot find the statement again removes the claim, which is the correct outcome even when it is the inconvenient one.

## Questions

### Can I add evidence myself?

You can add your own note, attributed to you. It is not promoted into an evidence-backed claim, because the value of the distinction lies precisely in its not being editable from either side.

### Why does a prospect I know a lot about have so few claims?

What you know and what a public source states are different sets. The record holds the second, which is smaller and is the part you can repeat to somebody outside your business.

### Is the evidence visible to the prospect?

No. It is workspace data under the same isolation as everything else. What reaches the prospect is the message, and the message is grounded in these claims rather than reciting them.

## Related

- [Evidence on a prospect](https://connectbyjbrh.com/docs/prospects/evidence/)
- [Researching a candidate](https://connectbyjbrh.com/docs/prospects/public-source-research/)
- [Keeping prospect research fresh](https://connectbyjbrh.com/docs/prospects/prospect-freshness/)
- [Evidence-first prospecting without guessed emails](https://connectbyjbrh.com/research/evidence-first-prospecting/)
- [Researching one prospect, end to end](https://connectbyjbrh.com/docs/workflows/prospect-research/)
- [Why this prospect](https://connectbyjbrh.com/docs/prospects/fit-reason/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §4 — the evidence rule
- `backend/app/prospect_evidence.py`, `backend/app/prospect_freshness.py`
- Connect capability registry (`docs-source/facts.py`)