← All writing

Guide

Can my AI publish to this site without my approval? Not one byte

Aug 14, 2026

Article releases on this site run through a tool that refuses to stage a file unless the fresh review and my approval name its exact bytes.

No. The release tool for this site refuses to stage a page unless the review record and my written approval both name the exact bytes being shipped.

An approval that cannot say what it approved is theater. Most pipelines run on that theater: a human nods at a summary or a filename, and the artifact keeps changing after the nod.

One disclosure before the mechanism, because this is a page about approvals: the gate below is built for one article at a time, and the page you are reading shipped in a batch release under a different, recorded authorization — my explicit written directive, logged in the site's approval records with the hash of every file in the batch. The gate is the standing path; the batch was the exception, and I'd rather show you the exception than pretend it didn't happen.

What did my approval actually approve?

In most setups, nobody can answer. The approval points at a name, and the name points at whatever the file happens to contain right now.

The verified incident row behind this story states the failure plainly: local draft state and partial checks could turn stale or mismatched files green. Checks passed. Files kept moving. Nothing in the path could prove that the thing the checks blessed and the thing that shipped were the same thing.

That is the hole. An approval bound to a filename approves whatever that filename holds later. An approval bound to a chat message approves a memory. Neither survives one edit.

The fix is boring and total: identify the artifact by its bytes. This site uses SHA-256, a fingerprint computed from a file's exact contents (change any single byte and the fingerprint changes completely). "Approved" here means these hashes, at these target paths, and nothing else.

How do the gates bind to the exact bytes?

Every record after the draft must carry the same binding block, and the release tool recomputes everything before a file is staged (written into the site's source folder). The block names a target path and a SHA-256 for each of the three files that ship together: the article, its proof page, and the proof data.

The order matters. A finished draft is marked voice-locked. Gate 1 is a mechanical checker, _check-content-ready.py, which must not only exit clean but print its RESULT: clean sentinel; a zero exit code alone is not trusted. Gate 2 is a fresh adversarial review, meaning a separate session that deliberately tries to break the piece's claims rather than confirm them. Its record must confirm the reviewer did not draft or edit the candidate, list the sources it actually opened, report BLOCKERS: none, and end VERDICT: PUBLISH-READY. "Fresh" is enforced, not requested: the record's recorded hashes must match the current bytes at validation time.

The hashes cover the staged public bytes, not my local draft. The release module strips the private workflow keys from the frontmatter (twelve on an article) and normalizes line endings before hashing, so it fingerprints exactly what will go live. It binds the Markdown and data sources being staged, not the HTML built later. Flip a private status field and the hash holds, because that byte never ships. Change one public character and every record downstream goes stale.

My approval record carries DECISION: PUBLISH, APPROVED_BY: Ali, the same binding block, and one more hash: a SHA-256 of the Gate 2 review file itself. If anyone touches the review after I sign, my approval dies with it.

What happens when one byte changes after approval?

Refusal, with the reason spelled out. The tool exits nonzero with [promote] REFUSED: and a STALE line naming both the recorded hash and the current one. The only way forward is a fresh Gate 2 and a fresh approval on the new bytes. Records written under the older, weaker hash format refuse the same way, with the same instruction: run a fresh review, obtain a fresh approval.

The refusals go further than staleness. A dirty site checkout refuses. A checkout that is not exactly at the site repo's origin/main commit refuses. A variant file, rather than the single chosen final draft, refuses. A target that already belongs to a different page refuses. Even the final write double-checks itself: bytes land in a temporary file, get hashed against the approved value before anything is replaced, get hashed again after, and a partial failure rolls all three files back.

Two honest limits. The tool never commits or pushes; a human does that, on purpose, after reviewing the diff. And a hash cannot tell you whether the words are true. It can only guarantee that the words the reviewer read, the words I approved, and the words you got are the same words. Truth is what the rest of the verification system is for, and the standards this site publishes under say what I owe you when it fails.

If your AI ships anything (code, posts, invoices), pull up the last approval in that pipeline and ask what it names. If someone edited the artifact one minute after the yes, would anything in your setup refuse?

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

@online{ali2026exactbyte,
  author = {Ali},
  title  = {Can my AI publish to this site without my approval? Not one byte},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/exact-byte-publish-gate/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.