Separate observations from interpretations in meeting notes
A useful meeting record can contain interpretation. The problem begins when an interpretation is written as though the room directly observed it.

Write meeting notes in three layers: what the team observed, what it interprets that observation to mean and what still needs verification. Do not compress those layers into one confident sentence.
“Three customers cancelled after onboarding” is an observation if the records support it. “Customers are leaving because onboarding is confusing” is an interpretation. The interpretation may be useful and even correct, but treating it as a fact can send the team into the wrong work with false certainty.
Use an evidence ladder, not a confidence tone
Polished language can make weak evidence sound settled. Instead of judging a sentence by how confident it feels, place it on an evidence ladder:
- Observed: a directly available event, statement, measurement or document.
- Reported: something a named person or source says happened.
- Interpreted: the meaning the team draws from observations or reports.
- Unknown: a question the current evidence cannot answer.
For example:
Observed: Trial activation fell during the week of the form change.
Reported: Two support conversations mentioned that the new form felt long.
Interpretation: The additional fields may be reducing completion.
Unknown: Whether the decline came from form length, traffic quality or another release.
The labels do not make the discussion timid. They show exactly where the team can act and where it must investigate.
Capture the source while the room remembers it
“The data shows” is not a source. Neither is “customers said.” Record enough detail for another person to locate the evidence without reconstructing the conversation.
Useful source notes are short:
- weekly activation report, 21–27 September;
- support conversation summaries reviewed by Priya;
- Leon's account of the client call on 30 September;
- onboarding form released in version 4.8.
A reported statement should keep its distance from direct observation. “Priya said the client rejected the timeline” tells a later reader who can confirm it. “The client rejected the timeline” erases the reporting step and may become false if the client actually asked a question rather than refused.
Do not fill the notes with links that nobody can access. Name the source and keep the relevant file, comment or meeting context connected to the record. A source that disappears behind a private inbox cannot support a shared decision for long.
Turn disputed facts into verification work
When two people remember the evidence differently, do not settle the argument by writing the most senior person's version.
Record the disagreement precisely:
Disputed: The team is unsure whether the 12 cancelled accounts had completed onboarding.
Then create a verification action:
Priya will check the account events for the 12 cancellations and add the result to this record by 3 October at 14:00.
The action needs an owner, evidence and a return point. “Check the data” is not enough. State what will be checked, where the answer will be added and which decision waits for it.
If work can safely proceed under either answer, name that work. If the answer materially changes the decision, keep the decision provisional rather than disguising the missing fact with confident prose.
Keep interpretations useful and falsifiable
An interpretation earns its place when it helps the team choose a test, action or decision. “Users hate the experience” is too broad to guide work and too vague to disprove.
Write a narrower interpretation:
The additional required fields may be reducing activation among trial users who do not yet have implementation details.
Now the team can test it. They might compare completion by field, review where users leave or speak with people who abandoned the form. The interpretation names a mechanism and a group; evidence can strengthen or weaken it.
Separate recommendations too:
Recommendation: Make the implementation fields optional for trial accounts while the team measures completion for two weeks.
That sentence is not an observation or an interpretation. It is a proposed action based on them. Keeping the layers visible lets the decision owner accept the recommendation without pretending its explanation is already proven.
Correct the record without hiding the mistake
Meeting notes are working records, so they will sometimes be wrong. Quietly rewriting the original sentence can remove the explanation for actions people took in good faith.
Add a dated correction:
Correction, 3 October: Nine of the 12 cancelled accounts had completed onboarding. The earlier note that most cancelled during onboarding was not supported. The team will review cancellation reasons before changing the form.
Then inspect everything downstream:
- Did a decision rely on the mistaken claim?
- Did someone start an action that should stop or change?
- Was the claim repeated in another meeting, update or client message?
- Does an owner need a new deadline because the work changed?
A correction is complete only when the affected work reflects it. Accurate minutes beside an unchanged implementation plan still leave the team acting on the error.
Use a four-line note during the meeting
This format is small enough to use in real time:
Observed or reported: [what happened, with source].
Interpretation: [what the team thinks it may mean].
Unknown: [what the current evidence cannot establish].
Verify: [owner, evidence, deadline and return location].
Not every sentence needs a label. Use the format where a claim materially affects a decision, priority, customer promise or allocation of work.
In Scripta, teams can bring notes or a transcript into a meeting record, review extracted decisions and actions, edit the wording and finalise the minutes. The review matters: Scripta can help structure what was written, but it cannot know that an unsupported interpretation became a “fact” during the conversation. A person still has to inspect the claim and its source.
This discipline also strengthens AI meeting notes that show their work. Source context is valuable only when the record is honest about what the source actually proves.
The goal is not to remove judgment from meetings. Judgment is why people meet. The goal is to prevent a useful hypothesis from hardening into organisational memory before anyone has checked it.
FAQ
Should meeting notes contain only facts?
How do you correct an interpretation that was recorded as fact?
Who should verify disputed meeting notes?
Keep reading
More from the Scripta blog
MeetingsA parking-lot question needs a return path
Keep deferred meeting questions from disappearing by recording the question, its owner, the evidence needed and exactly where the answer returns.
MeetingsDo not turn every meeting observation into an action item
Keep meeting task lists credible by separating observations from decisions, questions and real commitments before assigning work.
MeetingsA meeting action list needs an order
A long list of owned tasks can still fail when every item appears equally urgent. Choose what starts first, what waits and what gets dropped before the meeting ends.
DecisionsRecord what a meeting decision does not decide
Stop a reasonable meeting decision from becoming a blanket rule. Record its scope, exclusions and the questions that remain open alongside the choice.