On PyPI: you can pip install these today.
proof-surface v0.1.0: the accountability contract, a checkpoint that says no until it’s sure, records of work done and permission given, and chains of who delegated what. The shared foundation the release-safety tools clip onto. its own page →
public-surface-sweeper v0.1.1: the check you run before a release goes out. It confirms required files are present and sweeps for passwords, keys, or tokens that must not leak, so nothing slips public that shouldn’t. Built on proof-surface.
repo-proof-index v0.1.1: an index over the evidence records and receipts a project produces, laid out so a reviewer can actually check them. It collects and organizes the evidence; it never certifies it, and that stays a human’s job.
model-provenance-validator v0.1.1: checks a model or release’s honest record of where it came from against what it claims, and blacks out any passwords, keys, or tokens from its own output while doing it.
index v2.9.0 beta, as index-graph: a compact JSON inventory of every git repo in a multi-repo workspace, the tool that lets the whole system know its own shape at a glance. build-color is the sixth on PyPI, a product with its own page.
Public on GitHub: built and open, not yet on a package index.
The rest are real and public, just not published to PyPI, so I list them here as what they are. secret-redact-io wraps file reads, web fetches, and shell calls so that passwords, keys, or tokens are blacked out before they leave, and keeps a fingerprint-only record for auditing. provenance-sensorium is the evidence receipt you produce before shipping (its own page). release-surface-scanner and proof-surface-report handle release-packet scanning and review reporting. And a small set of agent-workflow tools (agent-routing-kit, context-curator-lite, agent-hook-pack, workflow-harness-lite), plus gpu-trace-validator, which checks GPU-trace JSON against a schema and emits bounded receipts.
“Public” here means the source is on GitHub and open to read. It does not mean “on PyPI,” and I’ll keep those two words apart.The count, corrected in the open. Proof before trust, on my own résumé.
An earlier version of this site said “19 packages on PyPI.” That was rounding GitHub-public repos and unpublished local packages into the PyPI number. Checked against the index, the honest figure was six toolkit packages; re-checked 2026-07-01, those six still hold, and the flagship engines have since published under their own names. So here is the real artifact, and the real count.
# installed straight from PyPI, a real published package $ pip install index-graph && index --help usage: index [-h] [--version] {status,doctor,demo,map,graph,context,...,verify,freshness,bench,mcp} ... # the honest accounting of the toolkit packages ON PyPI: proof-surface 0.1.0 public-surface-sweeper 0.1.1 repo-proof-index 0.1.1 model-provenance-validator 0.1.1 index-graph listed; source/tag 2.9.0 beta build-color 1.0.2 # = 6 toolkit packages on PyPI. The flagship engines publish separately # (gather-engine, forum-engine, crucible-bench, emet); their anchors are on the catalog.
Six toolkit packages, verified against the package index by author; the flagship engines and the Build products publish under their own names. The other tools are real and public; they’re just on GitHub, and saying so is cheaper than being caught rounding up.
PyPI membership was verified against the live package index on 2026-06-21 and re-checked on 2026-07-01. Index’s 2.9.0 beta version is taken from its current local public source and matching tag on 2026-07-12; this page does not present that as a fresh registry-version check. Honest limit / correction: the old “19 on PyPI” figure conflated three different things: published packages, public-on-GitHub repos, and packages only installed locally from source. One of the names I’d listed (agent-audit) turned out to be a different author’s package entirely, so it’s dropped from any claim. This is exactly the kind of quiet over-count the whole project exists to catch, including when I’m the one who made it. See a sample release hygiene report →
Why a ring of tiny tools.
A discipline you have to remember isn’t one. The reason these exist as separate, boring, single-purpose tools is that the moment release-safety depends on me being careful at the end of a long day, it’s already failed. So the sweep, the index, the check of where a release came from, the guarded file and shell calls: each is small enough to run every time and trust, and each says no by default and refuses to round up. They’re the connective discipline that lets the bigger working parts ship without me crossing my fingers.
Six on PyPI, the rest on GitHub, and I’d rather state the smaller true number than the bigger comfortable one.