Your AI Cited Source Code. Can You Prove Which Source?

Your coding agent just handed you a fix and backed it up with a quote: "based on the
implementation of the retry logic in your HTTP client library." It even pasted the
function. The fix looks right. Then a reviewer leaves one comment on your pull request:

Which version of the library is that from?

And there it is. The citation names a project, but not a version. Not a tag, not a
commit, not an artifact. The function might be from the release you have pinned, from
main at a different point in time, or from a fork with the same file name. The
citation alone does not tell you which.

This isn't a story about careless review. A citation and provenance are two different
things, and the distinction matters whenever version-specific behavior affects a
change. That is why this series starts here, alongside the site's other
field notes.

A citation is a claim. Provenance is evidence.

When an agent says "this comes from library X," that's a report. Useful, often correct —
and unverifiable on its own. Provenance is what turns the report into something a
reviewer can check: an exact version, a specific artifact, a checksum that either
matches or doesn't, a commit hash you can visit.

Reports come from the worker. Verdicts come from a judge.

The agent is the worker here. The judge is any verification step that someone else can
rerun and get the same answer. If your review process accepts the report without a way
to reach a verdict, the question isn't whether a mismatch will slip through — it's
whether you'll notice when it does.

Five questions that establish provenance

You don't need any particular tool for this. For a dependency your AI cited, can you
answer these five questions with links?

1. Does the version resolve to exactly one release? "The requests library" is not
   an answer; a specific resolved version is. Range specifiers need to collapse to the
   one version your lockfile actually pins.
2. Are you looking at the registry artifact or a repo snapshot? The package
   published to a registry and the repository at a matching tag are different evidence
   surfaces. Which one does your build consume, and which one did the citation use?
3. Does a published checksum verify — and what happens when it doesn't? A check
   that warns and continues is a formality. A check that fails closed, refusing to
   proceed on mismatch, is a control.
4. If the code comes from git, is the commit pinned and are the file contents
   verified? Can you point to the commit hash and check the individual blobs against
   the host's tree data?
5. Is there a record you can attach to the review? Provenance that lives in your
   terminal history helps nobody next week. A manifest — even a pasted one — makes the
   verdict portable.

If you can answer all five, the reviewer's "which version?" has an evidence-backed
answer instead of another assertion.

Worked example: what the primary records show

Disclosure first: Leitir is maintained by Anthony Garces, who publishes ranex.dev.
It appears here as a transparent first-party example of the checklist above — a
methodology walkthrough, not a ranking win or an independent endorsement.

Checked on 2026-08-31 (Asia/Manila) against the project's primary sources — the
Leitir README,
latest-release endpoint,
tags,
project metadata,
and LICENSE:

• Leitir describes itself as a deterministic, provenance-bound dependency-source corpus
  plus a deterministic code-search kernel for AI coding agents.
• Its README documents exact-version resolution, bounded registry source-artifact
  fetching, fail-closed published-checksum verification, pinned git commit trees, blob
  checks, and provenance manifests — the same five questions above, mechanized. I did
  not run those paths for this article.
• Its README lists support for GitHub, GitLab, Bitbucket, Codeberg, Sourcehut, npm,
  PyPI, crates.io, and Go sources.
• The README documents leitir info <spec> as one JSON response containing provenance,
  an API summary, examples, trust, and parity.
• GitHub's latest-release endpoint returned v0.1.6, published 2026-08-25. The tags
  listing maps v0.1.6 to commit
  91e93e16466405bb95fcfb762e9319a5f716de09; that observation does not guarantee the
  tag can never move.
• The README says distribution is through GitHub releases and tags rather than PyPI.
  Current-main pyproject.toml sets version 0.1.6 and dependencies = []; that does
  not prove anything about optional extras or the contents of the release artifacts.
• The checked LICENSE file contains MIT License text. GitHub's
  repository metadata reports
  NOASSERTION, so this article does not claim GitHub classifies the repository as
  MIT or that the checked license text covers every file.

Now the scope of all that, stated exactly: the verification methods described above
are designed to establish origin binding only. When you run them successfully,
they can show that specific bytes match a specific published artifact or commit. They
do not prove software quality, security, correctness, suitability for your project,
or the identity of the publisher. A perfectly provenanced dependency can still be a
bad choice. Verification narrows what you have to trust; it doesn't remove trust from
the picture.

That's also why the series will use careful wording from here on: a citation either
has "A scoped Leitir record is linked" or "No Leitir record is linked." Absence
never means failed verification. It means unverified — a neutral state, and an honest
one.

What could you verify this week?

Could you pick one dependency your AI assistant cited recently and run the five
questions on it by hand? Can you resolve the exact version, find the registry artifact,
and verify one checksum? Where does the trail go cold? That cold spot is your
workflow's actual provenance gap, and it is worth knowing before a reviewer finds it.

Caveats worth carrying with you: facts above were verified on 2026-08-31. The README
behavior was not runtime-tested, and release assets were not independently hashed.
If publication happens later, human review must recheck the version, release, activity,
and license facts that morning. Follow the primary links rather than trusting this
snapshot. Treat the method as the takeaway, and evaluate any tool against your own
constraints.

Research and drafting were AI-assisted. Human review is required before publication.
Primary sources are linked so you can check the claims yourself.

FAQ

Does a checksum match prove the code is safe?

No. A verified checksum proves the bytes you examined match a published artifact —
origin binding, nothing more. It does not prove quality, security, correctness,
suitability for your use, or who the publisher really is. Those need separate review.

What does "No Leitir record is linked" mean?

Only that no scoped provenance record accompanies the citation, so origin has to be
established another way. Absence never means failed verification — it means unverified,
which is a different and honest state.

Can I check AI source code provenance without any tool?

Yes. Resolve the exact version, download the registry artifact, verify its published
checksum, or pin the git commit and compare. It is manual and slow, but every step uses
primary sources you can link in a review.

Why disclose that Leitir is a first-party project?

Because the example only has value if you can weigh the interest behind it. Leitir is
maintained by the author of this site, so this article is a transparent methodology
walkthrough, not an independent ranking or endorsement.