Why I built it
Atomi began as a broader marketplace and audit project. While working on it, I kept coming back to a smaller problem: a green check mark says very little about what actually ran. In a normal repository, the code under review sits beside the tests judging it, so the same change can alter both.
For Build Week I cut away the marketplace and kept one goal: tie one approved check to one frozen source tree and one recorded run.
What it does
Evidence Gate accepts a source directory and a check definition authenticated with HMAC. It snapshots the source and rejects symlinks, special files, sensitive filenames, and key material before Docker starts.
The checker runs from a Docker image whose digest is recorded in the approval. The source is mounted read-only. Docker starts with no network, a non-root user, and resource limits, and the runner verifies the settings it actually received. When the run ends, Evidence Gate hashes the input again, records cleanup, and writes an event chain and private receipt authenticated with HMAC.
The demo covers four paths: PASS, an expected CHECK_FAILED, a modified receipt that fails verification, and a sensitive source tree rejected before Docker starts. PASS only means that this checker accepted this snapshot under this policy. It is not deployment approval.
How I built and tested it
The core is standard-library Python plus the Docker CLI. The baseline checker reads metadata and source structure but never executes code from the submission. I also made a small local receipt viewer; verification remains in the CLI.
I built the project in Codex with GPT-5.6 Sol. Codex helped turn the threat model into failing tests, including edited receipts, weakened Docker settings, and cleanup failures. It also helped debug the Linux and macOS paths. The released checker itself is deterministic and makes no model call.
The first green test suite used a fake backend. That was useful for unit tests, but it did not exercise the Docker boundary, so I added the full digest-pinned path on Linux.
Packaging revealed another problem. A test started from the source checkout can import the local package instead of the wheel being judged. The final judge job installs the release wheel offline, clears PYTHONPATH, and launches the demo from a temporary directory. CI also plants a fake atomi_evidence_gate package that exits immediately. If the judge imports from the checkout, the job dies. The demo still passes.
Today the repository has 28 unit and adversarial tests, a real Docker end-to-end run, fresh Ubuntu CI, and a no-rebuild judge bundle with the wheel, prebuilt Linux images, source commit, and checksums. All four demo scenarios run without an OpenAI API key or a paid service.
This is still an alpha. Docker is not a VM, the HMAC receipt is private authentication rather than a public signature, and PASS remains scoped to one approved check.
What I learned and what comes next
I initially called the idea an “AI auditor,” which pushed the scope in too many directions. The project became clearer once I wrote the acceptance rules as deterministic code. Codex was useful for proposing attacks and helping debug them; it is not in the verdict path.
The next practical step is a CI integration for team-owned checker policies. I would not call Evidence Gate production-ready before an external security review and a stronger signing and isolation model.
Log in or sign up for Devpost to join the conversation.