Leaving No Room for Doubt— A Check System That Removes Doubt ── Surface every objection first, then pin an owner and a deliverable to each one

01Why "Fix It After You're Told" Breaks Down

Log enough rejections in contract production and the causes split cleanly in two. One: the maker didn't know. The other: the maker did notice, but kept no evidence of having checked. The second kind is the more troublesome, and the more common. In review you're asked "is this dosage from the latest package insert?" and you have no answer ready, so the job goes back. Even if you did check, memory of a verbal exchange can't be reproduced.

What's failing here isn't quality. It's proof. The previous issue (Issue 3, The Regulatory Map) charted the four tiers: the Act, the advertising standards, the MSA guidelines, and the JPMA code. A map is useless to a reviewer without evidence that each waypoint was actually crossed. As long as doubt remains, the job keeps coming back.

02Surface Tomorrow's Objections Today

Removing doubt starts by writing out, on paper before production, every objection that review, screening, or audit could raise. Call it taking inventory of the contention points. The method is plain: cross past rejection records against the four-tier framework and write down every question this material could draw — as a question.

Phrasing them as questions is the trick. Not the noun "efficacy claim," but the interrogative "does any wording of the efficacy claim exceed the approved range by even one word?" A question stays open until answered. A noun checklist closes the moment you've "looked."

This table is only a starting point. Questions multiply by product class, medium, and channel. What matters is that the new questions aren't discarded but accumulated as an asset (which connects to standardization in Section 6).

03The Contention Ledger ── Pin the Checkpoint, the Owner, and the Deliverable

Surfaced questions aren't operable as-is. Each one becomes a system only once you pin three things: where it's checked (the gate), who checks it (the owner), and what proves it was checked (the deliverable). A table putting those three on one line per question is the contention ledger.

Any contention whose deliverable cell is blank is treated as unchecked. The ledger exists to kill "checked (I think)." If you can't name the evidence, redesign the form of the evidence on the spot.

04How to Build Gate Pass Criteria

The gates (A=Concept/sources, B=Regulatory map, C=QC, D=QA) don't work on "pass if roughly fine." Pass criteria must reduce to a form that leaves no judgment room — conditions decidable mechanically as binary (met/not met). "Appropriately stated" is not a criterion. "Zero diffs against the latest package insert" is.

Fix the criteria in three steps.

1. Aggregate the contentions ── pull the ones the ledger assigned to this gate.
2. Convert each to a pass/fail condition ── rewrite "is it...?" into a decidable proposition "...holds." Replace vague words (appropriate, sufficient, roughly) with numbers, comparisons, or presence/absence.
3. Write the pass definition in one line ── "all pass/fail conditions met, each tied to a deliverable." If exceptions are allowed, require a deviation record naming who approved it.

05Separating Authoring from Checking

This is the principle most easily broken and most effective. The maker's own check is not verification. Reviewing your own work is useful, but it's part of authoring, not an independent check. The same habit of thought builds the same blind spot at authoring time and at checking time.

Secure the separation on two axes: people and timing. People — "an owner different from the author decides gates B/C/D." Timing — "check all at once after authoring ends, not relying on self-checks while writing." In a small contract team that can't separate people, at least insert time and get close to a "blind check" that judges only from the ledger's evidence.

The reviewer looks first not at the artwork but at the contention ledger. Confirm every contention is tied to a deliverable, then sample and verify the contents of those deliverables. A job brought to a gate with the ledger still incomplete is sent back before anyone looks at the content.

06Standardizing Findings ── Never Raise the Same One Twice

A finding raised once must never be raised again for the same reason. If it surfaced, then either the contention was missing from the ledger or the pass condition was too loose. Don't let a finding end as a one-off fix; always return it to the system. Call it standardizing the finding.

Run it as a loop.

1. Record the finding ── one line each: what, on which regulatory basis, at which gate.
2. Classify the cause ── missing contention / loose pass condition / no owner / undefined deliverable.
3. Feed it back into ledger and criteria ── add the missing contention, rewrite the pass condition, so the same question fires automatically next time.
4. Inventory on a cadence ── tally findings monthly and promote frequent patterns into criteria.

This record becomes an asset against key-person dependence. A new owner can read past findings and inherit what this team has failed at.

07The SOP and Templates for the Check System

A system reproduces only once written into a procedure (SOP). A minimal SOP needs this flow. The sole acceptance condition is that the same verdict comes out when the owner changes.

Fix the columns of the ledger template: ID / question / regulatory basis (article, standard no.) / gate / owner / deliverable form / pass condition / verdict / evidence link. The basis column must name the basis precisely. Exaggerated advertising is Article 66 of the Act; unapproved (pre-approval) advertising is Article 68; information provision is Article 68-2. A contention citing the wrong article collapses at its foundation. Keep the basis column linking directly to Ad Regulation 01, the Act and 04, the MSA Guidelines.

08Operation ── Don't Let the Criteria Rot

Criteria age the moment they're set. Package inserts get revised, MSA interpretation updates, past findings keep growing. To prevent rot, run the criteria while measuring them.

• Findings per gate ── where do rejections cluster? A gate with many is a sign the upstream criteria are loose.
• Escaped findings ── findings raised by outsiders (screening, client) after gate D. The closer this is to zero, the more doubt has been removed.
• Recurrence rate ── the share of contentions supposedly standardized that surfaced again. High means the Section 6 loop isn't running.

When operation is unclear, default to this ── if judgment room appears, treat it as a sign the criteria are loose and fix the criteria, not the case. Tightening the criteria one notch is cheaper than passing a case on discretion. Move the check system away from a design that bets on human attention, toward one that yields the same verdict without it. The next issue (Issue 5, The QC Form (in preparation)) drills into the concrete steps of gate C, the QC process at the core of this system.