AllMeetingsDecisionsProduct

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.

Mira compares two note cards with a teammate at a meeting table while they correct the record together.

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:

  1. Observed: a directly available event, statement, measurement or document.
  2. Reported: something a named person or source says happened.
  3. Interpreted: the meaning the team draws from observations or reports.
  4. 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?
No. Teams need hypotheses, judgments and recommendations to make decisions. Label them clearly so a later reader can distinguish direct observations from interpretations and unresolved questions.
How do you correct an interpretation that was recorded as fact?
Preserve the original record, add the correction, name the evidence that changed the wording and update any decision or action that depended on the mistaken claim.
Who should verify disputed meeting notes?
The person closest to the evidence should verify the underlying fact, while the meeting owner remains responsible for updating the shared record and affected follow-up work.