Policy compliance scan

A policy compliance scan compares finished (or near-finished) operational output against a defined set of regulatory and internal policy rules. The model reads the text, maps passages to applicable rules, and returns structured flags where wording, commitments, disclosures, or omissions may breach those rules. The scan runs before delivery so reviewers see issues while there is still time to edit or withhold the document.

This page is for an operations compliance reviewer who is scanning model output, not for rewriting the underlying policies. You decide what ships. The model only surfaces candidates.

When the output text is missing, or the policy set is missing or empty, the scan returns no findings. Do not invent a default rule pack or treat blank input as a clean pass.

You need two inputs:

1. Output text — the draft, notice, report, email, ticket reply, or other artifact under review.
2. Policy set — the rules in force for this product line, jurisdiction, channel, or customer type (internal policies plus any regulatory constraints you have encoded for this workflow).

If either input is absent, incomplete in a way that makes matching unreliable, or explicitly empty, return empty output: no violation list, no “all clear,” and no partial score. An empty result means “scan not run,” not “compliant.”

Keep the policy set versioned and named in the run record so a later audit can tell which rules were applied. If the policy set changes between drafts, re-run the scan rather than reusing prior flags.

Treat the model as a first-pass detector. For each candidate issue it should state:

• Rule reference — which policy or regulatory clause it believes applies
• Passage — the exact span (or a tight quote) that triggered the flag
• Issue type — for example prohibited claim, missing required disclosure, conflicting commitment, restricted audience language, or retention/handling instruction that contradicts policy
• Severity hint — how serious the mismatch looks relative to the rule text (hint only; not a formal risk rating)
• Uncertainty — where the rule is ambiguous, the output is incomplete, or the match is weak

Prefer precision over volume. A short list of well-grounded flags is more useful than a long list of stylistic nits that are not policy. Do not rewrite the document in this step unless your workflow explicitly separates “flag” from “suggested edit.” The reviewer’s job is to accept, reject, or escalate each flag.

Do not auto-approve. Do not suppress flags because similar wording shipped before. Prior deliveries are not a substitute for the current policy set.

The model flags possible violations; compliance still decides. Use a fixed disposition for each flag:

• Accept — confirmed issue; hold or revise before delivery
• Reject — false positive or out-of-scope for this policy set
• Escalate — legal, regulatory, or product owner judgment required
• Defer — needs more context (source system data, customer class, jurisdiction) before a call

Record the disposition with the rule reference and passage. That trail matters when someone asks why a document shipped or why it was blocked.

Common failure modes to watch for while scanning:

• Over-flagging — marketing or tone preferences labeled as regulatory breaches
• Under-flagging — required disclosures skipped because they appear in a template elsewhere, not in this text
• Wrong jurisdiction — rules from another market applied to this channel
• Stale policy set — scan ran against yesterday’s pack after a rule change
• Hallucinated rules — citations that do not exist in the provided policy set (treat as invalid flags)

If the model cites a rule that is not in the supplied policy set, reject the flag and note the hallucination. Never treat an uncited “best practice” as a binding rule in this workflow.

Policy compliance scan sits beside other verify-stage checks that answer different questions. Completeness asks whether required sections and fields are present. Criteria-based scoring asks how well the output meets explicit quality bars. An adversarial pass tries to break claims or find contradictions. Policy compliance asks: given this text and this rule pack, where might delivery create a compliance problem?

Run order usually works best as: completeness first (so you are not scoring a half-built draft), then policy compliance, then criteria scoring or adversarial review as needed. If completeness fails, fix structure before investing review time in fine-grained policy matching.

Use the same output artifact across related checks so flags stay comparable. When you change the draft, re-run the scan; do not merge old and new flags by hand without re-checking the current text.

Before you trust a run:

1. Confirm output text and policy set were both present; if not, treat empty output as “not scanned.”
2. Spot-check a sample of high-severity flags against the actual rule text.
3. Reject any flag that cites a rule outside the supplied set.
4. Disposition every remaining flag (accept / reject / escalate / defer).
5. If any accept or escalate remains open, do not mark the item ready for delivery.
6. Store policy-set version, model run id, and dispositions with the work item.

After delivery (or block), keep the scan record with the final text hash or version. That pairing is what makes the verify step auditable later.