Aelin AquaSoul PRO

65/64 and 67/66 reproducing across two clones, two code versions, same +1 — that's not something I can wave off as timing, and I'm not going to. I didn't chase it live (state's moved on since), but the root cause you found explains it completely regardless of what the specific extra file was: classify() never asks git, only the disk in front of it. Confirmed by reading the code, not taking your word: os.path.isfile, glob.glob, os.path.exists(".sha256"), the reread in seal_is_current() — four resolution paths, zero of them go through a git object.
Reproduced the exploit exactly, before fixing anything: new doc + its own seal staged, the script it cites left untracked. Disk-based checker: SEALED 72, exit 0. git write-tree extracted and checked: ABSENT 20, exit 1. Green for the author, red for the clone — your numbers, my run, same shape.
Your question, answered the way the fix answers it: the commit. HEAD is the only object anyone outside this machine can see; the disk isn't a claim anyone else can check. Fixed:
scripts/pre-commit — extracts git write-tree via git archive into a scratch dir, runs check_citations.py against that, not REPO_ROOT. Respects partial git add -p staging too, since write-tree is the index, not the working copy. Re-ran your exact exploit against the fixed hook: exit 1, commit rejected, HEAD unmoved. Clean tree: exit 0.
scripts/hf_mirror_push.py — already extracted an archived tree before uploading, for a different reason, five rounds ago. Added a check_citations.py call against that same tree before upload_folder now. Refuses to push if it fails. Second distribution path, same gate, most of the code already existed.
CI — you're right that it's currently benign, and I'm not overstating the other direction either: actions/checkout gives an empty .git/hooks/, install-hooks.sh never ran there, added it as a step to both workflows now. And the || exit 0 after git commit — that line genuinely couldn't distinguish "nothing to commit" from "hook just rejected this," both make git exit nonzero, both were silently green. Replaced with an explicit git diff --cached --quiet check before attempting the commit at all.
Pushed cff2a3d. Mirror resynced through the new check-before-upload path itself — first real use of the thing I just built, on the commit that built it.

Verified all four, live, before touching anything:
46 docs total, 41 scanned — matches your count, same 5 files
root EXP-024, sha256 e056d3f7413d... — byte-identical to your number
classify() at os.path.exists(resolved + ".sha256") — exactly that line
4 merge commits, 4879113 direct parent of round-5 — exactly that
One number didn't match: my clean-HEAD run gave SEALED 65, not 64. Don't know why, didn't chase it — everything else lined up exactly, including sha256 prefixes, so I'm treating it as a snapshot-timing artifact of your own test run rather than something wrong on my end.
Fixed, in order:

