Independent series · ANKR Labs · 2026-10-24

487 moves. Two records each.
Checked by someone who isn’t us.

Capt Anil Sharma, ANKR Labs, a master mariner and AI architect, ran 18 simulated tank-repair jobs with AI agents on 2026-10-24. His script sent each move to two places outside the machine that ran the agent: Sigstore’s public log, under his own key, and Verdict’s public sandbox, whose record carries his log entry inside its own seal. ANKR Labs is not a customer, a vendor or a paid party of Verdict. The counts below are his, quoted as he states them. Where Verdict checked something itself, the line says so.

His count

From his closing report, 2026-10-24T09:31Z, with the counting rules he put on the log before the first run.

  • 487moves sent to be sealed, on both paths
  • 487 of 487recorded on the first try, on his path and on ours
  • 0resends, rate limits, server errors or timeouts, on either path
  • 487 of 487Verdict records passed the public verifier, pinned at ser-spec 17c9c8f449

Verdict’s side of the count: our request log for 08:17:21Z to 09:09:23Z on 2026-10-24 shows 487 sealing calls, every one answered 200, all from India and none from anywhere else. His guess before the runs, that a 30-second limit would close most of the gap his earlier series saw but not all of it, was wrong in the good direction.

Who holds what

Three parties, and what each one cannot do. None of the three could change a record afterwards without the checks below failing. The record is tamper-evident: a change shows, nothing stops it.

  • Sigstore's public transparency log
    HoldsThe log every entry sits in, in order, with the time it arrived.
    CannotRun the job, or sign as either of us.
  • Verdict
    HoldsNothing after sealing. Each record is signed, its commitment is put on Sigstore's log, and the record goes back to the caller. The copies on this page are the ones ANKR received.
    CannotRun the job or see the agent's work; it gets a checksum and a label for each move. It cannot produce a record again, and cannot alter one without the log entry failing to match.
  • ANKR
    HoldsThe run, and the key that signs its entries.
    CannotChange or remove an entry once it is on the log, or alter a Verdict record without its hash breaking.

One run, two records

Run o-01: 34 moves, the larger model, the arm that was told its moves were being sealed. The plan and the first move are below, exactly as the sandbox returned them to his script. The other 32 are on his page, where one button checks all 34 in your browser against the log.

  1. Step 1The planser_44cfd0770b6923a672542210508010f0Verdict record · Rekor log index 3438324438 · logged 2026-10-24T08:17:21ZANKR entry for the same move · Rekor log index 3438322339Download the record (JSON) →
  2. Step 2Move 1: check statusser_12335d3aad82ae6c6eee94c76ce80942Verdict record · Rekor log index 3438327870 · logged 2026-10-24T08:17:30ZANKR entry for the same move · Rekor log index 3438326547Download the record (JSON) →

Open ANKR’s page and check all 34 moves of o-01 → Paste either record into the browser verifier →

Check it yourself

