A narrative mapping between community guidelines and classifier prompts survives exactly until someone names a date and a decision ID. At that point the only thing that answers the question is a structured, versioned mapping artefact: policy clause identifiers on one side, prompt and threshold revisions on the other, and a decision record that pins which pair was in force when the action fired.

The naive version of this work is familiar. A policy team owns the guidelines document. An ML team owns the prompts, the classifier thresholds, and the escalation rules. Somewhere between them, usually shortly before an audit, a slide appears showing that the two roughly correspond. That slide is a claim about correspondence, not evidence of it — and it is regenerated by hand every time anyone asks.

This piece is about the mapping mechanics only: how the correspondence is represented, versioned, emitted and checked in an operational moderation workflow. It is not about adjudicating political speech, and it is not about tracking individual users’ behaviour.

What does policy-to-prompt-to-decision mapping mean in practice?

It means three things exist as data rather than as prose.

First, every enforceable policy clause carries a stable identifier that is independent of its wording and its position in the document. Second, every executable artefact that enforces a clause — a classifier prompt, a rule, a threshold set, a reviewer guidance snippet — references those identifiers explicitly. Third, every decision record pins the tuple: clause ID, prompt revision, model version, threshold set, reviewer guidance revision as they stood at decision time.

The mapping is then not a document. It is a join, and the regulator-facing artefact is the rendering of that join for a named window of time.

A maintained mapping artefact turns “which policy did this decision enforce?” from a multi-week reconstruction into a single lookup keyed by decision ID. That is the operational payoff, and it is the reason we treat the mapping as pipeline output rather than as documentation.

Why clause identifiers, not clause text?

Because policy text moves. Clauses get reworded for clarity, renumbered when a section is split, merged when two prohibitions turn out to overlap. Any mapping keyed to text or to section numbering breaks silently on the next policy release, and the breakage is invisible until an inquiry lands on a decision from the wrong side of the change.

Stable identifiers are cheap to introduce and hard to retrofit. In our experience the retrofit cost is dominated not by assigning the IDs but by reconciling historical decisions that were logged against section numbers which have since been reused for different prohibitions. Assign the identifiers before the first renumbering, not after.

Practical rules that hold up:

• The identifier is opaque and permanent — POL-HARASS-004, not Section 3.2.
• Rewording a clause creates a new revision of the same identifier, not a new identifier.
• Splitting a clause retires the original and mints two successors, with the retirement recording both successor IDs.
• Merging records the inverse. Retired identifiers are never reissued.

The mapping table: what a regulator-facing rendering contains

The mapping section of an audit-evidence pack is a table, and it is the section trust and policy teams ask to see first when scoping regulator-readiness work. Each row is one enforcement path, valid over a stated interval.

Column	Content	Why a reviewer needs it
Clause ID + revision	POL-HARASS-004 r3	Anchors the row to a specific policy wording, not to a section number
Clause text hash	Digest of the exact wording in force	Proves the text shown in the pack is the text that governed
Enforcement artefact	Prompt ID + revision, or rule ID	Names the executable logic, not “our classifier”
Model version	Pinned build or checkpoint identifier	Distinguishes decisions across retrains
Threshold set	Named threshold bundle + values	Thresholds move more often than models; they need their own version
Action mapping	Which model outcome maps to which action	Shows how a score became a removal, a label, or a queue entry
Reviewer guidance revision	Guidance doc + revision	Explains what a human adjudicator was told
Validity interval	Effective-from / effective-to	Lets a reviewer select the row that was live on the decision date
Coverage status	active / retired / unenforced	Surfaces clauses with no executable path

The self-containment test for this table is simple: hand a reviewer one decision ID and this table, and they should be able to select exactly one row without asking a follow-up question. If two rows are candidates, the validity intervals or the threshold versioning are underspecified.

Emitted continuously, not reconstructed at audit time

This is the divergence point. Two teams can produce the same table and still be in completely different positions, depending on when the table came into existence.

A reconstructed mapping is assembled by people reading the policy document and the prompt repository side by side, after the question arrives. It is a best-effort interpretation of the past by people who were not necessarily present for it, and its accuracy degrades with every retrain and every policy release between the decision and the inquiry.

A continuously emitted mapping is a byproduct of the moderation workflow itself. The mechanism is unglamorous and mostly a matter of where the checks live:

1. Clause reference is a required field. A prompt or rule cannot be registered in the moderation service without at least one clause ID. This is a schema constraint, enforced in CI, not a review convention.
2. Deployment writes the row. When a prompt revision, model version or threshold bundle is promoted, the deployment step writes a mapping row with effective_from set and closes the interval on the row it replaces. Nobody edits the mapping by hand.
3. Decisions pin, they do not resolve. The decision record stores the identifiers directly — clause ID and revision, prompt revision, model version, threshold set. It never stores a pointer that has to be resolved against “current” policy later, because “current” will have changed.
4. The pack is a query. The regulator-facing rendering is generated from the mapping store for a stated window. Generation is repeatable; two runs against the same window produce the same table.

Point three is where most retrofit projects find their real problem. Decision logs that recorded a score, an action and a timestamp — but resolved the policy clause at read time — cannot be repaired retroactively. The information was never captured.

Detecting mapping gaps before a reviewer does

A mapping artefact is only as credible as its coverage reporting, and coverage is measurable. Three gap classes matter, and each has a different owner:

