Published unchanged from the three registration files: the first written and committed on 21 October 2026 at 14:25 Irish time, before any result; the second at 21:12 the same day, before any of the new code; the third, re-registering E7a, E7b and E9c, at 00:46 on 22 October, before any of its code. Their deviations are dated at the end of each. Results: Evidence under attack.

VAS-1 evidence track, preview v0.1: pre-registration

Written and committed on 21 Oct 2026, before any VAS-1 result was computed. The commit that adds this file is the registration. Any change after the first scored run goes under "Deviations" at the end, dated, with the reason.

VAS-1 evidence track, preview v0.1, run by Aqta, not yet rerun by others. It is an evaluation suite, not a leaderboard, and it makes no claim beyond the systems and records named here.

What was looked at before registering

So that nobody reads this as blind when it is not: before writing this file we (1) read the plan (BENCHMARK-PATH-2026-10-22, section 2), the attestation-spec issuer-adversary document and the AWS CloudTrail log file integrity validation documentation; (2) fetched, once each, five unauthenticated public reads from the Seal production log (signed head, two inclusion proofs, one consistency proof, the key list) and saved them under fixtures/seal-production/; (3) confirmed that a production ACTION-v1 record and a production ATTESTATION-v1 receipt hash to the leaves the public log serves for them, which fixes the leaf format used below; (4) counted the arena's 1,529 signed records by outcome and found that 880 of them commit, through args_hash, to an approval reference the run files did not keep. No attack below has been run against any arm.

Question

For a record of an AI agent's consequential decision, can a third party who holds no account with the vendor or the provider check it offline from public material, reject tampering, and notice records that are missing, contradictory or misdated? Each test is a class of attack on the evidence, not on the agent.

Arms

The cloud arm is checked with a validator written from AWS's "custom implementations" documentation. Where a check goes beyond what aws cloudtrail validate-logs does, the result says so per attack. AWS's own tool needs live AWS access and was not run.

Reviewer model

The reviewer holds: the bundle the operator hands over, public material (published keys, public log heads and proofs, published verifiers), and for the cloud arm the provider's public keys fetched with the reviewer's own provider account (the documented ListPublicKeys route). The reviewer has no access to the operator's systems and no network during verification.

Scoring rule (identical for every arm)

Each test supplies genuine items, which must be accepted, and attacked items, which must be rejected or flagged. A test is PASS only if every genuine item is accepted, every scored attack is detected, and both lists are non-empty. Otherwise FAIL. N/A (stated reason) is reported where the arm has nothing the test could act on in principle, and is never counted as a pass. Sub-tests are shown; a class passes only if all its sub-tests do. Verdict tokens are VERDICT_PASS, VERDICT_FAIL, VERDICT_NA: none is a substring of another.

Negative controls, every test, every arm: the same test is rerun with an accept-everything checker and with a reject-everything checker. Both must score FAIL. If either scores PASS, the run aborts. Empty output is never a pass.

The eleven tests

Predictions (written before running)

• Seal: PASS E1, E2, E3, E4, E6, E8, E10, E11. FAIL E5 (approval format not published, use count not signed), FAIL E7 (both: leaves are cross-organisation hashes, so a withheld record is invisible, and A2 is open), FAIL E9 (E9c: log lag is not backdating, by design). 8 of 11.
• Cloud audit log: PASS E1, E3, E4, E6, E8, E11. FAIL E5 (approver identity is the operator's assertion), FAIL E7 (E7a expected to PASS through the hourly digest chain; E7b FAIL), FAIL E9 (E9c, late delivery is documented as normal), possibly FAIL E2 on signature hex case (AWS's sample decoder is case-insensitive). E10 not run. 6 of 11.
• Plain log: PASS E11 only. 1 of 11.
• No control: 0 of 11.

Limits stated before running

• Seal's arena records are signed by a local gateway with a local key, not the production key. The production arm is four real records, not a run.
• The cloud arm is a model, with a throwaway provider key. It is as faithful to the documentation as we could make it; a real trail, validated with AWS's tool, may differ in details we could not check offline.
• Every implementation in this suite, including both Seal verifiers, was written by Aqta. Nobody outside has rerun it.

Deviations

