An auditor sits down with a single published module and one question: prove it. Prove every regulated claim traces to an approved source. Prove a blind employee can complete it. Prove nobody quietly edited a signed-off screen after approval. She has no special access, just the published course and whatever records the team left behind. In the good case, she reconstructs the entire history in an afternoon, from raw SOP to the screen a learner saw, and signs her name to the finding. In the bad case, she finds a polished module, a verbal "the SME looked at it," and no way to tell what changed after sign-off. Same course. The difference is whether the team built two artifacts on purpose: a conformance report and a tamper-evident provenance trail. This lesson builds both.

The Auditor Test

The discipline of this lesson is a thought experiment you should run on every course you ship: can an auditor who was not in the room reconstruct, from the raw source to the published module, exactly what happened and who is accountable for each step. Not "did we do good work." Whether the work left a trail that survives the team leaving, the memory fading, and the tool changing. Two artifacts pass the auditor test, and almost nothing else does.

The first is the accessibility conformance report: a structured, evidence-backed statement of how the module measures against the accessibility standard, criterion by criterion. The second is the provenance trail: a tamper-evident record of where every load-bearing claim came from, who verified it, and what changed after sign-off. Provenance means the documented origin and chain of custody of a claim, from source document to the learner's screen. Tamper-evident means that if someone alters an approved record, the alteration is detectable rather than silent. Why you care: a verbal assurance and a clean-looking module are not evidence; an auditor cannot sign off on a memory, and neither can you when the question comes back two years later.

An auditor cannot reconstruct a claim from a confident module and a verbal "the SME looked at it." Build the two artifacts that let a stranger rebuild the history without you in the room.

The Conformance Report: WCAG, VPAT, and ACR

Accessibility is a gate, not a polish step, and the artifact that proves you cleared the gate is the conformance report. Start with the standard. WCAG 2.2 AA is the Web Content Accessibility Guidelines, version 2.2, level AA, the W3C Recommendation finalized 5 October 2023 and the conformance target this program holds. In the United States, Section 508 incorporates WCAG by reference for federal and federally funded content, and the legally incorporated version lags the latest WCAG, so you check which version your obligation actually names. WCAG is organized under four principles, easy to remember as POUR: content must be perceivable, operable, understandable, and robust.

The report itself usually takes the form of a VPAT, the Voluntary Product Accessibility Template, which when filled in produces an ACR, the Accessibility Conformance Report. The distinction matters and people blur it: the VPAT is the blank template, the ACR is your completed, evidence-backed claim against it. The ACR walks each applicable success criterion and records a conformance level (Supports, Partially Supports, Does Not Support, or Not Applicable) with a plain-language explanation and the evidence behind it. An ACR that says "Supports" with no explanation is not evidence; it is an assertion, and an auditor treats an unexplained "Supports" as a red flag, not a green light.

The AI-Specific Failure Modes

AI-generated media introduces failure modes a conformance report has to hunt for specifically, because the tool will happily produce confident output that fails. An AI-narrated video ships without captions or with auto-captions that mis-transcribe a regulated term. An AI-generated diagram encodes meaning in color alone, failing learners with color vision deficiency. AI alt text describes the wrong thing, or describes a decorative image at length while saying nothing useful about a load-bearing chart. An AI avatar's lip-sync drifts and the transcript does not match the audio. An adaptive path traps a keyboard-only learner in a component they cannot exit. None of these announce themselves; the module looks finished. The ACR is where you prove you checked for each, with evidence, rather than assuming the tool got it right.

The Provenance Trail

The conformance report answers "can everyone use it." The provenance trail answers "where did this come from and who stands behind it." For every load-bearing claim, threshold, procedure step, and regulated statement, the trail records four things: the source (the exact approved document and line), the transformation (that AI drafted it, grounded on that source), the verifier (the named human, usually an SME, who confirmed it against the source), and the sign-off (the approval, with a timestamp). A claim with all four is reconstructable. A claim missing any one is a hole the auditor will fall into.

