Evaluate output and enforce review gates

Verifiedon 2026-07-302026.7.1-2

Quality is evidence, not enthusiasm

A generated summary can be fluent and still be wrong. For the capstone, the reviewer checks each claim against a primary URL, version or date, source excerpt location, and plain-language uncertainty label. The editor cannot turn a rejected claim into an accepted one by rewriting it.

Use two gates:

1. Technical acceptance: the verifier confirms that every factual claim has a primary receipt and the output meets scope, format, and freshness rules.
2. Consequential release: the publication owner independently decides whether the accepted draft may be sent or published. A green technical review never auto-publishes.

Lab: make an acceptance checklist

Write binary checks before drafting:

• Every claim links to an approved primary source and retrieval date.
• The source version/revision is included when the claim is version-sensitive.
• Unsupported recommendations are labelled as recommendations, not facts.
• The draft is within the stated audience and word limit.
• Private data, credentials, and internal URLs are absent.
• A named reviewer accepted the technical pack.
• A named publication owner made a separate release decision.

Check: Reject a draft containing one compelling but unreferenced claim. Record the finding and return only that claim to research; do not discard verified work.

Checkpoint: separate the gates

A cron job finishes successfully and delivers a polished bulletin to its output location. Is it ready to publish? No. Job completion means the run reached a terminal status. It does not prove factual correctness, audience safety, or approval to create an external effect.

Learner artifact

Sketch an annotated review screen with three accepted claims, one rejected claim, source links, a technical-review signature field, and a distinct human publication button in a disabled state until review is complete.