A regulator does not ask whether your moderation model is accurate. They ask why a specific piece of content was actioned on a specific date — and then they want the record. If your trust team can only produce a model-accuracy slide deck, you have answered a question nobody asked and failed the one they did. This is the gap that catches platforms off guard. The deployment review went well: the model hits its precision and recall targets, the false-positive rate is bounded, the dashboards are green. Then an inquiry lands referencing one removed post, one suspended account, one appeal that was rejected — and the question is not “is your system good on average” but “show me how this decision was made.” Per-model evidence cannot answer a per-decision question. The audit-evidence pack is the artefact that can. What a Content-Moderation Audit-Evidence Pack Contains The pack is a defined, repeatable document structure — not a one-off export assembled under deadline pressure. Its purpose is to make any single moderation decision reconstructable by someone who was not in the room when it was made. In our experience, an inquiry that arrives without this artefact already in place forces the trust team to reverse-engineer a decision from raw logs, which is exactly the work that turns a days-long response into a weeks-long one. A complete pack covers six sections. Each answers a question an external reviewer will eventually ask. Section What it captures Question it answers Policy mapping The platform policy clause the decision enforces, versioned “Under which rule was this actioned?” Policy-to-prompt mapping How the policy clause is expressed to the model (prompt, classifier label, threshold) “How does your AI know what the policy means?” Model-version pinning The exact model version and config in force at decision time “Which system made this call?” Decision record Input, model output, confidence, and the action taken “What did the system actually decide?” Reviewer adjudication trail Whether a human reviewed, who, what they changed, and why “Was a person involved, and what did they do?” Escalation and appeal evidence Escalation triggers fired, appeal lodged, outcome “What happened after the first decision?” The discipline that makes this work is that the structure is fixed in advance. A reviewer reading two different decisions from two different years should find the same six sections in the same order, populated from the same fields. That invariance is what lets the trust team respond to an inquiry by retrieving rather than reconstructing. How Policy-to-Prompt-to-Decision Mapping Is Captured The hardest section to get right — and the one regulators increasingly probe — is the chain from written policy to model behaviour. A platform’s community guidelines are prose written by a policy team. The model operates on prompts, classifier labels, or threshold scores. The audit-evidence pack has to make the translation between those two layers explicit and traceable per decision. The mechanism that holds this together is treating the policy-to-prompt mapping as a versioned artefact in its own right. When policy clause 4.2 (“graphic violence in a newsworthy context is permitted with a warning interstitial”) is operationalised, the mapping records which prompt phrasing, which classifier label, and which confidence threshold implement it — and pins a version to that mapping. Each decision record then references the mapping version that was live when the decision fired. This is the same provenance discipline we describe for audit-grade evidence in regulated AI workflows: the claim is only defensible if the path from rule to action is reconstructable after the fact. Without this, a platform can show a regulator a current prompt and a removed post, but cannot prove the prompt that actioned the post was the one in force at the time. That gap is where defensibility collapses. A decision made under mapping version 7 cannot be defended with mapping version 9, even if version 9 is better. This is the per-decision principle stated precisely: the pack pins the world as it was when the decision was made, not as it is now. What Per-Decision Evidence an External Reviewer Expects External reviewers — whether a regulator under the EU Digital Services Act, an outside counsel, or an independent auditor — read for a specific property: can this single decision be explained end to end, by the artefact alone, without a meeting? The standard is reconstruction, not justification. They are not asking whether the decision was correct; they are asking whether you can show how it was reached. In practice the reviewer expects to trace a clean line: input content → policy clause invoked → mapping version that translated it → model version and output → human adjudication (or a recorded reason none was required) → action → any escalation or appeal. The single per-decision record is the unit they read first; the pack is the structure that guarantees every such record carries the same fields. When the adjudication trail shows a human reviewer overrode the model, the reviewer wants the recorded rationale — not because the override was wrong, but because an unexplained override is indistinguishable from an arbitrary one. This is also the cleanest place to state the operational boundary the pack is built around. It documents operational moderation workflow — policy enforcement decisions on content. It is not a vehicle for political-speech adjudication framings, and it does not track or profile user behaviour. The artefact answers “how was this content decision made,” and stops there. We treat that scope as a hard line, re-verified for every decision type the pack covers. How the Pack Survives Policy Changes Without Being Rewritten Platforms change policy constantly. A naive evidence approach ties the audit format to the current policy, so every policy revision invalidates the documentation and the trust team rebuilds from scratch. That is the failure mode worth naming: a pack that has to be rewritten whenever policy moves is a pack that will be out of date the moment an inquiry references an older decision. The pack survives policy churn because its structure is invariant while its contents are versioned. The six sections never change. What changes is the policy version, the mapping version, and the model version recorded inside a given decision record. A decision from 2024 is reconstructed using the policy and mapping versions that were live in 2024 — both of which the pack pins — even though both have since been superseded. The structure is the constant; the version pins are the variables. This is what lets the policy team point at something durable when the alignment between policy and AI behaviour is challenged. The mapping is not a snapshot of today’s intent; it is a versioned record of intent over time. Pipelines without this property re-litigate the policy-AI alignment question from first principles on every inquiry, which is observably slower and more error-prone (an observed pattern across regulated-workflow engagements, not a benchmarked figure). The whole point of fixing the format once is that you never pay the reconstruction cost again. The engineering reliability of the triage pipeline itself — uptime, throughput, queue behaviour, model-drift monitoring — is a separate artefact concern, covered in our work on content-moderation workflow reliability. The reliability pack answers “is the pipeline trustworthy as a system”; the audit-evidence pack answers “is a single decision defensible.” A platform’s trust team needs both, and they should not be conflated. For the broader picture of how policy becomes an AI-assisted decision in the first place, see how content moderation works in practice. This work sits within our broader practice on AI governance and trust, where the recurring theme is that defensibility is a property of the artefact, not the model. FAQ What does a content-moderation audit-evidence pack contain section by section? Six sections: policy mapping (the versioned clause enforced), policy-to-prompt mapping (how the clause is expressed to the model), model-version pinning (the exact version live at decision time), the decision record (input, output, confidence, action), the reviewer adjudication trail (who reviewed and what they changed), and escalation/appeal evidence. The sections are fixed in advance so any two decisions read the same way. How is policy-to-prompt-to-decision mapping captured as a regulator-facing artefact? The mapping is a versioned artefact recording which prompt phrasing, classifier label, and threshold implement a given policy clause. Each decision record references the mapping version that was live when the decision fired. A decision made under one mapping version cannot be defended with a later version, even a better one — the pack pins the world as it was at decision time. What per-decision evidence does an external reviewer expect to see? A clean, reconstructable line from input content through the policy clause invoked, the mapping version, the model version and output, human adjudication (or a recorded reason none was required), the action, and any escalation or appeal. The standard is reconstruction without a meeting, not justification — the reviewer asks how the decision was reached, not whether it was correct. How does the pack survive policy changes without being rewritten? The six-section structure is invariant; the contents are versioned. A decision from an earlier year is reconstructed using the policy and mapping versions that were live then — both of which the pack pins — even after they are superseded. Because the format is fixed once, a policy revision never invalidates older evidence. How does this CCU’s artefacts relate to the engineering reliability artefacts? They answer different questions. The reliability artefact covers whether the triage pipeline is trustworthy as a system — uptime, throughput, drift monitoring — while the audit-evidence pack covers whether a single decision is defensible per-decision. A trust team needs both and should not conflate them. Where does the audit-evidence pack end and a regulatory submission begin? The pack is the platform’s internal, repeatable artefact that makes any decision reconstructable on demand. A regulatory submission is a jurisdiction-specific packaging of evidence drawn from the pack to meet a particular regime’s filing requirements. The pack is the durable source; the submission is a formatted extract for a named regulator. How does the EU Digital Services Act’s obligations on Very Large Online Platforms shape what the pack must contain? DSA obligations on VLOPs and VLOSEs push the pack toward per-decision traceability and clear records of human involvement, since regulators can probe individual moderation actions and expect the reasoning behind them. That maps directly onto the decision record, the adjudication trail, and the escalation/appeal section — the pack is structured so those obligations are answered by retrieval rather than reconstruction. How does the pack accommodate jurisdiction-specific regimes without rewriting the core artefact? The same versioned, six-section structure serves multiple regimes because the core artefact captures the decision provenance, not a single jurisdiction’s filing format. A DSA inquiry and an Online Safety Act inquiry both read from the same per-decision records; what differs is the submission packaging built on top, not the underlying evidence structure. Where This Leaves a Trust Team The question worth carrying into the next deployment review is not “is our moderation model accurate enough to defend.” It is “if a regulator names one decision from eighteen months ago, can we reconstruct it from an artefact, or will we be reading raw logs under a deadline.” The model accuracy is the easy part. The pack — versioned, invariant, per-decision — is what determines whether the answer takes days or weeks. The supporting artefact here is SVC-TRUSTPACK in its content-moderation lens, scoped to operational moderation workflow. If your pipeline can defend a model but not a decision, that gap is the failure class this artefact exists to close.
