Why a Short Checklist Beats a Long Policy Document

A detailed AI-use policy is necessary but too long to consult in the moment before sending an email or finalizing a document. This checklist is meant to be short enough to run through quickly, every time, for any AI-assisted technical content headed toward a deliverable — a working habit rather than a reference document consulted occasionally.

The Checklist

  1. Every factual claim traced to a source I've checked myself. Not "the AI cited a source" — I have personally opened the code table, spec sheet, or reference document and confirmed it says what the AI claims.
  2. Every number independently recalculated or verified against a trusted source. Not re-asked to the same AI tool — recalculated by hand, checked against a known-reliable calculator, or verified against a source I trust independently of the AI.
  3. Code/standard edition confirmed current for this project's jurisdiction. The AI tool may not know (or may not say) which edition it's drawing from, or may default to whichever edition is most common in its training data rather than the one actually governing this project.
  4. Units and magnitude sanity-checked. Does the final answer's order of magnitude make sense against a rough independent estimate or a comparable past project?
  5. Project-specific details actually reflect this project. Not generic boilerplate with details swapped in — the content genuinely responds to this project's actual conditions, not a templated version of a similar situation.
  6. No client-confidential information was exposed in generating this content. Confirmed the tool/tier used was approved for this level of confidentiality, per firm policy.
  7. A qualified human has reviewed and signed off. Documented, even briefly — dated initials or a project-file note confirming review occurred.

Red Flags That Should Trigger Extra Scrutiny

  • Suspiciously precise-sounding numbers with no shown derivation — a confident specific value presented without the steps that produced it is harder to verify and more likely to hide an error.
  • Citations that can't be quickly located — if a cited code section, standard, or manufacturer spec takes more than a couple minutes to find and doesn't match what's described, treat that as a strong signal the citation may be fabricated or mismatched, not just hard to find.
  • Answers that don't change when you correct an obviously wrong assumption in a follow-up — if you point out an error and the tool's revised answer doesn't meaningfully change, it may not have actually incorporated the correction.
  • Overly confident language on a genuinely uncertain or context-dependent question — real engineering judgment calls usually have caveats; an AI answer with no caveats on a question that should have some is worth a second look.

Making This a Habit, Not a Form

The checklist works best as a mental habit run through quickly, not a form filled out for every piece of AI-assisted content — save the formal documentation step for content actually headed into a client deliverable or calculation package, per your firm's human-review workflow, while still running the quick mental check on lower-stakes AI-assisted work as a matter of practice.