← All writing

Build log

My resume can't ship a claim my evidence doesn't clear

Aug 14, 2026

An AI drafts my public materials, so the public/private line can't live in anyone's memory. It's a machine-checked property of the file bytes — and the check already caught drift on my live site.

My resume is built by AI in two lanes from one claim library, and a fail-closed checker refuses any build that carries a claim past its disclosure rank.

That gate exists because the drafting is AI's job now. The library behind the resume holds 214 claim and lead cards, and a disclosure boundary that lives in memory is already broken — you just haven't found the leak yet.

Why does a resume need a disclosure gate?

Because two versions of the same document go to two very different audiences. The direct lane produces the file I hand to one specific employer; it may carry RESUME-ONLY material — outcomes I'll discuss in an application but won't post publicly. The web lane produces the copy anyone on the internet can download, and it is restricted to claims ranked PUBLIC or PUBLIC-SANITIZED (a bounded, pre-approved generalized form of a private claim).

Every card in the library carries one of five disclosure ranks: PUBLIC, PUBLIC-SANITIZED, RESUME-ONLY, PRIVATE, DO-NOT-USE. Both lanes build from the same library, so the dangerous failure is quiet reuse: a sentence that was fine in a direct application PDF getting rebuilt, untouched, into the public web version. I've already watched private context leak into a public surface once. A resume is the highest-stakes version of that leak I own.

Once an AI does the drafting, "I would never publish that" stops being a fact about me. It has to become a checkable property of the artifact.

What does the fail-closed checker verify?

_check-resume-artifacts.py is fail-closed: anything it cannot positively prove safe is a failure, not a skip. On every bundle it:

• maps every visible paragraph in the document to stable claim IDs. An unmapped paragraph fails the run.
• computes each paragraph's rank as the strictest rank among the claims it cites, then fails the web lane on anything above PUBLIC-SANITIZED.
• verifies exact hash chains (SHA-256 fingerprints of each file; change one byte and the fingerprint changes) from the claim library through a frozen snapshot and manifest to the shipped DOCX and PDF bytes.
• compares ordered text tokens between the DOCX and the PDF, so the two formats must say the same words in the same order across exactly two pages.
• checks every link against an allowlist of exactly four approved URLs, and scans for phone-number and personal-email shapes. The web lane must contain zero, and the scan covers the raw document internals, not just the visible text. The direct lane must contain exactly one contact phone in its visible text.
• pins the PDF metadata, including a creation date fixed to a date in 2000, so builds are deterministic (the same inputs always produce byte-identical output).
• rerenders the PDF to page images at 144 dpi and compares their hashes against a signed visual-QA receipt (reviewer_class: MODEL-VISUAL-REVIEW). The AI reviewer's sign-off is bound to the exact bytes it reviewed, and the checker rerenders independently rather than trusting the stored images.

One gate is hard-coded on top of all that: the build manifest must record publication approval as false. The bundle structurally cannot claim it is cleared for the public web. Publishing is a separate human action, the same discipline as this site's own exact-byte publish gate.

None of this is glamorous. That's deliberate. The glamorous alternative — an AI assuring me it "kept the private parts private" — is the least trustworthy sentence in the whole pipeline.

Did it actually catch anything?

Yes, on the live site, on 2026-08-09. A read-only audit compared the published web resume PDF against the current bundle and found the live file was a stale version: v5 on the web while v5.1 sat locally as the prepared candidate. The stale file carried disclosure drift: outcome claims tied to a former employer, ranked RESUME-ONLY under current policy, were sitting on the public internet. Details generalized to protect the people and organizations involved.

That was my system's own failure, and I'll say so plainly. The policy had tightened, the checker guarded every new build, and nothing re-checked what was already published. A gate that inspects new artifacts while old ones rot on the web is half a gate.

What I trust is what happened next: nothing silent. The pointer file _current.json now records the live lane as PUBLISHED-WITH-DISCLOSURE-DRIFT, a named honest state, with the corrected candidate held at PREPARED-NOT-PUBLISHED. The fix stays blocked until a human approves the exact site change. The drift is a fact in the record, not a memory in my head.

This is the same shape as everything else in how I know my AI is right: the boundary is a property of the artifact, the failure has a name, and a green result means something specific.

So the question I'd put to you: if an AI drafts anything that ships under your name — a resume, a bio, a proposal — where does your public/private line actually live? And if a stale copy of last year's version is still sitting on some public surface right now, what would tell you?

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{ali2026resumegate,
  author = {Ali},
  title  = {My resume can't ship a claim my evidence doesn't clear},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/resume-disclosure-gate/}
}

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