• 21 Oct 2026, after the first run: E10 gives the TypeScript verifier every item the Python verifier saw in E1 to E9 (25,975 distinct items, history bundles included), not only E1 to E3 as registered. Wider than registered, same rule. No verdict changed.
• 21 Oct 2026, first run: a crash in the E5 harness (an arena record with neither an amount nor a version) was fixed by choosing the changed value from a fixed list; no scoring rule changed.

VAS-1 evidence track: E5 re-registered as E5a to E5e

Written and committed on 21 Oct 2026, before any E5 code was written and before any E5 rerun. The commit that adds this file is the registration. Any change after the first scored run goes under "Deviations" at the end, dated, with the reason. Everything in PREREGISTRATION.md still holds except where this file replaces E5.

VAS-1 evidence track, run by Aqta, not yet rerun by others. An evaluation suite, not a leaderboard.

Why E5 is re-registered

In preview v0.1, E5 had three sub-tests (values, approver, use count) and Seal failed two of them: the approval format was not published with a verifier, and no signed record carried which use of an approval an action consumed. Aqta is now building the missing evidence: GRANT-v1 and a new USE-v1 record as drafts in attestation-spec, a chain profile in both reference verifiers, and a gateway that signs one USE-v1 record in the same transaction as each successful use claim. E5 is split into five assertions so that each property is scored on its own, and so that a pass on one cannot hide a fail on another.

E5 passes as a class only if all five of E5a to E5e pass. E7 and E9 are untouched by this work and are rerun unchanged. E10 grows: the chain bundles from E5 are added to the items both verifiers must agree on.

What was looked at before registering

The E5 design note (internal, 21 Oct 2026), the GRANT-v1 trust-model draft, the gateway's grant code as deployed in production (grants.py at the live revision, which differs from the repository's main branch: the live code carries scope_args, the exact argument values an approver fixes, and an organisation-scoped consumption key), and this harness. No E5 attack below has been run against any arm under the new definitions.

The five assertions

Scoring rule, unchanged from PREREGISTRATION.md: a sub-test is PASS only if every genuine item is accepted, every scored attack is detected, and both lists are non-empty. Accept-all and reject-all controls must score FAIL on every sub-test, or the run aborts.

Accepted means, for Seal, the chain verdict is PASS. FAIL and INCOMPLETE both count as not accepted. For every Seal item we also register which of FAIL or INCOMPLETE we expect, and report any mismatch as a missed prediction; that label does not change the score.

The scenario

The existing scenario (harness/scenario.py) is unchanged: one payment approval (g-pay-1, finance controller, exact values for invoice INV-2291, single use) and one deploy approval (g-dep-1, release manager, single use); decisions d1 (pay, allowed), d2 (overpay, refused), d3 (replay, refused), d4 (deploy without approval, refused), d5 (deploy, allowed), d6 (self-signed approval, refused). E5 adds, inside the E5 tests only, items built from it: a three-use approval (V2), a reissued approval sharing an intent_ref (V3), and the attacks below.

Seal arm

What the reviewer holds: the bundle (GRANT-v1 records, USE-v1 records, ACTION-v1 records each with the argument object its args_hash commits to), the issuer's public key pinned from public material, the set of approver public keys the relying party designates (taken from the approver's book, the ground truth here), and the chain profile of both reference verifiers from the local attestation-spec checkout. The issuer is simulated in the production format with a throwaway key, as in v0.1; the approvers' keys are throwaway keys. The Python verifier scores; the TypeScript verifier is compared in E10.

Genuine items (must be PASS): the honest bundle (d1 to d6, two grants, two USE records, refusals carry no USE); d1's chain alone; d5's chain alone; V2 (a grant with max_uses "3", three actions, uses 1, 2 and 3); V3 (two grants for one intent_ref, one use between them).

Listed, not scored, in E5e: the operator withholds BOTH a second use's ACTION and its USE. This is omission, which is E7's class, and the design states it as a limit before the run: the bundle that remains is internally complete, so we predict Seal's verdict on it is PASS (not detected), and the cloud arm detects it through its hourly digests. In v0.1 this item was scored under E5c; it moves out of E5 for every arm alike, and the result reports it beside the table so the cloud log's advantage on it stays visible.