The word that earns its place is tamper-evident. A trail you can silently edit after sign-off proves nothing, because the auditor cannot tell whether the record reflects what was approved or what someone changed afterward. Tamper-evidence does not require exotic technology. A version-controlled log where every entry is timestamped, attributed, and append-only (you add a correction as a new entry rather than overwriting the old one) makes any change visible. A content hash recorded at sign-off lets anyone confirm the approved screen and the published screen are byte-for-byte the same. The principle is simple: an approved record should be impossible to alter without leaving a mark. That is what separates a trail from a story.

A provenance trail you can edit without a trace is a diary, not evidence. Tamper-evidence is the difference between "trust me" and "check for yourself."

Reconstructing a Claim, From Raw Source to Published Module

Walk one regulated claim through the trail the way an auditor would, because the test of both artifacts is whether they let a stranger rebuild the path end to end.

The claim is a data-retention threshold in a privacy module: "personal records are deleted after a stated retention period." The auditor starts at the published screen and works backward. Sign-off: the trail shows the screen was approved on a date by a named compliance reviewer. Integrity check: the hash recorded at sign-off matches the published screen, so nothing changed after approval. Verifier: the trail names the SME who confirmed the threshold and the date they did it. Transformation: the entry notes the screen was AI-drafted, grounded on the loaded retention policy, with the method recorded. Source: the entry points to the exact clause and line in the approved policy that states the period, and the auditor opens the policy and confirms it. Five backward steps, and the auditor has reconstructed the entire life of the claim from the learner's screen to the source clause, without anyone from the team present. She signs her finding. That is what passing the auditor test looks like.

Now the accessibility side of the same module. The auditor opens the ACR. For the AI-narrated explainer, the report records captions present and human-reviewed, transcript matching the audio, and a note that auto-captions were corrected for two regulated terms. For the process diagram, the ACR records a text alternative that conveys the same information color was carrying, with the evidence. For the interactive practice, it records keyboard operability and a tested exit path. Each criterion carries a conformance level and an explanation, not a bare "Supports." The auditor spot-checks three criteria against the live module, finds the evidence holds, and signs. The conformance report did not just claim accessibility; it let her verify it.

A Worked Example: Before and After

A learning team ships an AI-assisted anti-bribery module to 9,000 employees across two builds.

Before (the story). The build is fast and looks excellent. The thresholds came from "the policy, basically," the SME "reviewed it on a call," the captions are whatever the video tool auto-generated, and the alt text is whatever the image tool produced. There is no ACR, just a sense that it is probably fine. Eighteen months later a regulator opens an inquiry and an auditor asks the auditor test: prove the gift-value threshold traces to the approved policy, prove a blind employee could complete the certification, prove the signed screen was not edited afterward. The team cannot. They have a confident module and a memory. The SME who "reviewed it on a call" has left. Nobody can say whether the published threshold matches what the SME saw or what someone changed later. The captions mis-transcribe a key term, and there is no record anyone checked. The module may even be correct, but correct-and-unprovable is indistinguishable from wrong when the auditor cannot reconstruct it.

After (the two artifacts). The same module, built to pass the auditor test on purpose. Every threshold carries a provenance entry: source clause, AI-drafted-and-grounded transformation, named SME verifier, timestamped sign-off, and a content hash. The log is append-only, so a later correction to one threshold appears as a new dated entry, not an invisible overwrite. The ACR walks each criterion: captions human-reviewed with the two corrected terms noted, the diagram's text alternative recorded, the practice's keyboard path tested. Eighteen months later the same regulator inquiry lands on a different team. The auditor reconstructs the gift-value threshold from screen to policy clause in minutes, confirms the hash proves no silent edit, and verifies from the ACR that a blind employee could complete the module. She signs. Same speed of build, opposite outcome, because the team produced evidence a stranger could check instead of a story only they could tell.

The lesson is not that accessibility and provenance are bureaucracy. It is that a module without them is unprovable, and in a regulated context unprovable is a liability whether or not the content was ever wrong.

Building Both Artifacts During the Build

