If You Never Fetched It, You Never Researched It

TL;DR: A citation can look researched without proving anyone opened it. Fetch the source bytes, record them, and say what that check still cannot prove. The parent slice log explains why claims need evidence.

You have written a sentence, attached a source, and felt sure of it without opening the link. A model can do the same thing faster and with more confidence. Neither reaction turns recall into research.

In this note

• A citation is a shape you can fake
• Fetch the bytes, not just the link
• Use a research checklist you can enforce
• Say where the proof stops
• Open the source before you repeat the claim

A citation is a shape you can fake

A URL costs almost nothing to produce. A file with a recorded matching hash requires somebody to obtain bytes.

Ranex found this problem in its own architecture-decision process. The original research rule required one URL under a prior-art heading. A blog post satisfied it. A link to the Ranex repository satisfied it. A dead link satisfied it. The rule looked like research without requiring anyone to show that they had read an implementation.

ADR-003 records the corrected rule: a citation is a shape an agent can invent; a file with a matching hash is one it had to obtain. The purpose is not to measure whether a writer feels well read. It is to make a factual question answerable from files in the repository.

This is why polished citations deserve the same suspicion as polished summaries. The title can sound right. The URL can point at a respected project. Neither tells you whether the cited code says what the writer claims.

Fetch the bytes, not just the link

Fetched evidence turns “I saw this” into a file another reviewer can inspect without trusting the writer.

For Ranex decisions, each prior-art entry must name a pinned source-file citation, its license, its weakness, and a vendored copy recorded with the blob hash Git would report. The decision requires two distinct sources. The copies live with the decision record and are tracked by git, so a fresh clone contains what the record says it relied on.

The weakness requirement is doing real work. A source can be mature and still answer a different problem. Naming the weakness makes the reader ask where the borrowed design stops applying before it becomes a hidden assumption in a new system.

Two sources are not an excuse to collect tabs until the work stalls. ADR-003 calls them a floor on rigor, not a reading quota. The goal is independent implementation evidence, not bibliography theater.

Use a research checklist you can enforce

You can apply this discipline to a design doc, an incident note, or a prompt handed to an agent. The machinery can be simpler; the questions should stay sharp.

• Fetch, do not merely link. Save the actual source you rely on.
• Pin the version. Cite a commit or release path, not a branch that can move after review.
• Use independent sources. Do not count the same file twice under different links.
• Record the license. Copying source is a licensing act, not casual note-taking.
• Name the weakness. State what the source does not establish for your decision.
• Make absence block. A cited file that was never fetched is a named failure, not a blank checkbox.

Ranex tests these clauses against its documents. The record describes refusals for specifications cited instead of working code, moving branch links, duplicate sources, escaped evidence paths, untracked files, and more. Those checks are useful because they turn common shortcuts into visible failures.

Say where the proof stops

Fetching and hashing a file does not prove that the file came from the URL beside it. That is the limit you must keep in the sentence.

An offline repository check can verify the tracked bytes and their recorded hash. It cannot independently contact the cited host and establish provenance. ADR-003 explicitly records that an agent could vendor a file it wrote itself and give that file its true hash. Closing that gap requires a second, independent network fetch.

That admission does not make fetched evidence pointless. It tells you exactly what it catches: citing from memory or inventing a source without obtaining its bytes. It does not catch a determined writer who controls both the citation and the vendored file. A smaller true claim is stronger than a broad claim you cannot test.

FAQ: fetched research evidence

These answers distinguish a citation someone supplied from source bytes a reviewer can inspect.

What is the difference between a citation and fetched evidence?

A citation is a URL or title someone can type from memory. In Ranex, fetched evidence is a vendored source file with a recorded hash that the writer had to obtain.

Why does Ranex require two fetched sources for a decision?

ADR-003 requires two distinct pinned source files because one implementation shows only one author choice; two sources are a rigor floor, not a reading quota.

Does fetching a source prove where it came from?

No. Ranex says a fetched hash proves recorded bytes exist, not that they came from the cited URL; an independent network fetch would be needed for that claim.

What happens when no source is fetched?

Ranex refuses the citation as a named problem. Absence is blocking rather than a default pass or a skipped research entry.

Open the source before you repeat the claim

Before you reuse a citation, open the pinned source file. Read the implementation, the license, and the limitation. Save what you relied on so the next reviewer can do the same.

Ranex is pre-release, with a working verdict path and substantial surrounding work still unbuilt. This research rule is one documented control, not proof that every decision is right. It is a way to make invented authority more expensive.

Try it. Break it. Tell me what broke.

Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.