A developer writing on dev.to has published sourcey-tracker, a read-only command-line tool that watches the Sourcey open registry of startup credits, deals and "Agent Readiness" report cards. The author describes it as a single Python file of roughly 450 lines that uses only the standard library — no pip install, no virtualenv and no API key — and the companion GitHub repository carries the same description. Because the announcement comes from the tool's own author, the specifics below are his claims rather than independently verified facts.
The registry itself is the reason the tool exists. According to the repository, Sourcey publishes three datasets as plain JSON — a companies registry, startup-credit offers and an agent-readiness table with letter grades — and, as of October 2, 2026, reports 543 companies, 596 offers across 530 vendors and 25 readiness profiles. The author's post puts the companies count at 543 as of his last check and states that the live release on that date reported the digest sha256:8094c042 consistently across all three datasets.
That consistency is the mechanism the tool is built around. Each dataset snapshot is addressable and the current release carries a digest, which the author argues is what separates real change detection from "fetch and eyeball": you can prove the bytes changed rather than merely observe that a page looks different. The repository adds that every record carries a release_id, revision_digest and provenance, and that the catalog moves through a signed change feed.
The tool ships six commands, not five. status prints a one-shot live view of the current release, record counts and feed freshness. snapshot downloads all three datasets plus the change feed, cross-checks release consistency and stores an immutable, content-addressed local copy under a timestamped directory. verify re-reads a stored snapshot later and re-computes its hash. diff compares two snapshots structurally. changelog renders a markdown changelog between two releases from Sourcey's public JSON Feed. watch polls for the next signed release and is designed for cron, GitHub Actions or a systemd timer.
The snapshot format is deliberately explicit. The author writes that snapshot stores data alongside metadata containing the source, release_id, sha256 and capture time, and prints the digest; verify re-reads the file, recomputes the digest over a canonical JSON serialization and compares. The repository shows a manifest.json per snapshot directory holding the release_id, a consistency block with record counts, and per-file entries pairing a local SHA-256 with the signed artifact hash. If a stored file no longer matches its recorded local hash, verify exits non-zero and prints a drift warning.
Engineering weight is mostly carried by two design details. Canonical serialization — fixed separators and sorted keys — is the first, since, in the author's words, false diffs arise from key ordering alone when default json.dumps output is hashed. The second: digests are compared first by diff, and when digests are identical, the result short-circuits to "no changes" with no data walk at all. Whether a change monitor is trusted or ignored is decided by details of this kind.
Until he broke his own diff on purpose, the author says, he did not trust it. A fake company was added, one company's region field was changed from "EU" to "US", an offer was deleted, and a grade was changed from A to F — what he calls mutation testing. All four, he reports, were caught by the tool. His first version held the surprise failure: field values were not compared, only entity sets were, so no output at all was produced by a grade change — his stated lesson being that "same entities" and "same data" are different claims and both need testing.
Within the repository, attention is paid to the trust boundary. The tool never applies for an offer, redeems one, ranks it or purchases it, and approval is never produced out of unknown eligibility, according to its statement; instead of being an official Sourcey product, of the public datasets and JSON Feed it serves as a read-only consumer that operates independently. For tool-native discovery, readers are directed by it toward Sourcey's hosted MCP server, while for deterministic integration its HTTP API is recommended, and the point is made that ownership of the data rests with Sourcey and its publishers.
For freelancers and developers who cite registry data in proposals, research notes or agent memory, the practical value is the snapshot/verify split rather than the specific registry. A stored snapshot with a recorded digest lets you re-check later that the numbers you cited match the exact bytes you saw, and a release-to-release diff answers the question of what changed between the release you quoted and the one live now. The author frames the pattern as registry-agnostic — fetch JSON, canonicalize, digest, snapshot, diff — with the only registry-specific code being an endpoint table at the top of the file.
The tradeoffs are real. Zero dependencies is presented as a supply-chain argument: the author contends that every dependency is a vote cast on behalf of everyone who runs the tool, and that urllib.request, hashlib and json have been sufficient for a read-only tracker since well before modern packaging. The cost is that the tool does no more than read and compare — it does not resolve eligibility questions, does not apply for or redeem offers, and offers no hosted service. Anyone wanting richer integration is directed to Sourcey's own MCP server or HTTP API.
Several things remain unverified from the supplied material. The record counts, the release digest and the October 2, 2026 release date are the author's and repository's statements, not independently confirmed here. The mutation-test results are self-reported. The post lists sibling tools — a registry CLI, an SVG badge renderer, a wallet watcher and a bounty-board scanner — as part of the same one-file, stdlib-only, MIT-licensed family, but no independent evaluation of any of them is provided.
The broader claim worth weighing is the author's assertion that more registries are publishing versioned JSON because agents need stable URLs to cite. That is an argument, not a measured trend, and the evidence here covers one registry. What is concrete is narrower and still useful: a working, MIT-licensed, single-file example of digest-anchored change detection that a developer can read end to end in one sitting and point at another JSON registry by editing an endpoint table.
The author's own closing advice is the most transferable part: break the tracker on purpose before relying on it. A change monitor that has never been mutation-tested, in his phrasing, is just a vibes engine — and for anyone whose notes or citations depend on a registry staying still, that distinction is the whole product.