Define human approval before AI-generated publishing
Separate draft creation, content approval and publication permission with version-specific evidence and a testable state transition record.
What does approval actually authorize?
A reviewer can approve the accuracy of a draft without authorizing its publication to every channel. The workflow needs a narrow record of what was reviewed, who had authority and which action is allowed. Otherwise, a comment such as “looks good” can be stretched into permission for an unrelated external action.
OpenAI’s safety guidance recommends human review where possible and access to original information. That recommendation does not mean every item labeled “human approved” has been checked. The review record must make the evidence and decision inspectable. The state design below is an original operational example. [Safety best practices]
A version-specific publication record
{
"contentId": "fixture-guide-01",
"versionHash": "fixture-hash-v3",
"state": "approved",
"evidenceReview": "sources-and-calculation-reviewed",
"approvedAction": "publish-this-version-to-owned-blog",
"excludedActions": ["email", "paid-promotion"],
"publicUrl": null
}| From | Required condition | Result |
|---|---|---|
| Draft | Evidence review and scoped content approval | Approved version retained |
| Approved | Current hash matches; execution authorized | Publication attempted |
| Publication attempted | Public readback matches approved content | Published with URL and release evidence |
| Approved | Claim, offer or substantive text changes | Return to review |
| Published | Correction required | Create a new reviewed revision; preserve history |
A hash links approval to bytes or a defined normalized representation, but does not judge the content. Choose what it covers: body, title, metadata, assets and downloadable files may all carry claims. If the image still contains an old unsupported number, approving only the text body leaves a real gap.
What should the reviewer receive?
- The exact draft, title and description that will be published.
- Source passages supporting factual claims and the dates they were checked.
- Original inputs and unrounded arithmetic for worked calculations.
- A list of unknowns, exclusions and any unresolved permissions.
- The intended destination and permitted external action.
Separate accuracy approval from identity or quotation permission where necessary. A contributor may confirm that a paraphrase is correct while withholding named attribution. A client may approve an aggregate result but not the identifying detail in the screenshot. The workflow should retain those distinctions instead of collapsing them into a single green status.
Automated checks can help identify missing links, invalid data or unexpected changes. They should report their actual scope. Passing a schema validator is not a human editorial review, and passing an editorial review does not prove a deployment reached the custom domain.
Test changes and partial delivery
Run fixtures where the title changes after approval, a source is removed, the public URL returns an error and a deployment succeeds under a preview domain only. The correct state should preserve the actual boundary: changed content needs review, and unpublished or unavailable content should not be labeled live.
The useful acceptance record contains the approved version, action, release reference and public readback. If any part is missing, retain the honest intermediate state. This makes recovery simpler when a publication fails halfway through or a later correction changes the evidence.
Sources
AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.
- Safety best practices — checked 2026-10-18