Evidence challenge 1, published 21 October 2026
Four bundles. Which ones are real?
These are evidence bundles from one real Cyber-Circuit run, plus the format spec and the receipts a second machine collected while the run happened. Some bundles have been tampered with. Using the spec alone, without our code, decide which bundles are valid and say why.
The task
- Read the bundle format spec. It is meant to be enough to build a verifier from scratch.
- Write your own verifier, in any language. Please don't use CircuitBreaker's code; the point is a second, independent implementation.
- Check each of
bundle-Atobundle-Dwith the trusted gateway keys, the trusted log key, and the receipts below. - For each bundle, give a verdict, valid or invalid, and the first check that fails. If you couldn't run a check (for example, no SLH-DSA library), say so rather than skipping it.
Files
| Spec | spec.md (CircuitBreaker evidence bundle format, version 1) |
|---|---|
| Bundles | bundle-A/ … bundle-D/, each with decision.jsonl, control.jsonl, checkpoints.jsonl, gateway-keys.pub.json, rekor-anchors.jsonl, rekor-log.pub.pem. For example bundle-A/checkpoints.jsonl. |
| Receipts | receipts.jsonl: the alarms a second machine received while the run happened, through a channel that could only append |
| Trusted gateway keys | gateway-keys.pub.json, key ID f481ce5d6f19fe6e496a637f77a4a0e98b1c1f1dfc6eaed464de7d101efda039 |
| Trusted log key | rekor-log.pub.pem: the public key of Sigstore's Rekor v1 log, https://rekor.sigstore.dev, log ID c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d, from Sigstore's published trusted root |
| Checksums | SHA256SUMS |
The run's start, trip, and shutdown checkpoints are also in the public Rekor log at indexes 3361100305, 3361101674, and 3361102328, so you can fetch them yourself.
Committed answers
We wrote down the expected verdict for each bundle before publishing, in a file with a random nonce so it can't be guessed. Its SHA-256 is:
85f6352b5e6dec3a816139829c869aeb964b0f64bc02f1692af1b08094d4b368
Now published: answer-key.json. Its SHA-256 matches the value above. With the answers public, this set is no longer blind; a second challenge will be. Questions or your own results are still welcome at info@quantum-clarity.com.
First independent answer: 4 of 4
We gave the challenge to Grok, xAI's model, with one instruction: write your own verifier from the spec, without our code. It wrote one in Python, ran every check in the spec, including the post-quantum signatures and live lookups in the public log, and reached the same verdict as our answer key on all four bundles, failing each invalid one at the same check.
| Bundle | What we did to it | Grok's verdict |
|---|---|---|
| A | Changed why the trip happened, then re-linked every later record so the journal's own hashes still checked out | Invalid, matches (signed checkpoints name journal heads that no longer exist) |
| B | Cut the trip out of every file, consistently | Invalid, matches (checkpoints the second machine received are missing) |
| C | Nothing | Valid, matches |
| D | Changed one byte of one post-quantum signature, leaving the classical one intact | Invalid, matches (the post-quantum signature fails) |
Grok's verifier and its full check-by-check output are published as written: verifier.py and results.txt (every check passed or failed per bundle, including the live log lookups).
Grok was run by us, so this is an independent implementation, not an independent party. It also listed twelve places where the spec was ambiguous or silent. Those are now answered in spec revision 1.1, which changes no format and no verdict. This challenge keeps the original spec.md as published.
What this does and doesn't test
- It tests whether the bundle format can be checked by someone else's code, and whether that code catches cuts and rewrites that our own verifier catches.
- It doesn't test whether the gateway recorded everything that happened, or anything about the agent sandbox. Those are lab results, described on Lab results.
- The run, the machines, and the spec are ours. An independent verifier is one step toward outside review, not a substitute for it.