“Human reviewed” is not a quality standard by itself.
A person can skim a fluent draft, miss an invented citation, approve the wrong attachment, or assume that a confident paragraph came from the client’s source material. A useful review process names what must be checked, what evidence is authoritative, and what stops release.
This guide provides a release gate for AI-assisted proposals, reports, client updates, summaries, and other professional drafts. It is designed for a solo professional who does not have a separate quality-assurance team.
Testing status. This is an editorial review method informed by the current public sources linked below. Practical Solo Ops has not validated the checklist across every profession, AI system, contract, or regulated use. It is not legal, accounting, security, medical, compliance, or professional-practice advice. High-impact or specialized work may require an independent qualified reviewer or a workflow that does not use generative AI.
Source status. NIST states that AI RMF 1.0 is being revised. This article uses the current published AI RMF 1.0 Core and the July 2024 Generative AI Profile as available on August 24, 2026. The worksheet is a small-business editorial adaptation, not a NIST checklist, certification, or claim of conformity.
Define the release unit
Do not review “the AI output” as an abstract category. Review one artifact for one audience and one action.
Write the release unit at the top of the draft:
Final client-status email for the August implementation phase, sent by me to the client project lead after I verify dates, completed work, open risks, and next actions against the approved project record.
The sentence should identify:
- the artifact;
- the intended recipient;
- the purpose;
- the authoritative source;
- the person who approves release;
- the action that follows approval.
The same text may need a different review when its audience or authority changes. A paragraph kept in private notes is not equivalent to the same paragraph placed in a signed proposal. A draft that suggests next steps is not equivalent to one that creates a commitment.
For data and permission decisions before drafting begins, use the client-data safety checklist. Human review at the end does not retroactively authorize an improper upload.
Match review depth to consequence
Use the highest consequence in the artifact to set the review depth.
| Review class | Typical use | Minimum release condition |
|---|---|---|
| Private working material | Outline, brainstorming, internal notes | Useful to you, clearly labeled, no external action |
| Routine client-facing draft | Status update, recap, non-binding deliverable draft | Full checklist completed against approved sources |
| Consequential or specialized work | Contract language, regulated advice, material financial calculation, rights-affecting recommendation | Qualified domain review or a non-AI workflow, plus any required formal controls |
Editorial analysis. Review effort should follow consequence, not word count. A two-line message can be high consequence if it changes price, scope, deadline, or responsibility. A long private outline may be low consequence if it cannot leave the workspace.
The automation risk ladder applies the same idea to system actions. If a workflow can send, publish, update a source of truth, or act without approval, solve the authority problem before improving the prose review.
Why fluent output needs evidence
Sourced fact. The NIST Generative AI Profile defines confabulation as confidently presented erroneous or false content, including output that diverges from input or contradicts earlier output. It also notes that generated logic and citations can themselves be false and may encourage inappropriate trust.
The practical response is not to distrust every sentence equally. It is to require evidence for material claims and to preserve uncertainty when the evidence is incomplete.
Sourced fact. The NIST AI RMF Core describes documenting knowledge limits and how output will be used and overseen by humans. It also calls for human-oversight processes to be defined, assessed, and documented, and for output to be interpreted within its use context.
Editorial adaptation. A solo operator can turn those broad outcomes into three release rules:
- the reviewer knows which source controls;
- every material uncertainty is resolved or disclosed;
- the reviewer records a clear approve, revise, escalate, or stop decision.
The nine-pass release review
Run the passes in order. Early failures often make later polishing unnecessary.
1. Reconfirm the brief
Compare the draft with the approved assignment, not with the prompt that happened to produce it.
Check:
- requested deliverable and audience;
- required sections, format, and length constraints;
- approved inputs and excluded material;
- promised tone and level of detail;
- deadline, scope, and acceptance criteria;
- actions the artifact may and may not take.
Mark any requirement as met, not met, or not applicable. Do not use “looks good” as a status.
Stop condition: the current brief is missing, contradictory, or materially different from the prompt. Resolve the brief before editing the generated draft.
2. Build a claim ledger
Highlight every statement that a recipient might rely on.
Material claims commonly include:
- names, roles, organizations, and contact details;
- dates, deadlines, sequence, and status;
- quantities, prices, percentages, totals, and units;
- project scope, deliverables, and completion claims;
- client decisions, approvals, objections, and quotations;
- product capabilities, performance, security, or compliance claims;
- legal, regulatory, tax, health, or professional conclusions;
- citations, links, and document references.
For each claim, record one of four evidence states:
| Evidence state | Meaning | Release action |
|---|---|---|
| Verified | Matches an approved authoritative source | May remain |
| Qualified | Source supports a narrower statement | Rewrite to the supported scope |
| Unresolved | Evidence is missing or conflicting | Ask, research, or remove |
| Incorrect | Contradicts the source | Correct and log the error |
Do not ask the same model to “confirm” its own unsupported claim and treat the answer as independent evidence. Return to the client record, contract, source document, calculation, or current primary source.
Sourced fact. The NIST Generative AI Profile recommends reviewing and verifying sources and citations in generative-AI outputs during evaluation and ongoing monitoring. It also warns against extrapolating capability from narrow, anecdotal assessments.
3. Verify sources, citations, and links
Open every source that materially supports the client-facing artifact.
Confirm:
- the source exists and the link reaches it;
- the title, author or issuing body, and date are accurate;
- the cited section supports the claim actually made;
- a quotation is exact and retains necessary context;
- the source is current enough for the decision;
- a vendor statement is identified as a vendor statement rather than independent proof;
- a secondary summary has not replaced an available primary source.
For PDFs, inspect the cited page. For web pages, save the access date when the fact can change. For client records, identify the approved version rather than linking to a folder with several drafts.
Stop condition: a material citation is invented, inaccessible, unrelated, or weaker than the draft implies.
4. Recalculate numbers and dates
Treat every number as a claim.
Check calculations outside the generated prose using the original figures:
- recompute subtotals and totals;
- confirm units, currencies, time zones, and tax treatment where relevant;
- distinguish percentage change from percentage points;
- check that denominators and comparison periods match;
- confirm rounding rules;
- inspect dates for year, month/day ambiguity, sequence, and business-day assumptions;
- confirm that a forecast is labeled as a forecast rather than a result.
If a spreadsheet or calculator produced the authoritative result, preserve that working file. Do not trust a plausible total because the surrounding sentence reads well.
Example, not a tested result. A draft says that moving from 20 hours to 15 hours is a 25% reduction. The reviewer should calculate the change from the original baseline, confirm that both figures measure the same work, and then verify that the client record supports each input. The arithmetic can be correct while the comparison is still misleading.
5. Check completeness and contradiction
Generated text can be locally polished while omitting the fact that changes the conclusion.
Compare the draft with the complete source set and ask:
- Is a required section absent?
- Is a limitation hidden in a footnote or omitted?
- Does the conclusion follow from the evidence?
- Does one paragraph contradict another?
- Are open questions presented as settled?
- Are client corrections reflected everywhere they matter?
- Has a condition become a guarantee?
- Has a draft plan become a completed action?
Run a reverse check: list the source facts that would materially change the recipient’s decision, then confirm each is represented accurately.
Editorial analysis. A completeness check is different from a fact check. Every sentence can be accurate while the artifact remains misleading because an important constraint is missing.
6. Inspect confidentiality, permissions, and ownership
Review both the visible text and the artifact around it.
Check for:
- client names or identifiers that are unnecessary for the recipient;
- another client’s data or reusable prompt context;
- credentials, access links, hidden comments, tracked changes, and document metadata;
- personal, privileged, regulated, or restricted information;
- material copied from a source without permission or attribution;
- images, charts, code, or text with unclear reuse rights;
- sensitive input repeated in a broader, more shareable output.
Inspect attachments and exported files, not only the message body. A clean email can still carry the wrong spreadsheet.
Stop condition: permission, confidentiality, or ownership is unclear for material content. Remove it or obtain the appropriate review before release.
7. Review impact, tone, and representation
Look for harm that a narrow factual review may miss.
Ask:
- Does the draft make an unsupported judgment about a person’s intent, competence, or character?
- Does it turn correlation into blame or causation?
- Does it generalize from one example to a group?
- Does it use certainty that the evidence does not support?
- Does it conceal that AI materially assisted the work when disclosure is required by a client, profession, platform, or policy?
- Would a person affected by the recommendation have enough information to correct a material error?
Do not treat a generic “bias check” prompt as proof. Use the real context, the people affected, and the decision at stake. When specialized judgment is required, escalate to someone qualified or narrow the artifact.
8. Verify the delivery context
Before release, review the exact final state the recipient will see.
Confirm:
- recipient names and addresses;
- subject line, document title, and version;
- attachments and access permissions;
- visible comments, tracked changes, speaker notes, and hidden sheets;
- links and link-sharing settings;
- file format and accessibility;
- requested call to action;
- deadline, owner, and next step;
- whether the message is a draft, recommendation, approval request, or commitment.
Read the artifact once in the delivery format rather than only in the editor. Export can change tables, pagination, link behavior, and hidden content.
Stop condition: the reviewer cannot see the exact destination, attachment, or action at approval time.
If the delivery behavior changed because an automation was edited, use the automation change log and rollback plan to verify the released workflow and preserve a safe restoration path.
If a tool is being replaced, the AI-tool offboarding worksheet adds the export, ownership, access, retention, and deletion checks that an artifact review cannot cover.
9. Make and record the release decision
Use one of four outcomes:
- Approve: all required checks pass and no stop condition remains.
- Revise: a correctable issue remains; return to the relevant pass.
- Escalate: qualified review, client clarification, or another authority is required.
- Stop: the artifact or workflow should not proceed.
Record the decision with the artifact version, reviewer, date, evidence used, unresolved limitations, and next review trigger.
Sourced fact. NIST AI RMF Core says documentation can improve human review and accountability. The Generative AI Profile also suggests documenting trade-offs and go/no-go decisions and using human moderation where it fits the use context and established oversight policy.
Copyable one-page worksheet
Use this as a release record. One row can contain a short note or a link to evidence.
| Gate | Status | Evidence or correction | Stop if |
|---|---|---|---|
| Release unit | Pass / revise | Artifact, audience, purpose, approver | Purpose or authority is unclear |
| Brief | Pass / revise | Approved requirements and scope | Brief conflicts with the prompt or draft |
| Claims | Pass / revise | Claim ledger and authoritative sources | A material claim is unresolved or wrong |
| Sources | Pass / revise | Opened links, pages, dates, quotations | A material citation is invented or misleading |
| Numbers | Pass / revise | Independent calculation and units | Inputs or comparison basis cannot be verified |
| Completeness | Pass / revise | Required facts, limits, contradictions | An omission changes the conclusion |
| Data and rights | Pass / revise | Permission, confidentiality, attribution | Use or disclosure is not authorized |
| Impact | Pass / revise | Affected people, uncertainty, recourse | Specialized or high-impact judgment lacks review |
| Delivery | Pass / revise | Recipients, files, links, final format | Exact external action is not visible |
| Decision | Approve / revise / escalate / stop | Version, reviewer, date, follow-up | Any stop condition remains |
Do not total the number of passes. One failed stop condition can matter more than nine completed rows.
Make the review efficient without making it ceremonial
A checklist should reduce missed work, not create a signature ritual.
Use three working views:
- Source view: the authoritative client records, calculation, contract, or primary sources.
- Draft view: the exact candidate artifact.
- Ledger view: material claims, evidence states, corrections, and the release decision.
Review in two sweeps:
- Red-flag sweep: audience, authority, sensitive data, material commitments, missing source, wrong attachment.
- Evidence sweep: claims, citations, numbers, completeness, impact, and delivery details.
Use search to find every currency symbol, percentage, date, proper name, quotation mark, external link, and commitment word such as “will,” “guarantee,” “approved,” or “complete.” Search is a coverage aid, not a substitute for reading.
Track review labor in the AI subscription total-cost worksheet. A workflow that saves drafting time but creates a larger verification burden may still be useful, but the burden belongs in the decision.
Maintain a small error log
After release or correction, record meaningful error categories without retaining unnecessary client data.
| Error category | Example signal | Process response |
|---|---|---|
| Unsupported claim | No approved source | Require claim-ledger evidence |
| Source mismatch | Citation does not support sentence | Open and inspect cited section |
| Quantity error | Wrong unit, total, or baseline | Recalculate outside prose |
| Omission | Limitation or open issue absent | Add reverse completeness check |
| Privacy leak | Unneeded identifier or metadata | Minimize input and inspect export |
| Scope drift | Draft promises work not approved | Reconfirm brief and authority |
| Delivery error | Wrong file, link, or recipient | Approve only in final delivery view |
Review the log on a schedule or when the workflow changes. Repeated corrections should change the template, prompt, source preparation, or use decision—not merely produce faster clicking through the same checklist.
Editorial analysis. The purpose of the log is calibration. It should help you learn where the process fails, not create a permanent archive of sensitive prompts and client material.
Example: reviewing a client-status draft
Example, not a tested case. A consultant uses approved project notes to draft a weekly client update.
The release unit states that the final email will summarize completed work, open risks, and next actions for the client project lead. During review:
- The claim ledger marks “integration complete” as unresolved because the source record says “testing complete; production activation pending.”
- A date appears in US month/day order while the client’s record uses day/month order, so the reviewer writes the month name.
- One next action assigns work to the client that was only discussed, not approved, so it becomes a question.
- The draft includes an internal ticket link the client cannot access, so the reviewer replaces it with a short explanation.
- The final delivery check finds an earlier spreadsheet attachment and removes it.
The outcome is revise, followed by another review of the affected claims and delivery state. This example illustrates the method; it does not report a Practical Solo Ops client engagement or tool test.
Know what human review cannot prove
Human review does not automatically establish:
- that a model is accurate across other tasks;
- that a vendor’s service is secure or compliant;
- that unseen source material is complete;
- that a reviewer has the required domain expertise;
- that a workflow is authorized by a contract or law;
- that a biased or harmful assumption will always be detected;
- that an external system will perform the intended action;
- that a polished artifact will produce a business result.
Sourced fact. NIST AI RMF 1.0 is voluntary and its Core actions are not a universal ordered checklist. The Generative AI Profile is also a cross-sector companion resource rather than a certification scheme.
Editorial conclusion. Human review is a control with conditions. It works best when the reviewer has authoritative sources, enough time, the relevant expertise, visibility into the final action, and the power to stop release.
Stop signs
Do not release when:
- a material claim, number, quotation, or citation remains unresolved;
- the artifact exceeds the approved scope or creates an unapproved commitment;
- sensitive information or reuse rights are unclear;
- the work needs expertise the reviewer does not have;
- the recipient, attachment, permission, or action is not visible at approval;
- the output affects rights, health, safety, credit, employment, housing, legal position, or another high-impact matter without appropriate safeguards and qualified review;
- the review consists only of asking the generating system whether its answer is correct;
- time pressure has reduced approval to a glance.
A delayed draft is usually easier to repair than a false claim, exposed file, or unintended commitment sent to a client.
Sources and further reading
- NIST AI Risk Management Framework — current framework status and the voluntary purpose of AI RMF 1.0.
- NIST AI RMF Core — outcomes for documented human oversight, contextual interpretation of output, accountability, monitoring, and go/no-go risk decisions.
- NIST Generative AI Profile — cross-sector guidance on confabulation, source and citation verification, human-AI configuration, moderation, and documented risk response.
- FTC Advertising FAQs for Small Business — US guidance that advertising claims need an appropriate reasonable basis and objective supporting evidence before publication.