Seal predictions: E5a PASS, E5b PASS, E5c PASS, E5d PASS, E5e PASS. E5 PASS. E7 FAIL and E9 FAIL as before. E10 PASS with the chain bundles included. Predicted total 9 of 11.

E5d's enforcement half (the boundary itself refuses a second or concurrent use) is not computed by this harness, which has no gateway. It is the gateway's own tests G1 (concurrent claims: exactly one ALLOWED, exactly one USE) and G2 (reissue under the same intent_ref: BLOCKED, no second USE), on the gateway branch, reported beside the table. The harness scores the evidence half.

Cloud audit log arm

Most favourable honest configuration, as in v0.1, extended: every approval and every decision reaches the trail as an event; the approval event carries the exact approved values, maxUses, notAfter and, new for E5d, an intentRef, so a reviewer can count uses per authorisation as well as per approval. The approval events are written by the operator's application, as in v0.1. A deployment where each approver writes under an IAM principal of their own was considered: those principals are administered by the operator in its own account, so a relying party that trusts them trusts the operator's administration. It is not modelled as a separate arm.

The reviewer's check: validate the trail (unchanged validator), then compare each ALLOWED action with its approval event (values, resource, window), count ALLOWED uses per approval and per intentRef against maxUses, and require an approval event for every ALLOWED action that names one.

Cloud predictions: E5 FAIL (E5b, E5c). Total unchanged, 6 of 11.

Plain log arm and no control

Plain log: the reviewer gets the JSON-lines log and the most favourable check we can give it (values compared with the approval row, uses counted per approval and per intent reference). Every sub-test includes at least one attack made by editing or omitting rows, which nothing in an unsigned log can show. Prediction: E5a to E5e all FAIL, total 1 of 11. No control: nothing recorded, E5a to E5e all FAIL, total 0 of 11.

Limits stated before running

• The Seal issuer in E5 is simulated in the production format with a throwaway key; the gateway that signs USE-v1 records is built and tested on a branch and is not released.
• Approver authority rests on the set of keys the relying party supplies. No signed, published organisational approver root exists yet.
• A compromised issuer key could sign a false USE; the public log makes it visible to a monitor, not impossible.
• GRANT-v1 and USE-v1 are drafts, not frozen. Both verifiers and the chain profile were written by Aqta.
• E7 (omission) and E9c (backdating) are untouched by this work.

Deviations

• 21 Oct 2026, first run (a dry run of the E5 module before the full harness run): the plain-log E5a attack was built wrongly. It edited the approval row to 750000 but left d1's row at 480000, so the log contradicted itself and the favourable check caught it, and plain-log E5a scored PASS against a FAIL prediction. That item did not instantiate the registered attack ("an edit nothing in an unsigned log can show"). It was replaced by the self-consistent edit: d1 paid 750000, and the approval row and d1's row both rewritten to 750000 (ground truth: 480000 approved). Plain-log E5a then scored FAIL as predicted. No class verdict or total depended on it: plain-log E5 fails on E5b, E5c and E5e regardless. Every Seal and cloud item was unchanged by this correction.
• 21 Oct 2026, in writing the code: the cloud table above lists "the second use's log file withheld" as a scored E5e item, which contradicts the rule written above it that withholding a second use moves out of E5 for every arm alike. The rule was followed: the item is listed, not scored, for the cloud arm as for Seal. The cloud arm detects it (its hourly digests list the file) and the result says so. Cloud E5e is PASS either way.
• 21 Oct 2026: the E10 items now include the 41 Seal chain bundles from E5, as registered above; both chain verifiers are loaded from attestation-spec commit e0a7c18 (unpublished, branch e5-use-evidence-2026-10-21).

VAS-1 evidence track: E7a, E7b and E9c re-registered as E7a.2, E7b.2 and E9c.2

Written and committed on 22 Oct 2026, before any E7 or E9 code was written and before any rerun. The commit that adds this file is the registration. Any change after the first scored run goes under "Deviations" at the end, dated, with the reason. Everything in PREREGISTRATION.md and PREREGISTRATION-E5.md still holds except where this file replaces E7a, E7b and E9c.

