How do I document a process when I am not sure which details are confirmed?
Quick answer
Use three draft statuses: observed, unresolved, and verified. Record the basis for each detail, mark open questions clearly, and identify who or what can confirm them. Do not turn a plausible guess or single observation into an instruction. Before sharing guidance, check that each actionable claim is supported and that policy or safety questions have been confirmed by an appropriate reviewer.
The question, the details, the next step.
I need to document a process, but my notes mix things I watched happen with things people told me and things I am guessing. How can I draft it without making uncertain details sound official?
Give each detail a visible status instead of smoothing every note into polished instructions:
- Observed: You directly saw or recorded this happening. Note the context where it matters; one observation does not automatically establish a general rule.
- Unresolved: The detail is a question, second-hand report, or guess that still needs checking. Keep it out of final instructions, or mark it clearly in a draft.
- Verified: An appropriate person or reliable source has confirmed the detail for the process you are documenting. Record what supports it and who should review it if it changes.
These are practical editorial labels, not a formal standard. Purdue OWL recommends assessing whether sources are reliable, accurate, and trustworthy, and whether they support the claims being made. Its guidance can help you assess support, but it does not prescribe these labels or a verification workflow. [S1]
Keep what happened distinct from what someone should do. If you saw a colleague check a form, that observation alone does not confirm that everyone must do so. Leave the possible instruction unresolved until the requirement is confirmed.
What should the tracker look like, and how do I use it while writing?
Keep a tracker beside the draft, with one row per claim or step. For example:
Detail | Status | Basis | What needs confirming | Reviewer / next action
[Person reviews the request] | Observed | [Saw it in this context] | Is this required every time? | [Role to confirm]
[Request must be approved before processing] | Unresolved | [Mentioned in notes; no confirmation] | What is the requirement? | [Ask process owner]
[Confirmed instruction] | Verified | [Current document or reviewer and date] | Recheck if process changes | [Responsible role]
The bracketed entries are placeholders, not facts about your workplace. In the draft, use a marker such as [VERIFY: Is approval required before processing?] rather than quietly turning uncertainty into an imperative. Keep unresolved markers out of a reader-facing final version unless it is explicitly a draft and readers need to see the questions.
For each proposed instruction, ask what supports it and whether that support covers the audience and situation described. Purdue OWL’s revision guidance recommends checking whether evidence supports the main point and clarifying confusing sections. It does not specify who must verify a claim or establish a status system. [S2]
How do I handle policy or safety-related steps when I cannot confirm them myself?
Do not fill the gap with a guess or wording that merely sounds authoritative. Mark the claim unresolved, state exactly what needs confirmation, and route it to an appropriate policy owner or qualified safety reviewer. Until it is confirmed, omit it from instructions intended to guide action, or label the document clearly as a draft that must not be treated as verified guidance.
Make the question specific. Instead of [Check safety section], write [Does this process require a specific safety check before the task begins? Please confirm the current requirement and applicable situations.] That asks for an answer without inventing one. The Purdue OWL pages help with source assessment and revision checks; they do not establish workplace policies, safety requirements, or an approval chain. [S1] [S2]
What final check helps me make sure I have not accidentally turned an open question into an instruction?
Scan the action words in your draft: *must, always, submit, approve,* and *check*, for example. For each direction, find its tracker row and confirm that it is verified and that its support covers the instruction, audience, and situation. If the basis is missing or does not support the direction, change the status to unresolved and remove or clearly flag the instruction.
Also check that the draft states its scope, distinguishes observations from requirements, and gives reviewers specific questions rather than asking them to “confirm everything.” Revision can help reveal unclear or unsupported claims, but it cannot establish their truth by itself. [S2]
A practical checklist
Separate observed details, unresolved claims, and verified instructions.
Record a basis and next action for each unresolved or verified item.
Mark uncertainty in the draft; do not present guesses as instructions.
Route policy and safety questions to an appropriate reviewer before relying on them.
Check every directive against its tracker entry before sharing final guidance.
A few more useful answers
Can a detail be observed but still not be a verified instruction?
Yes. An observation records what happened in a particular context; it does not necessarily show that the same step is required every time. Confirm the broader requirement before writing it as a rule.
What if the person who can confirm a detail is unavailable?
Leave it unresolved, record the question and the role or source needed to answer it, and avoid presenting it as confirmed guidance. Do not guess just to complete the draft.
Should I keep the tracker with the published process?
That depends on how the document will be maintained. At minimum, retain the tracker with the working materials so reviewers can see what was confirmed and what still needs attention.
Sources
References used for this guide.
- [S1] Using Research and Evidence — Purdue OWL owl.purdue.edu · Checked
- [S2] Steps for Revising — Purdue OWL owl.purdue.edu · Checked