The objection you will hear is that conformance reports and provenance logs are slow, after-the-fact paperwork that drags a fast AI build to a crawl. That objection is true only if you build the artifacts after the fact. Built inline, as a byproduct of the work you are already doing, they cost almost nothing and accrue automatically. The trick is to capture evidence at the moment of the action, not reconstruct it later from memory.

For provenance, capture the entry at the instant a claim is drafted and verified, not at the end of the project. When the AI drafts a threshold grounded on a policy, the grounding already names the source line, so record it then. When the SME confirms it, record the verifier and timestamp then. When the screen is approved, hash it then. By the time the module ships, the provenance trail is complete because each entry was written at the only moment its information was fresh and free. Reconstructing the same trail two weeks later, from memory and chat logs, is the expensive version, and it is also the unreliable one, because memory is exactly what tamper-evidence is meant to replace.

For the conformance report, treat each WCAG 2.2 AA criterion as a build requirement and record the evidence as you satisfy it. When you human-review the captions, note it in the ACR. When you add the diagram's text alternative, record it. When you test the keyboard exit path, log the result. The ACR is then assembled from evidence captured during construction rather than reverse-engineered during a pre-launch scramble. This is the practical meaning of accessibility as a gate rather than a polish step: the evidence is produced by passing the gate, not by inspecting the finished module and hoping.

The inline discipline also changes the economics of a correction. Because the log is append-only and the criteria are tracked per screen, fixing a wrong threshold or a failing component eighteen months later is a small, localized, fully documented change, not a forensic investigation into what the original team did. The artifacts that pass the auditor test are the same artifacts that make your own future maintenance cheap, which is why building them in is not a tax on speed but an investment in it.

The Iron Rule and the Accessibility Gate

Both artifacts are the iron rule made into evidence. AI assists, the human verifies, the human owns the decision, and "the AI wrote it" is never a defense. The provenance trail records exactly who verified and who owns each claim, so the iron rule is not a slogan but a signed, timestamped, tamper-evident fact an auditor can check. The accessibility gate is bright-line and lives in the conformance report: an AI-generated experience that fails WCAG 2.2 AA does not ship, and the ACR is how you prove you cleared the gate rather than hoping you did. Accessibility is not a feature checkbox the vendor ticks for you; the obligation does not transfer to the platform, and an auto-caption the tool generated is your responsibility to verify, not the tool's claim to make.

The deepest point is that these artifacts protect you even when the content was right. A correct claim with no provenance is unprovable, and a usable module with no conformance report is unverifiable, and in front of a regulator or an accessibility auditor, unprovable and unverifiable are functionally the same as wrong. Build the conformance report and the tamper-evident trail not because you expect to be caught out, but because the auditor test is the standard the work is actually held to, and a stranger reconstructing your claim in an afternoon is the proof that you did it right.

Key Takeaways

• The auditor test is the standard: can a stranger reconstruct, from raw source to published module, exactly what happened and who is accountable, without the team in the room.
• Two artifacts pass the test: an accessibility conformance report and a tamper-evident provenance trail; a confident module and a verbal assurance pass nothing.
• WCAG 2.2 AA (W3C Recommendation, October 2023) is the conformance target, organized as POUR (perceivable, operable, understandable, robust); Section 508 incorporates WCAG by reference and its incorporated version can lag the latest WCAG.
• A VPAT is the blank template; an ACR is your completed, evidence-backed conformance claim, and an unexplained "Supports" is a red flag, not evidence.
• AI media fails accessibility in specific ways the ACR must hunt for: mis-transcribed auto-captions, color-only diagrams, wrong or useless alt text, lip-sync and transcript drift, and keyboard traps in adaptive components.
• A provenance entry records source, transformation, verifier, and sign-off; tamper-evidence (append-only logs, timestamps, content hashes) makes any change after approval detectable rather than silent.
• An auditor reconstructs a claim by working backward from the published screen through sign-off, integrity check, verifier, transformation, and source, confirming each against the approved document.
• The artifacts protect you even when the content was right: correct-but-unprovable and usable-but-unverifiable are functionally the same as wrong in front of a regulator or auditor, and the obligation never transfers to the vendor.