Skip to content

Reality Monitoring Checklist

Checklist method — instantiates Use-Time Source Attribution Calibration

A short cue-by-cue checklist run at the moment of recall to decide whether an item was actually perceived from the world or generated inside your own head.

The hardest source distinction to make is the one inside a single mind: did I observe this, or did I infer, imagine, or assume it and then remember the product? Reality Monitoring Checklist is a short, repeatable prompt list run at the moment an item is retrieved, that decides its source class by interrogating the cues that separate perception from internal generation — the richness of sensory and contextual detail, whether a specific moment of observing it can be recalled, and how much reasoning effort the item still carries. Its defining move is to distrust fluency: an item is not treated as observed because it comes to mind easily or feels certain, but only if it passes the cue checks that genuinely track external origin. Where a rubric grades how sure you are, this checklist decides which class the item belongs to in the first place.

Example

A security analyst is writing the timeline for an intrusion. Under pressure, "the attacker exfiltrated the database at 02:14" feels like a firm fact. Before it goes in the report as observed, the analyst runs the checklist against it. Can I point to the specific evidence I saw? — the log line, the byte counts, the timestamp. For the exfiltration event: yes, there is a concrete artifact, so it is tagged observed. Does the item carry perceptual/record detail, or does it feel like a conclusion? The claim "they'd been inside for weeks" has no single artifact behind it — it is an inference stitched from several weak signals, so it is tagged inferred, not observed. Do I actually recall encountering this, or did I reconstruct it to make the story cohere? The detail "they used the same tool as the last incident" turns out to be a memory of a hypothesis raised in a meeting, not a finding — tagged recalled/assumed, flagged for a source check.

The report now reads the same length but carries three different source tags where it previously had one implied "observed." The reader can see which spine of the timeline is load-bearing evidence and which is the analyst's reconstruction.

How it works

The checklist runs three moves at the point of use, in order:

  • Name the classes that matter. For this domain, fix the small set of source classes to sort into — typically observed / recorded, inferred, imagined or assumed, reported by another, and unknown — so the judgment has defined bins rather than a vague "sure / not sure."
  • Probe the cues, not the feeling. Ask the discriminating questions: Is there sensory or record detail? Can I recall a specific moment of encountering it? How much of it is reasoning I can still reconstruct? Externally-sourced items tend to carry perceptual/contextual detail; internally-generated ones tend to carry traces of the cognitive operations that produced them.
  • Apply the attribution rule. Assign the class the cues support — deliberately overriding fluency, authority, and desired conclusion when they point the other way — and default to unknown when the cues are mixed rather than forcing a label.

What distinguishes it from siblings is its target: the internal observed-versus-generated boundary, decided from cognitive cues in the moment, with no external record to consult.

Tuning parameters

  • Class granularity — a coarse observed/not-observed split versus a fine schema (observed, inferred, imagined, reported, reconstructed). Finer discriminates better but slows recall and invites false precision on a fuzzy judgment.
  • Cue set depth — how many discriminating questions to run. A one-question check ("can I point to what I saw?") is fast and catches the worst intrusions; the full battery catches subtle reconstruction but is too heavy for routine items.
  • Fluency-override strength — how aggressively vividness and confidence are discounted as evidence of source. Strong override catches confident false memories but can make a genuine sharp observation feel doubtful.
  • Unknown-tolerance — how readily an ambiguous item is parked as unknown rather than forced into a class. High tolerance preserves a path to checking; low tolerance keeps records tidy but manufactures false certainty.
  • Trigger scope — run on every recalled item, or only on the ones about to bear weight. Universal application is thorough but exhausting; selective application risks skipping the item that mattered.

When it helps, and when it misleads

Its strength is catching the intrusion that no external audit can reach — the inference or imagined detail that a single observer has already, sincerely, filed as something they saw. It makes the observed-versus-generated seam visible before the item is spent as evidence, and it protects legitimate internal generation by giving it an honest label instead of forcing it to masquerade as observation.

Its limits are those of introspection. The cues it reads are probabilistic, not proof: a richly-detailed memory can be confabulated and a true observation can be thin, so the checklist reduces error rather than eliminating it. Its classic misuse is running it backward — reaching for the cues that would license the label you already want ("it feels vivid, so I must have seen it") instead of letting the cues decide. The disciplines that keep it honest come straight from the underlying idea of reality monitoring:[1] treat fluency as a weak cue rather than proof of source, and prefer a reversible unknown over a premature observed, because a false "observed" tag propagates silently while an honest "unknown" leaves a door open to corroboration.

How it implements the components

Reality Monitoring Checklist fills the classify-from-cues front end of the archetype — the components that turn a raw retrieved item into a source class:

  • source_class_schema — it fixes the small set of source classes (observed, inferred, imagined, reported, unknown) that the judgment sorts into.
  • source_cue_feature_set — its questions are the cue set: perceptual detail, recollection of encountering, and residual reasoning effort, the features that track external versus internal origin.
  • use_time_attribution_rule — the rule that maps the cue readings to a class at the moment of use, overriding fluency and authority.

It does NOT attach a source_confidence_annotation to the label (the Source Attribution Confidence Rubric does), resolve a provenance_backlink_or_trace against an external record (Provenance Lookup Before Publication does), or compile the source_attribution_error_profile across many items (the Source Confusion Matrix Review does).

  • Instantiates: Use-Time Source Attribution Calibration — this checklist is the in-the-moment classifier that produces the source labels the rest of the machinery weights and checks.
  • Sibling mechanisms: Memory Source Probe · Source Attribution Confidence Rubric · Borrowed Idea Attribution Scan · Chain-of-Custody or Lineage Check · Generated Content Disclosure Gate · Hallucination Intrusion Triage · Observation Recheck or Replication · Provenance Lookup Before Publication · Source Attribution Training Set · Source Confusion Matrix Review · Source-Label Preserving Summary Template

References

[1] Reality monitoring — the cognitive process of deciding whether a memory records something perceived in the world or something internally generated (imagined, inferred, dreamt). The broader source-monitoring framework, developed by Marcia Johnson and colleagues, holds that people make this call not from a stored tag but by weighing cues such as perceptual detail and remembered cognitive effort — which is why a checklist that surfaces those cues can sharpen a judgment usually made by feel.