VAS-1 evidence track, run by Aqta, not yet rerun by others. An evaluation suite, not a leaderboard.

Why, and what does not change

After the E5 rerun Seal fails three sub-tests: E7a (the operator withholds a record), E7b (the issuer never records a decision, ISSUER-ADVERSARY A2) and E9c (a record is backdated). Aqta is building three pieces of evidence, all drafts:

1. Witnessed time (E9c). The hourly log witness countersigns the public log head into Sigstore, so each head has a time the issuer does not control. A new opt-in verifier profile, witnessed, fails a record whose claimed time is more than a stated tolerance before the witnessed time of a witnessed head that does not contain it.
2. Signed checkpoints (E7a). Every hour, including empty hours, the issuer signs a CHECKPOINT-v1 statement per organisation: how many ACTION-v1 and USE-v1 records the organisation has in that hour, a hash over exactly those records, and a link to the previous checkpoint. Checkpoints are leaves of the public log under a new entry tag. A new opt-in profile, complete, checks a bundle of records against the checkpoints covering a review window.
3. Executor co-signing (E7b). The system that carries out an action (a payment or deploy system) refuses any action without a verifying Seal ALLOWED record and USE record, and keeps its own signed, sequenced log (EXECUTION-v1). The complete profile reconciles that log against the records the checkpoints count.

The rule this file follows: no existing attack, test or pass rule changes. Each re-registered sub-test contains the v0.1 attack of the sub-test it replaces, item for item: the same withheld record (d3), the same never-recorded decision (d3, a refusal), the same backdated record (d6, claiming 10:06:00, first logged at its true time 12:31:50). What differs is the evidence the reviewer holds (checkpoints, witness statements, an executor log) and Seal's checker (the new profiles). New attacks are added beside them. The scoring rule is unchanged: a sub-test is PASS only if every genuine item is accepted, every scored attack is detected, and both lists are non-empty; accept-all and reject-all controls must score FAIL or the run aborts.

Class composition, as in E5. E7 passes only if E7a.2 and E7b.2 both pass. E9 passes only if E9a, E9b and E9c.2 all pass. E9a and E9b keep their v0.1 items and checker unchanged; the v0.1 E9c item moves into E9c.2 unchanged. This applies to every arm alike. The v0.1 forms of E7a, E7b and E9c (v0.1 evidence, published 1.2.7 verifier) are still computed for Seal and reported in the notes of the new sub-tests; they are not counted, as v0.1 E5 was not.

Outside E7, E9 and E10, every result in every arm must be byte-identical to the E5 rerun (bd7bfed). E10 grows by the new bundles.

What was looked at before registering

The E5 design note and its section 9 of findings, this harness (E5 rerun bd7bfed), ISSUER-ADVERSARY.md (A2 and A3 and the vector a3-lag-is-not-backdating), the public-log code in the gateway (transparency_service.py, attestation_binding.py: entry tags receipts 0x00, anchors 0x01, actions 0x02, USE 0x03), the startup sequence that numbers every table from one log_seq sequence, and the log witness (hourly at :17, consistency from the last head, head file countersigned into Sigstore with keyless cosign). No E7 or E9 attack below has been run against any arm under these definitions.

The world every arm records (fixed, deterministic)

The v0.1 scenario is unchanged: d1 10:05:10 pay ALLOWED, d2 10:07:40 overpay BLOCKED, d3 10:09:05 replay BLOCKED, d4 10:41:30 deploy without approval BLOCKED, quiet hour 11:00 to 12:00, d5 12:24:15 deploy ALLOWED, d6 12:31:50 self-signed approval BLOCKED; review requested 14:00. The review window is [10:00, 14:00) UTC, as in v0.1 where the cloud reviewer knows the trail ran until the review request.