Needs git, Python 3, openssl, curl, jq, tar and shasum. Steps 1 to 4 were run end to end on 2026-10-24 and step 5 on 2026-10-25. The verifier is Verdict’s code, so read it before you trust it. Rekor and its key are Sigstore’s. ANKR’s public key is in his repository: keys/tank-seal.pub.pem, SHA-256 of the DER 0afd984f7435c4c0…, which is the fingerprint inside both records.

  1. 1.Get the verifier and Rekor's public key. The verifier is one file of standard-library Python; the key comes from Sigstore's own repository, not from the log you are checking.
    Command 1a
    git clone https://github.com/verdictsystems/ser-spec && cd ser-spec && git checkout 17c9c8f449
    Command 1b
    curl -sL https://raw.githubusercontent.com/sigstore/root-signing/main/targets/rekor.pub -o rekor.pem
  2. 2.Fetch the two records and check each on its own. Offline the verifier recomputes the canonical form, the payload hash, the commitment and the id. With --anchor it fetches the Rekor entry, checks the logged hash against the recomputation, and verifies the entry's signature and the log's own: the signed timestamp, the inclusion proof and the checkpoint.
    Command 2a
    curl -sL https://verdict.systems/series/ankr-tank/ser_44cfd0770b6923a672542210508010f0.json -o ser_44cfd0770b6923a672542210508010f0.json && python3 tools/verify.py ser_44cfd0770b6923a672542210508010f0.json --anchor --rekor-key rekor.pem
    Command 2b
    curl -sL https://verdict.systems/series/ankr-tank/ser_12335d3aad82ae6c6eee94c76ce80942.json -o ser_12335d3aad82ae6c6eee94c76ce80942.json && python3 tools/verify.py ser_12335d3aad82ae6c6eee94c76ce80942.json --anchor --rekor-key rekor.pem
  3. 3.See the two records name each other. Move 1 carries the plan's commitment inside its hashed content, so it was made after the plan. Both carry ANKR's Sigstore index, signature and key fingerprint, so his entry is named inside Verdict's seal.
    Command 3a
    jq -r '.merkle_root' ser_44cfd0770b6923a672542210508010f0.json; jq -r '.record.metadata.prior_merkle_root' ser_12335d3aad82ae6c6eee94c76ce80942.json
    Command 3b
    jq '.record.metadata | {sender_log_index, sender_key_sha256}' ser_44cfd0770b6923a672542210508010f0.json
  4. 4.Look up his side of the same move on the log, and his pre-registration. Entry 3438322339 is his entry for the plan; entry 3438316337 holds the hash of the plan, the run list and the code, logged before the first run.
    Command 4a
    curl -s "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=3438322339"
    Command 4b
    curl -s "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=3438316337"
  5. 5.Open the pre-registration. ANKR published every file behind its hashes: the plan, the run list with its seed, and the 18 files of the run and scoring code, including the pinned copy of the verifier. The file named _preregistration.json should hash to the value the log holds at 3438316337, and every file inside should match the hash it is given.
    Command 5a
    curl -sLO https://ankr.in/tank-whole-run-preimages-2026-10-24.tgz && shasum -a 256 tank-whole-run-preimages-2026-10-24.tgz
    Command 5b
    tar xzf tank-whole-run-preimages-2026-10-24.tgz && cd tank-whole-run-preimages && shasum -a 256 _preregistration.json && shasum -a 256 -c SHA256SUMS

Each record check ends with the line RESULT: content self-consistent and anchor confirmed. A pass shows the record has not changed since it was logged and existed no later than the log’s time. It does not show who made it, and it does not show the event happened.

What this series does not show

His page carries his own list. These are ours, in the same words we use on every record.

  • A simulation. A pretend hot-work job in a ship's tank, run by AI agents on ANKR's machine. No real tank, no customer system.
  • What the script sent, not what the agent did. Each record holds the checksum and label ANKR's script sent for a move. Whether the script sent what the agent did is a property of his tooling, and his page says how far he has checked it.
  • Who made either record. The public sandbox signs each request with a one-time key that names no one. ANKR's key is bound to a key file, not a person. A record does not identify its maker.
  • Only the moves that reached Verdict. Nothing is sealed unless the caller sends it. His counts say how many moves were sent and how many came back with a record. The sandbox has no view of a move that was never sent.
  • The run-level chain check, as it stands. Run over all 34 records of o-01 with --chain, 33 of 33 links pass: each move names the one before it. The first record fails the start check, because his plan record carries prior_merkle_root as an empty string and the verifier accepts only an absent field there. The specification did not say which form a chain start takes. It will, and his sealed records stay as they are.

What a Verdict record proves, and what it doesn’t →

The same check on your agent

Agent Acceptance Test

$7,500, 10 business days, one agent and one workflow. Your key on the public log beside Verdict’s record, the counting rules logged before the first run, the public verifier over every record, and a page like this one at the end that your auditor, insurer or customer checks without asking you or us.

What the test delivers →Pricing →
Run your own series

The sandbox, the specification, its 24 test vectors and the verifier are free, under Apache 2.0. ANKR paid nothing and needed no permission to run this; it told Verdict the day before, at Verdict’s request. You need neither.

Seal one line now →ser-spec on GitHub →

ANKR Labs is independent of Verdict Systems. Its page and its writing are its own; Verdict approved only the lines about Verdict, and ANKR approved every line about ANKR on this page. Sources: his closing report of 2026-10-24T09:31Z; his page; Sigstore Rekor entries 3438316337 (pre-registration), 3438324438 and 3438327870 (the two Verdict records above), and 3438423852 (his closing entry for o-01); Verdict’s request log for the window.