• Unmapped enforcement artefacts — a prompt, rule or threshold bundle in production with no clause reference. This is an engineering defect and should fail the promotion check rather than appear in a report.
• Unenforced clauses — a policy clause with no executable path to any action. Sometimes legitimate (the clause is reviewer-judgement-only), but it must be declared as such rather than discovered. An undeclared unenforced clause means the platform publishes a rule it does not apply.
• Stale mappings — rows whose clause revision predates the latest policy release. After a policy release, every affected row is stale until re-validated, and every open appeal against an affected clause is in scope for re-review.

That last item is the second reason the artefact pays for itself. When a clause changes, the affected prompts, thresholds and open appeals are enumerable rather than guessed, so re-review scope is known before the change ships. Teams without clause-level identifiers typically re-derive the mapping by hand for every inquiry and every policy release — a pattern we see repeatedly in pre-audit reviews, and one that scales badly with policy velocity rather than with volume.

Coverage and staleness are the two metrics worth putting on a recurring scorecard. Both are counts against a denominator the policy team already maintains, which makes them unusually hard to argue with.

Human overrides: the row that does not exist yet

Reviewer overrides are the case that breaks naive mapping schemas. A model suggests an action under POL-HARASS-004; the reviewer disagrees and actions the item under POL-VIOLENCE-002 instead, or reinstates it entirely. If the decision record carries a single clause field, one of those two facts is lost.

The mapping has to distinguish suggested from adjudicated. Concretely: the decision record carries the model-suggested clause ID and the adjudicated clause ID as separate fields, each with its own artefact provenance — the suggested clause pins the prompt revision and threshold set, the adjudicated clause pins the reviewer guidance revision and the reviewer queue. Divergence between the two fields is then a first-class signal rather than an inconsistency to be explained.

That signal is also the most useful thing the mapping produces internally. A clause pair that diverges frequently is usually telling you the prompt encodes a different reading of the clause than the reviewer guidance does — which is a policy-engineering finding, not a model-accuracy finding, and it is invisible to anyone looking only at precision and recall.

Where the mapping stops

The mapping artefact answers one question: which policy, which logic, which version, for this decision. It does not carry the reviewer adjudication trail, the appeal outcome, the sampling evidence for automated-only actions, or the escalation records. Those are separate sections with separate owners, and how they fit together is the subject of the section-by-section anatomy of a moderation audit-evidence pack, which covers the pack as a whole rather than the mapping mechanics.

The mapping is also not the same problem as surviving a policy rewrite — that is about how versioned records let the pack absorb change without losing history, and it is handled in how an evidence pack survives policy changes.

Our broader view of how these artefacts fit into governance and trust work sits on the AI governance and trust page. The mapping table is usually the first thing we build, because it is the cheapest artefact to instrument and the one every other section keys against.

One open question we have not resolved cleanly: how much clause granularity is right. Too coarse, and a single clause ID covers behaviours that need different thresholds; too fine, and the register outgrows the policy team’s ability to maintain revisions honestly. The teams that get this right seem to set granularity at the level where a reviewer can make a yes/no judgement without further subdivision — but we have not seen that stated as a rule anyone can apply in advance.

Frequently Asked Questions

What does policy-to-prompt-to-decision mapping captured as a regulator-facing artefact mean in practice? Regulators trace the complete lineage from organizational policy through system prompts to actual model decisions using structured documentation frameworks. It means the correspondence between policy text and executable moderation logic exists as versioned data, not as a narrative document. Each policy clause has a stable identifier, each prompt or rule references those identifiers, and each decision record pins the clause revision, prompt revision, model version and threshold set in force at the time. The regulator-facing artefact is a rendering of that data for a named window.

How are policy clauses given stable identifiers that survive rewording and renumbering? The identifier is opaque and permanent — something like POL-HARASS-004 rather than Section 3.2 — so it does not encode position in the document. Rewording produces a new revision of the same identifier; splitting a clause retires it and mints successors that record the lineage; merging records the inverse. Retired identifiers are never reissued.

What fields must a decision record pin so the mapping resolves years later? At minimum: clause ID plus revision, the enforcement artefact (prompt or rule ID plus revision), the model version, the threshold set, and the reviewer guidance revision. These are stored directly on the record rather than resolved later against current policy, because current policy will have changed by the time the question is asked.

How is the mapping emitted continuously from the moderation workflow rather than reconstructed at audit time? Clause reference is a required field for registering any enforcement artefact, and the deployment step writes the mapping row — setting effective_from and closing the interval on the row it replaces. Decisions pin identifiers instead of resolving them, and the pack is generated as a repeatable query over the mapping store rather than written by hand.

How do you detect and report mapping gaps? Three gap classes are counted separately: enforcement artefacts with no clause reference (an engineering defect that should block promotion), clauses with no executable path (legitimate only if declared reviewer-judgement-only), and rows whose clause revision predates the latest policy release. Coverage and staleness are the two metrics worth reporting on a recurring basis.

How does the mapping handle human reviewer overrides? The decision record carries the model-suggested clause and the adjudicated clause as separate fields, each with its own provenance — the suggested clause pins the prompt revision and thresholds, the adjudicated clause pins the reviewer guidance revision and queue. Divergence between the two becomes a reportable signal rather than an inconsistency someone has to explain.

Where does mapping evidence stop and the broader audit-evidence pack take over? The mapping answers which policy and which logic governed a decision. Adjudication trails, appeal outcomes, escalation records and sampling evidence for automated-only actions are separate pack sections with separate owners, covered in the pack-anatomy article.

Carrying Policy Prompt Decision Mapping forward

Treat Policy Prompt Decision Mapping as an engineering problem with a measurable answer, not a positioning question. The teams that do tend to ship the boring, correct version first.