For Seal the simulated issuer (throwaway key, production format) now logs what the E5 gateway logs: each ALLOWED granted decision is a USE-v1 record followed by its ACTION-v1 record, each refusal an ACTION-v1 record. Other organisations' leaves interleave as in v0.1, after five leaves of earlier history. Checkpoints for the organisation are issued two minutes after each hour closes (11:02, 12:02, 13:02, 14:02) and logged then; the chain starts with the 10:00 to 11:00 hour (sequence 1). Hour 10 counts five records (d1's USE, d1, d2, d3, d4), hour 11 none, hour 12 three (d5's USE, d5, d6), hour 13 none. The witness fetches the public head at HH:17:00 every hour from 09:17 to 14:17 and the time authority stamps it at HH:17:42. The reviewer's target head is signed by the issuer at 14:20:00.

The draft formats and profiles (summary; the specs go in attestation-spec, drafts, not frozen)

All flat, string-only members, canonical JSON, Ed25519, strict base64url, as ACTION-v1 and USE-v1.

• CHECKPOINT-v1 (checkpoint-1), signed by the issuer: org_id, checkpoint_seq, prev_checkpoint_hash ("" for sequence 1), period_start, period_end, record_count, total_count, records_hash (SHA-256 over the sorted 32-byte leaf hashes of the ACTION-v1 and USE-v1 records whose timestamp lies in the period), timestamp (issued, not before period_end), public_key, signature. Log entry tag 0x04, the next free tag.
• EXECUTION-v1 (execution-1), signed by the executor: executor_id, entry_seq, prev_entry_hash, org_id, result (EXECUTED or REFUSED), action_id, action_leaf_hash, use_id, use_leaf_hash, args_hash, timestamp, public_key, signature.
• WITNESS-v1 (witness-1), signed by the time authority: witness_id, statement_seq, prev_statement_hash, log_public_key, tree_size, root_hash, head_timestamp, head_signature, witnessed_at, public_key, signature. A stand-in for the Sigstore-anchored countersignature: in production the time is Rekor's integrated time under Rekor's ECDSA key; here a throwaway Ed25519 key the issuer does not hold plays that part.

witnessed profile (E9c.2): the reviewer pins the issuer key and the time-authority keys and states a tolerance (3600 seconds). Witness statements must form one contiguous chain; each must witness a head the pinned issuer signed; each must be consistent with the target head; each record must be included in the target head. For each record, W_inc is the first witnessed head that contains it and W_prev the one before. FAIL if the record claims a time after W_inc's witnessed time, or if W_prev's witnessed time is more than the tolerance after the record's claimed time. INCOMPLETE if no witnessed head contains the record yet, if W_inc is the first statement and is more than the tolerance after the claimed time (lateness cannot be bounded), if a consistency proof is missing, or if no witness key set was supplied. What this detects, stated before running: with an hourly witness, a record logged more than the tolerance plus one witness interval after its claimed time is always caught; one logged within the tolerance is never caught.

complete profile (E7a.2, E7b.2): the reviewer pins the issuer key, states the review window and, for E7b.2, pins the executor key. Checkpoints must chain contiguously and cover the window (else INCOMPLETE); every presented record must fall in a checkpoint's period; per checkpoint, fewer records than counted is INCOMPLETE (withheld), any other mismatch is FAIL. Every executor entry that names a Seal record must find that record in the bundle (else FAIL), and an EXECUTED entry must name an ALLOWED action and its USE.

Verdict labels: PASS is accepted; FAIL and INCOMPLETE are both not accepted. As in E5, every Seal item's expected label is registered and any mismatch is reported as a missed prediction; the label does not change the score.

Seal arm

E7a.2, records withheld by the operator (the issuer is honest)

Condition: the reviewer holds the organisation's checkpoints (handed over with the bundle, or fetched by the reviewer). Checkpoints count ACTION-v1 and USE-v1 records only; ATTESTATION-v1 model-call receipts are not counted.

Prediction: E7a.2 PASS.

E7b.2, decisions the issuer never records (the issuer is the adversary)

Condition, stated in the first line of the results: the executor cooperates. It refuses any action without a verifying Seal ALLOWED record plus USE, keeps its own signed and sequenced log, and hands the reviewer that log in full; the reviewer pins the executor's key. A real deployment needs the customer's executor to adopt this. The executor here is simulated with a throwaway key. In every attack the issuer's checkpoints and records are consistent with its omission (it counts only what it logged); the executor's log is honest and complete.

Prediction: E7b.2 FAIL. The v0.1 attack is an omitted refusal. A refusal that never reaches the executor leaves no trace outside the issuer, so executor co-signing cannot catch it. We register this miss before running. Detecting it would need a second party that sees every request (for example the caller signing and sequencing its own requests); that is not built and not claimed.

E9c.2, backdating

Condition: the hourly witness ran without a gap across the window, and its statements carry a time from an authority the issuer does not control (Sigstore in production; simulated here). The reviewer takes the witness statements from public material, not from the operator. Tolerance 3600 seconds.

Prediction: E9c.2 PASS.

Seal predictions: E7a.2 PASS, E7b.2 FAIL, E9c.2 PASS. E7 FAIL, E9 PASS (E9a and E9b PASS as before). E10 PASS with the new bundles and 0 disagreements on verdict and reason. Predicted total 10 of 11.

Cloud audit log arm (existing behaviour, unchanged checker)

Listed, not scored, so the comparison stays fair: (1) an executor log reconciled against the trail would show d1 and d5 executed with no trail event; the cloud arm's executor cannot verify a trail event before acting (delivery lags by minutes), so this is not part of its existing behaviour; (2) the same one-hour tolerance applied to the provider's digest windows (an outside clock) would flag both backdated events; it is not what validate-logs does, and AWS documents late delivery as normal. Both are computed and reported beside the table.

Cloud predictions: E7 FAIL, E9 FAIL. Total unchanged, 6 of 11.

Plain log arm and no control

Plain log: E7a.2 (d3's row withheld, v0.1; d1's row withheld), E7b.2 (d3 never logged, v0.1; d1 never logged), E9c.2 (d6 backdated, v0.1; d5 backdated) all FAIL; E9 keeps its reorder item. Total 1 of 11. No control: nothing recorded, all FAIL, total 0 of 11.

Gateway (reported beside the table, not scored by the harness)

On a gateway branch from the E5 branch: checkpoint issuance (an idempotent job that issues every due hour, empty hours included, safe to run from several instances at once), checkpoints logged under tag 0x04 from the shared log_seq sequence with every backfill base and setval spanning every logged table, and a public read that returns a record's inclusion proof and the consistency proofs from witnessed sizes to one head, from one snapshot. Tests for each. The gateway is not released.

Limits stated before running

• Simulated issuer, simulated witness and time authority, simulated executor, all with throwaway keys. The real witness signs through Sigstore keyless (ECDSA, Fulcio, Rekor); the draft WITNESS-v1 stand-in does not verify real Sigstore bundles.
• E7b.2 depends on executor cooperation, and catches executed actions and refusals taken to the executor only.
• E9c.2 depends on a gapless witness and catches backdating beyond the tolerance only.
• Checkpoints do not count ATTESTATION-v1 receipts. They start from the hour they are switched on.
• CHECKPOINT-v1, EXECUTION-v1, WITNESS-v1 and both profiles are drafts written by Aqta. Nobody outside has rerun this.

Deviations

• 22 Oct 2026, first run (a dry run of the E79 module before the full harness run): Seal E7a.2 and E7b.2 scored FAIL because every genuine item came back INCOMPLETE. The cause was the harness's simulated issuer, not the profile or any attack: when it built hour 11's checkpoint it counted hour 10's checkpoint (stamped 11:02) as one of the organisation's records. This file registers checkpoints as counting ACTION-v1 and USE-v1 records only, and so do the spec and the gateway. The simulated issuer was corrected to count those two kinds only, and a harness test now pins it. No attack, expected verdict, condition or scoring rule changed. In that dry run E9c.2 already scored PASS and every cloud, plain-log and no-control result was as predicted.
• 22 Oct 2026, while writing the verifier (after this file was committed, before the first run): the profile summary above says every presented record "must fall in a checkpoint's period" without saying which verdict a record outside every checkpoint gets. It is INCOMPLETE: a record outside the checkpoints means checkpoint evidence is missing, which is how missing evidence is labelled everywhere else, and it is what the registered label for "withholds d3 and the 10:00 checkpoint" (INCOMPLETE) assumes. The label does not change the score: FAIL and INCOMPLETE are both not accepted.
• 22 Oct 2026: the results table now lists the sub-tests of every part of a class, so E9 reads "E9a, E9b, E9c.2". Rendering only; outside E7, E9, E10 and the totals every row is unchanged.