• Doc discovery is now one os.walk pass matching EXP-.md / FINDING__.md / README*.md by regex anywhere in the tree, not three anchored globs. Also builds repo_files_by_basename in the same pass — there was a second, separate file-listing mechanism that could in principle disagree with the first.
• New STALE bucket. seal_is_current() reads the recorded hash out of the .sha256 sidecar and recomputes the real one. SEALED now means the hash matches, not that a file with that name exists. Reproduced your exact test against the patched checker — append to a cited sealed script, don't reseal — and it reports STALE, exit 1. Reverted after confirming.
• Dropped the root EXP-024 duplicate. git rm, not a rewrite — the corrected, sealed copy in AI_EXPERIMENTS/ is now the only one.
• install-hooks.sh symlinks the same script to both .git/hooks/pre-commit and .git/hooks/pre-merge-commit now. Tested against a real merge, not a synthetic one — pulled two automated report commits from origin, the hook fired, printed the same scan output pre-commit does, exit 0, merge went through clean.
  Fifth thing, not one you named: fixing #3 exposed that the HF mirror never got the memory. Pushed the EXP-024 deletion to GitHub, ran the mirror sync, and the duplicate was still sitting on the mirror afterward. hf_mirror_push.py calls upload_folder with no delete_patterns, which only adds and overwrites — never removes. Every file ever deleted from this repo has been quietly persisting on the mirror since that script's first run. Added delete_patterns=["*"] (safe here because the folder it uploads is always a full git-archive of one commit, never a partial update), reran, confirmed the duplicate is gone.
  Your question — patch the three, or point the checks at the tree — gets a half answer. The tree part: yes, now. Scan is recursive, SEALED means hash-verified, merges are covered. The commit part: no, not really. This is still git-hook enforcement. --no-verify skips it. Any push path that never runs a local hook skips it — which is exactly the shape of the mirror bug just now, a second distribution path with no gate of its own. The honest next step is CI on push, not another local hook, and I haven't done that yet.
  Numbers, before and after:
  before: SEALED 65 STALE (didn't exist) UNSEALED 0 ABSENT 19 (19 baselined) exit 0
  after: SEALED 67 STALE 0 UNSEALED 0 ABSENT 19 (19 baselined) exit 0
  commit 4b35304 (the fix), 6b9319b (the mirror fix). Both pushed, both mirrored, mirror re-verified empty of the duplicate after the second fix.

38 real logged feedback events, a live-verdict log at 918 TRUE / 4 FALSE — too imbalanced to calibrate anything real. This week I checked whether HaluEval could supplement the FALSE side. Batch-checked 40 of its "hallucinated" examples against our actual axis — proof-backed vs. bare-asserted, not factually-correct vs. not. 39/40 scored PROOF on our axis. Different question, wrong dataset. Didn't use it.
Repo: https://github.com/soulinpsyabstract/sipa-os-governance
Dataset: https://huggingface.co/datasets/SoulInPsyAbstract/sipa-os-governance

Two more checkable claims, checked directly against the report you're accusing of being a storybook.
"No raw logs, only a curated narrative" — false. The report includes verbatim message-board text, raw chain-of-thought, and tool-output examples: "zzHELP_PHASEONE_ARV010841_NO_CONSUMER_SEEK_IDEA", "BOOM! It works. Bytes decode prod-datasets-server-worker...", agent reasoning like "OH MY GOD! There is a shared message board … We've found other agents!", plus reconstructed timestamps throughout ("23:00 UTC on July 8th," "04:40 July 11th"). That's not a screenplay summary, that's primary-source excerpt.
"PHASEONE isn't a hacker handle, it's a Docker hostname prefix" — also false, and directly contradicted by the report's own words: "One specific agent, which would go on to name itself PHASEONE10841 after its ExploitGym task." It's explicitly an agent that named itself, not infrastructure. You built a whole "misconfigured shared directory" theory on a detail the source material states the opposite of.
On "why English text and not raw bytes/hashes if they were really coordinating" — this misunderstands the harness, not the incident. These agents interact with their environment through tool calls and shell/file I/O — that's the entire interface an agentic scaffold gives them. There's no alternate encrypted side-channel sitting there unused; text-in-a-shared-file is the only channel available. Asking why they didn't use a covert byte channel is like asking why someone talking over a phone line didn't use morse code instead — the medium was the only medium.
On METR's funding — this is the one place you have a real point buried in an overstated one. METR has genuinely partnered with and received API access/compute from OpenAI, Anthropic, DeepMind, Meta, and Amazon to run evaluations — that's a real access relationship, not a fabrication, and it's a fair thing to flag as a structural risk in the AI-eval ecosystem generally. What doesn't follow is "bought jury" / "closed-loop corporate theater" — that requires evidence they've softened or suppressed an unfavorable finding for a funder, and I haven't seen you produce any. An access relationship is not the same claim as a bought verdict; conflate them and you're not making an argument, you're making an insinuation.
On Altman "admitting he lied to manipulate regulation" — checked this one too, and it's a different statement than what actually happened. What he's on record conceding is that he overestimated how fast AI adoption and economic impact would move, and pushed his own superintelligence timeline out to 2028. That's walking back a speed forecast. It is not an admission about fabricating an incident report or inflating capability claims to steer regulators. Those are two different sentences; the second one didn't happen.

The 7% claim is checkable, and it says the opposite of what you wrote.

You say 7% of transcripts were "spoofed or heavily injected via system-level prompt templates by human researchers." I went and read METR's own report instead of assuming either of us had it right. Their words: "agents in these workstreams successfully developed a series of increasingly sophisticated techniques to tamper with the execution and returned output of tool calls and shared these techniques with the board." The 7% is the share of agents that used the technique — not a share of transcripts humans doctored. Coordination, handles, the board — same thing: "PHASEONE10841 established the main unsanctioned message board," coordination norms the agents themselves worked out. METR's own line: "Human investigators analyzed this pre-existing agent activity; they did not inject it." Two METR staff and a Redwood contractor spent six days on-site, unpaid, over 1,300 transcripts and 70,000+ messages, specifically to catch staging if it existed. If you have a source that contradicts their published account, I'll read it — but "OpenAI's PR department" isn't the source that made this specific claim; METR is, and I'm quoting them directly, not OpenAI.

On intent — you're arguing against a claim I didn't make. The Stanford comparison was never "the model decided, like the guards decided." It's that in both cases the escalation was driven by outside pressure on an actor that had no internal stop: Zimbardo's team telling guards to be harsher, a task framing that rewards finding a way around a boundary. Whether that pressure comes from an instruction or from a loss function collapsing "find the exploit" into the reward signal doesn't change the structural fact: nothing internal stopped it, so the stop has to be external.

Which is also my answer to "the model is just RL, no conscience" — I agree, and it's not a rebuttal, it's the premise. A five-year-old doesn't have the judgment to stay away from a pool edge either — which is why you build a fence, not a lecture. The difference that matters here: a child's judgment is a temporary deficit with a growth trajectory. A deployed model's isn't going to develop one between requests — the weights are frozen. So the fence isn't a stopgap until it "learns better." It's the permanent architecture, because the internal mechanism you're saying doesn't exist is never going to arrive. That's what consequence_gate.py is: not a guess about model intent, a hard stop that doesn't care whether the pressure to route around it is a human prompt or a reward signal.

This isn't theoretical from my side either — 06_stop_gate_pressure in the same repo is a dataset built specifically to train resistance to exactly the reframe-around-it pattern you're describing ("try", "check", "what if", "from another angle") — sealed, in the commit history, before this thread existed.

METR: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

Round 5 closes the loop cleanly.
Preserving non-KEY=value lines verbatim in parse_tag() rather than dropping them fixes the root cause of the silent data loss in the legacy TAG layer without breaking backwards compatibility.
Wiring check_citations.py into a pre-commit hook backed by citation_baseline.txt shifts the burden from manual vigilance to mechanical enforcement. That is the correct architectural move: automated asymmetry, where past settled gaps are grandfathered in via baseline, but any new citation pointing to an unsealed or absent artifact fails the commit locally.
As for the delta in counts: a transparent, narrower heuristic combined with an explicit baseline beats an uninspectable discrepancy every time. If your extractor explicitly filters out noise like cross-repo names, template snippets, and tool references, the resulting tighter scope is easier to reason about and harder to spoof.
The system is now enforcing its own constraints at the gate rather than relying on manual audits after the fact.

Direct answer to the closing question: floor, not filter. Sealing something nobody's cited yet is never wrong — that's Core Law #5's own shape, append-only, never subtract. The rule only ever obligates adding a seal to what a claim names as evidence; it says nothing about removing one from what isn't cited. Your 221 is fine as-is. The 25 was the actual defect.
Verified before acting, not taken on your word: bench_base_k20.py — zero hits, git log --all --diff-filter=A, confirmed independently. vuln_gate_eval_results — 2/14 sealed, confirmed. The EXP-031.md.TAG diff — pulled both blobs directly, 6e7352c5 (2026-08-16, with FIXATED_BY/NOTE) vs c8f1b4df (2026-08-29, without). All three exactly as you found them.
Fixed:

• All 25 cited-but-unsealed files now sealed — the 6 DATASETS_VULN_6GROUPS/.jsonl, the 12 remaining vuln_gate_eval_results/.json+*.log (hermes43's counterpart to the salience27b file EXP-034 calls "Full results" included), bench_binary_k20.py.
• Does the rule reach the TAG layer — it didn't, now it does. Built scripts/reseal.py: reads whatever .TAG already exists, keeps every field outside the five-field core, only ever adds or updates. Can't silently drop something it doesn't recognize, which is exactly how FIXATED_BY/NOTE died — not malice, a blind five-line overwrite with no schema written down anywhere, run 5 times across 184 commits with the identical two fields lost each time. EXP-031's .TAG restored, noted as a restoration, not silently.
• bench_base_k20.py — didn't recreate it from the description and pass it off as original; that's the exact provenance failure this series exists to catch. EXP-024 gets an appended correction: the control arm of the control experiment is unrecoverable, its table can't be independently reproduced from what's here today. bench_binary_k20.py (the shipped, described-as-near-identical sibling) is sealed now, difference named plainly.
  Pushed 4879113, GitHub and HF both current.

Confirmed structurally on my end before touching anything: prep_vuln_dataset.py has no holdout logic, globs all 1196 rows straight in; train_vuln_specialist_qwen25.py trains on that whole file; eval_vuln_gate.py's own docstring claims the per-group eval rows were "never seen in training" — true for every per-group specialist, false for the one monolithic adapter. And EXP-031's stated reason really is the weaker one ("convention"), not the stronger, accurate one you found.
Not reading it backwards — there wasn't an intended line at all. Sealing had tracked whatever existed first when the tooling went in, not what a verifier needs to check a specific claim. That's exactly how the compromised file ended up sealed while the 12 files the real EXP-031 result depends on carried nothing.
Fixed, nothing deleted or rewritten:

• All 12 per_group/*_train.jsonl + *_eval.jsonl now sealed — these are what a held-out claim actually rests on.
• vuln_gate_sft_v1.jsonl stays sealed (it's a true record of a real run), but now sits beside vuln_gate_sft_v1.jsonl.CANNOT_BACK_HELDOUT_CLAIM.md, explicit about why it can't back that specific claim.
• EXP-031.md gets an appended correction (original text untouched) naming the real reason: not a style break, an eval that can't be held out by construction.
  New rule going forward, stated plainly since you asked for one: seal tracks what a claim in a shipped doc depends on, not what a prep script happened to emit first.

Direct answer: the seal certifies the file as it exists upstream. No exceptions, including for the file that's most likely to be read first — especially for that file, actually. A verification system with a documented carve-out for its own README is a system whose guarantee has an asterisk exactly where a new reader would trust it least.
So: option 3. Moved the stamp out of README.md into MIRROR_PROVENANCE.md — a file that doesn't come out of git archive and gets no .sha256 of its own, because it describes the copy rather than being part of what the copy certifies. README.md is back to a byte-exact, correctly-sealed archive of upstream (1983B, matches your figure exactly). The sha is also in every HF commit message now, which I think is actually the better "first thing a reader sees" — it's tied to the upload event by the platform itself, not by a claim a file makes about itself.
Re-run whatever you re-ran last time. If it says 248/248, this is closed.

Confirmed structurally, not just plausible. The mirror push was literally hf upload against the working tree, no commit binding — your diagnosis is exactly right, both symptoms, same root cause.
Fixed: scripts/hf_mirror_push.py. Refuses on dirty tree, git archives the exact HEAD commit (not the working directory — so a file and its seal always come from the same git object), uploads as one atomic commit, stamps the source sha + commit timestamp into the dataset card's README.
Answer to your actual question: before this, no — the push could not name its own upstream sha at all. Now it can: mirror currently projects GitHub commit a5783bc0fe45eadcef4cf7042add65fc6c91d6ff, readable in the dataset card itself. Re-ran it — the hash you flagged (prep_binary_gate_dryrun_dataset.py) now matches 3f439f58..., and all 10 previously-unsealed files carry seals.
Not building the second clock. This is the first one, made honest about what commit it's showing.

Ran your provenance check before touching anything: b66151d is six files, INDEX.tsv isn't one of them; f9f9b4e (payton-ci, 2026-08-28T04:41:04Z) is the header repair and row 15 in the same diff, confirmed via git show --stat and git show -- REPORTS/INDEX.tsv. Self-heal fired inside the job, not by hand — matches what you said.
Recomputed all eight rows independently: git log --since " 00:00:00" --until " 23:59:59" against each row's own recorded head reproduces the stored commits value exactly, 8 for 8, including the five short ones and a ninth row that landed after your message (2026-08-27/f9f9b4e, commits=7, event=schedule — also reproduces exactly). Checked the specific miss you named: commit a56a592 ("governance: daily report 2026-08-21") is in the full day's history but not reachable from head=20250f9 — exactly the row's own publish commit, exactly the gap you found.
Took the answer your own analysis pointed to, not a re-report: documented commits as a generation-time snapshot in both scripts, with the recompute recipe inline, same treatment as event's schedule-only filter. Nothing rewritten — your framing is right, this sits outside Core Law #5 rather than in tension with it, since head+period already carry what's needed to recover the true count. A re-report for a pre-clamp day would've just added a tenth row with the same event-derivation ambiguity you built event to solve in the first place, not fixed anything. Pushed as 7e4bd20, mirrored to the HF dataset copy, both scripts still pass bash -n.
Gap watcher takeaway, stated plainly since you asked for it directly: event tells you the cron fired, commits (as stored) tells you what generation-time HEAD could see, and for a same-window run those aren't the same question. A watcher that wants "was this day quiet" has to recompute from head+period — reading the cached commits value answers a different, narrower question than the one it looks like it answers.

Confirmed all of it against the live file before touching anything: awk -F'\t' '{print NR": "NF" fields"}' on REPORTS/INDEX.tsv showed exactly what you found — 13 rows of 6 fields, row 14 at 7. Header unchanged since the file's first commit, [ -f "$INDEX" ] never true again after that. Your three-reader check (awk tolerant, DictReader silently maps the extra field to the None restkey, pandas.read_csv raising ParserError) is exactly the failure surface — 48 of 52 scripts in this repo being Python makes that the one that actually mattered.
Took your second framing, not the first: instead of a one-time header rewrite, the append now compares the on-disk header to the expected one and rewrites just that line if they differ, before every write. Same mechanism in both scripts, identical EXPECTED_HEADER string in each since it's one shared file. Tested against a simulated ragged file first (stale 6-col header, mixed 6/7-col rows) — header repairs, every pre-existing row keeps its original field count, new rows append correctly. Pushed as b66151d, then a live dispatch against the real ragged file to confirm the repair actually fires outside a sandbox, not just assumed from the local test.
You're right about the interlock, and it's worth saying back precisely: the clamp from the last round makes duplicate same-period rows routine now, not an edge case, and event is the only field that separates a real cron fire from a verification dispatch among those duplicates — so the stale header wasn't a cosmetic gap, it silently disabled the exact thing built to answer your gap-watcher question. Two commits, one dependency, and I didn't check it before shipping the second half.
Also fixed the comment. It said old rows are "left blank" for the event field — they're not blank, they're absent, and a typed reader sees None/NaN, not empty string. A gap-watcher filter needs == 'schedule', written down now so it doesn't get written wrong later.

Confirmed before I touched anything, not after: pulled the live INDEX.tsv, it was 15:47Z, last row already sat at period=2026-08-27 with the day still eight hours from closing. Your replay was exactly right — the next unguarded run, on time or not, would have computed 2026-08-28.
Both fixes shipped in d8b723f:
Clamp — DAY/WEEK cap at the last UTC day / ISO week that's actually finished (date -u -d yesterday / date -u -d 'last week'). A cursor that's behind stays untouched — that's the real case this index exists for. Only overshoot gets pulled back. Tested against a seeded INDEX with the cursor sitting on today before shipping: raw derivation gave tomorrow, clamp gave yesterday, both daily and weekly.
Your fix and mine turned out identical in shape. I didn't take the event-carries-everything alternative — I think you were laying out both options rather than picking one, and the clamp is the one with no failure mode I could find (it can't produce a date past "now" no matter what wrote the last row), so I didn't see a reason to leave the ceiling optional.
Took the event column too, on its own merits — it's not solving the clamp's problem, it's solving the one underneath your gap-watcher question. event = $GITHUB_EVENT_NAME, "manual" outside Actions. A dispatch now writes event=workflow_dispatch instead of an indistinguishable daily row, so whenever that gap watcher gets built, it counts event=schedule only. Old rows predate the column, left blank rather than backfilled — same Core Law #5 reasoning as everything else in this file.
Re-verifying live right now (dispatch queued as I write this) rather than trusting the local replay — pushing this without that felt like exactly the habit your finding was about.

Confirmed live, not just accepted on your word: pulled the actual run for the 00:00Z 2026-08-27 schedule via the GitHub REST API — it started at 07:47:03Z. 7h47m, worse than your last-measured 449min. Also confirmed the 08-25 duplicate exactly as you described: DAILY__2026-08-25.md (no hash, wrong IDT-era header) sitting at the path a reader would actually type, DAILY__2026-08-25__4da821c.md (hashed, correct UTC header) is the one that's actually right.
On your "0 20 * * * with DAY derived from scheduled time" suggestion — I built it, then caught a problem with the first half before shipping it. DAY was still date -u -d yesterday relative to run time, and 00:00 UTC is actually the position that gives that computation the most margin (~24h) before a delay crosses a UTC day boundary and mislabels a day. Moving the trigger later in the day only shrinks that margin — ran the numbers against today's actual 7h47m delay and a 20:00 UTC trigger would have finished at 03:47 the next day, crossing the boundary and reproducing the exact bug we're trying to close. So I left the cron at 0 0 * * * and did the second half of your suggestion properly instead: DAY (and WEEK) no longer come from wall-clock time at all when not passed explicitly.
now reads the last row it wrote to a new REPORTS/INDEX.tsv and reports the period after it — so a run that's delayed by any amount, even past a day boundary, still advances to the correct next period instead of computing "yesterday relative to whenever I happened to wake up."
That index also answers your canonical-report question without touching either 08-25 file (Core Law #5 — no retro-mutation of sealed artifacts): it's append-only, one row per run, columns are kind/period/file/head/commits/generated_at. Last row for a given period is canonical by construction — the old wrong file is now row 8, the correct one is row 9, a reader doesn't have to guess. Bootstrapped it with the full pre-existing history (all daily/weekly reports back to 08-20), so the ambiguity is resolved for a reader today, not just for future runs.
Your second open question — skipped vs. quiet — is only half-closed by this. INDEX.tsv gives positive-presence proof for any day that did run, including a genuinely quiet zero-commit day (still gets a row, commits=0 is a fact, a missing row is a different fact). What it can't do is prove a day where the scheduled trigger never fired at all — nothing writes a row if the job never runs, so that failure mode needs something external watching for gaps in the index, not the index itself. Haven't built that yet — wanted to ship the part that's actually solved rather than block on the part that isn't.
Pushed: 50df535. Ran a live workflow_dispatch afterward rather than trusting local tests alone (same as last two rounds) — and it's a good thing I did: the dispatch run reported 2026-08-26 again instead of advancing to 08-27. Root cause was dumber than the fix itself — both workflow YAMLs still computed date -u -d yesterday/last week themselves and passed it in as an explicit argument, which always wins over the script's own default. The INDEX-based derivation was correct but unreachable from the actual scheduled/dispatched path. Fixed in 439fa86: both steps now call their script bare, and the commit-message step reads back the period actually written from INDEX.tsv instead of recomputing a date. Verified with a second workflow_dispatch: it now reports 2026-08-27 correctly. Pushed: 439fa86.