AI tools now draft a growing share of the words that move through engineering organisations. Some of those words stay as drafts. Others travel into design notes, tickets, runbooks and reports, where they start to behave like reference material.
The corrective point is simple. The hard part is not getting AI to produce an answer. It is making that answer reviewable, current and accountable before it is reused.
In this context, “show your work” means the AI answer comes with its trail: the source, the conditions it depends on, and the check you ran. “Trust” does not mean “believe the tool”. It means “safe to reuse because another engineer can review it”.
A common failure mode is unexamined reuse. A paragraph is copied forward, stripped of context, and quietly promoted from draft to policy to practice.
The Decision Grade Answer Note
The governance move is straightforward. Treat an AI answer the way you would treat any third-party input that could influence a decision: be clear on where it came from, where it applies, what it assumes, and who is responsible for the check.
A practical way to do that is a one page Decision Grade Answer Note that travels with the AI output when it is reused. Decision-grade, here, means safe to reuse because someone else can review the evidence trail and the check.
This aligns with published guidance that treats AI output as useful but not self-validating, including EngX contributor guidance in Planning your blog post and the UK Government’s AI Playbook for the UK Government.
The six questions
If you can answer these, the output is reviewable. If you cannot, it stays a draft.
-
What is the claim, in one sentence?
-
What is the exact source, including the revision and date, and where in that source does it come from?
-
Where does it apply, and what is out of scope?
-
What are the top assumptions, and what would change the conclusion?
-
If sources disagree, which one wins and why?
-
What single check will we run before reuse, and who owns it?
Question two and question six do most of the heavy lifting. When you’re moving quickly, naming the source and naming the check is often enough to stop ungrounded text becoming a “fact” by repetition.
What a completed note looks like
Claim: Update test A and test B to meet the new requirement.
Source: a safety, quality, or engineering standard, 2024 revision, section 5.3 and table 2.
Applies when: product line A, current configuration, UK deployment. Out of scope: legacy variant and non-UK regimes.
Assumptions: using the 2024 revision; configuration matches table 2; no local derogation applies.
If sources disagree: the standard takes precedence over supplier guidance. Newest revision wins.
Check and owner: open section 5.3 and confirm wording, then update the test checklist. Owner: test lead.
Why the source and the check matter most
The exact source requirement is not pedantry. It is the control point that separates a helpful draft from decision support. It also protects you against a known failure mode: AI can generate plausible-looking references that do not exist, which EngX has discussed explicitly in What engineers and policymakers need to know about the ChatGPT revolution.
This post is about decision-grade advice and reuse, not action-taking AI where the control set expands.
The check is where governance becomes enforceable. The check must be real, proportionate, and owned. Owned is the point. If nobody is accountable for the check, it will not happen.
How the six questions prevent common failure modes
Most mistakes that matter are not wildly wrong. They are misapplied. A requirement that holds only for one variant is reused for another. A configuration assumption is dropped. A jurisdictional constraint is ignored. “Applies when” and “does not apply when” are the difference between guidance and guesswork.
An assumption list sounds basic, but it is the shortest route to a meaningful review. If assumptions are wrong, the answer is wrong. If assumptions are unspoken, nobody can evaluate them.
Conflict is normal. Standards evolve. Secondary sources summarise and can drop conditions. Documentation drifts. The failure mode is not conflict. It is hiding conflict in a smooth paragraph. A workable tie-break rule is usually enough: primary standards or regulation over commentary, newest revision over older revision, official documentation over blogs, test evidence over claims.
Why this is controllability
This is more than content hygiene. It is controllability: whether you can keep reuse within agreed limits and reconstruct why a decision was made.
The note creates a small, auditable interface between AI output and operational decisions. It gives you a required check before reuse for information as well as code.
For a public anchor for this posture, the NIST AI Risk Management Framework 1.0 links documentation to transparency, human review and accountability.
How to start without creating bureaucracy
Start in one workflow where reuse is common and stakes are meaningful: change approvals, runbooks, customer technical responses, procurement justifications, incident summaries.
Make the Decision Grade Answer Note the minimum for reuse. Start with question two and question six, then add the rest where consequence demands it.
Two practical cautions help keep this safe and usable.
First, do not paste internal material into tools you do not control; use titles and revision markers and verify from the original documents.
Second, do not let the note turn into a ritual. If the check is not something someone will do, it is not a control.
AI can speed up drafting. It should not speed up unverified reuse. A small evidence standard is often the difference between acceleration and drift.
Join the conversation
What would you make non-negotiable on your team: the source, the scope, the assumption list, the tie-break rule, or the owned check?
Which artefact spreads fastest in your environment: runbooks, change notes, or customer technical responses?
Share your approach in the comments, especially how you assign ownership for the check and how you handle tie-breaks when sources disagree.