Open-data staff treat an OSINT framework link directory as the case-management system for a vendor review. Where should findings actually be stored?
Select an answer to reveal the explanation.
Short Explanation
The framework is a map of tools, not a filing cabinet. Your notes and the report are where URLs, screenshots, and conclusions live. Clicking a directory leaf does not save the case.
Full Explanation
Framework indexes point to techniques; they are not notebooks or case-management systems. When open-data staff treat an OSINT framework link directory as the case-management system for a vendor review, findings should actually be stored in the analyst's notes and report—source, time, capture, and conclusion—so the civic work product survives review and handoff.
Storing only in the framework tree because clicking a leaf stores evidence is false; directory clicks do not create case files. Storing only in a vendor SKU that cannot export notes to the city creates lock-in and audit failure. Storing only in a personal chat thread with no URLs or timestamps fails evidence standards.
Exam caveat: tools may assist note-taking, but the authoritative store must be exportable to the city and capable of holding locators and timestamps; the framework page itself is discovery, not storage.
Operational check: keep a structured notes file or report draft with URLs, times, and captures for the vendor review; use the framework only to find methods; and avoid chat-only or non-exportable SKU vaults as the sole record. In municipal practice, keep the wording tied to public artifacts, retrieval dates, and the authorized civic question so peers can re-perform the work without guessing intent.