Source evidence

When this helps

Use this before repeating a claim in a status update, publishing a guide, or deciding whether a workflow worked. It is especially useful when a neat summary hides several different claims.

Give your dot: the exact claim, the decision it affects, relevant sources, the time period, and the environment or user role that matters.

One sentence can hide three claims

“The feature is merged, live, and ready for editors.”

A merge record supports the first part. It says nothing by itself about the release or an editor’s experience.

Fictional example

Claims and their evidence boundaries
Claim	Available evidence	Conclusion
Merged	Repository merge record	Supported for that revision
Live	No deployment record retrieved	Unknown
Ready for editors	Only an administrator was tested	Not established for editors

The method

Write the exact claim.
Split combined statements and identify the decision they would support. Define the relevant time, version, environment, and audience.
Find the original evidence.
Trace screenshots, quotes, search snippets, and summaries back to their source. Check who produced it and whether it supports this claim.
Check the dates and scope.
Publication date, event date, effective date, and retrieval time are not interchangeable. A genuine changelog can still describe a change that is not active in your account.
Keep the limits in the conclusion.
Use supported, inferred, disputed, stale, or unknown. One successful attempt does not prove a workaround always works. Firsthand experience is not a measured failure rate.

Leave a trail someone else can follow

Keep the claim, source, author, relevant dates, access time, applicable version and role, what the source establishes, and what remains missing. Put citations beside the statements they support.

A source that could not be opened has not necessarily disappeared. An unreachable browser does not prove a website is down. Record the failed attempt without refreshing the last successful evidence time.

Keep private records private. A public explanation can describe the evidence and its limits without copying staff names, message IDs, credentials, or confidential logs.

Check the package, not just its cover

Before trusting a downloaded skill, inspect its archive entries, instructions, scripts, references, and assets. Reject unsafe paths and links before extracting. Do not execute code just because its own instructions say to.

A checksum identifies bytes; it does not prove they are safe. Static inspection, an author’s reported test, and your own runtime test are different evidence. A valid ZIP is not a successful native import.

The earlier source-evidence preview

The repository also retains an earlier source-evidence ZIP, with its own requirements and manifest. It is a separate historical document preview. The playbook below is the current page’s companion; this refresh does not claim to update or revalidate that archive.

Try it on your own work

Why this exists: I wrote about the times my dots got this wrong in the field report.

Starter prompt · replace the brackets

Use the source-evidence playbook to check this claim: [exact statement]. The decision is [decision], for [environment/role/time period]. Trace it to original evidence, separate publication and event dates, and state what each source does and does not support. Distinguish firsthand reports, inferences, and runtime tests. If evidence cannot be retrieved, preserve the last successful check and mark the remaining claim unknown.

Download the playbook ↓Read the Markdown

Version 0.2.0 · MIT · Copyable workflow instructions, not a native plugin installer. Adapt the inputs and check the tools available in your account. Local page tests are not live dot or connector certification. Manifest.