A diagram can look complete even when the middle of the story is missing. Before you rebuild a feature, ask a less comfortable question: which part of this explanation could I independently check?
Start with the exact target
Keep the package version, file path and a digest when available. “The app” is too vague once it updates. A later release may move a handler, change a format or remove the behavior you investigated.
Our Pocket Notes result identifies the inspected directory with a SHA-256 digest. The report is retained so a reader can compare the article’s claims with the actual result rather than taking a polished screenshot as the final authority.
Use three columns in your notes
| Label | What belongs there | Example from our lab |
|---|---|---|
| Observed | A finding directly present in the inspected material | The preload invokes notes:export |
| Inferred | A conclusion supported by observations | The API and handler form the intended export route |
| Unknown | Something the evidence does not establish | Whether a save dialog successfully wrote a CSV file |
This is an editorial method for reasoning about evidence. REA’s own record includes its confidence, limitations, unknowns and coverage; read those fields rather than replacing them with a single reassuring label.
Static evidence has a useful boundary
Static analysis reads the artifact. It can show declarations, literals and candidate relationships without launching the application. Those findings are useful, but a path present in code may not be reached in the state you care about.
In our fixture, REA reported one paired renderer transmission. The report also says that static Electron relationships do not prove runtime registration, reachability, defaults or enforcement. Both statements belong in the conclusion.
An application-level coverage result can be complete while semantic analysis still contains unknowns. In this retained report, the application inventory is complete and the semantic coverage status is unknown. Read the scope attached to each claim.
Turn assumptions into probes
Suppose the explanation says an exporter handles quoted notes correctly. The smallest useful probe is a note containing a double quote, followed by inspection of the resulting CSV with a parser. A screenshot of the Export button would not check that claim.
For a recovered calculation, compare outputs against the original across normal inputs and boundary conditions. For a browser workflow, connect the captured action to the response and the consuming code. The test should address the weakest link in the explanation.
Write a conclusion you can defend
Prefer: “The inspected package contains a matching invocation and handler for this literal channel. The handler includes a cancellation branch. We have not run the save flow.”
That conclusion is less dramatic than “we recovered the export system,” but it tells the next person exactly what they can build on and what remains to test.
Before implementation, make sure you can point to the target identity, the supporting locations, the unresolved assumptions and the next falsifying test. Then choose a narrow reconstruction. The DX-Ball study shows why comparing a small function can be more meaningful than showing a large imitation.