OWASP OSINT Verification Standard · Version 0.1.0
Evidence,
not assertion.
Open-source intelligence now informs decisions that affect liberty, safety, and national security. OOVS is an open standard that makes those decisions defensible — every judgment traceable to its origin, every requirement testable against published criteria, and AI output never mistaken for evidence.
The problem
A confident report and a correct report look identical.
Publicly available information is now used to prioritise cyber defence, attribute hostile activity, support safeguarding referrals, document alleged atrocities, and justify consequential action. The professional guidance covering that work is written almost entirely as prose.
Prose describes what good practice looks like. It rarely states what evidence would demonstrate it, what sample would test it, or what observation would disprove it. So an organisation can state that it follows a protocol without producing anything a second party could check — and a reviewer cannot distinguish a disciplined process from a self-assured one.
When the reasoning cannot be inspected, the failure is invisible until it is consequential. Then it is a misidentified person, a wrong attribution, or a decision no one can reconstruct.
What the standard does
Four questions, answered on the record.
Where did this come from?
Every material item carries its origin, time, method of collection, and handling history. Originals stay distinguishable from copies, so an error can be found and corrected rather than merely regretted.
Is it independently corroborated?
Independence is judged by counting distinct origins, not mentions. Reposts, syndication, and machine restatements of the same single source do not become confirmation through repetition.
Who is accountable for the judgment?
Observation, inference, assumption, and unknown are stated separately. Automated output is an aid, never a witness, and a named person remains answerable for any consequential determination.
Does the caveat survive contact?
Confidence, limits, handling constraints, and expiry travel with the product to the point of action — and a correction can reach everyone who received it.
Failure modes closed
Five ways sound-looking intelligence goes wrong.
Each requirement in the standard exists because one of these has already caused documented harm.
-
01
Undecidable observation
No one can establish what was actually seen, from where, or how it changed on the way to the report. Correction becomes impossible, because the affected material cannot be located.
-
02
Amplification laundering
One origin travels through many apparently independent accounts. Counting mentions instead of origins converts a single unverified claim into apparent consensus — the mechanism behind some of the best-known misidentifications on record.
-
03
Signal overtrust
Embedded metadata is forgeable and routinely stripped. A cryptographic hash proves bytes are unchanged, not that content is true. Provenance credentials record assertions about creation, not whether the depicted event happened. Detectors degrade badly outside their test conditions.
-
04
Automation laundering
An automated system restates its own input in fluent, confident prose, and the fluency is mistaken for corroboration. Under this standard, machine output can never corroborate the material it was derived from.
-
05
Dissemination decay
Assurance achieved during analysis is lost at release: caveats dropped in summary, a lead retold as a finding, distribution beyond need-to-know, and no route to reach recipients with a correction.
Assurance of the standard itself
A standard that tests itself.
Most standards are a document. This one is a document and a structured, machine-checkable record of the same requirements — and automated checks refuse to publish if the two ever disagree. A requirement cannot be quietly reworded in one place and left stale in the other.
Each release also publishes a manifest of file hashes. Anyone can confirm that the copy they hold is byte-for-byte the copy that was released, so a document altered in transit or misquoted downstream can be identified rather than argued about.
Requirements are also adversarially tested: deliberately faulty records are kept on file and the checks must reject each one for the stated reason. A test suite that only ever passes proves nothing.
Why this matters for procurement
A conformance claim is only as good as the specification behind it. If the specification can drift, every downstream audit inherits the drift. Fingerprinted releases and enforced agreement between the human and machine forms mean an assessment can be tied to an exact, verifiable version of the rules.
Grounding
Built on established doctrine, not invented from scratch.
Every requirement cites public guidance that practitioners and oversight bodies already recognise. These relationships are stated conservatively: related to, not equivalent to, certified against, or compliant with.
| Source | What it establishes |
|---|---|
| Berkeley Protocol on Digital Open Source Investigations | International minimum professional and ethical standards for identifying, collecting, preserving, verifying, and analysing digital open-source information. |
| ICD 203 — Analytic Standards | Separation of information from judgment, expression of uncertainty, consideration of alternatives, and logical argumentation. |
| ICD 206 — Sourcing Requirements | Sourcing and source description for disseminated analytic products. |
| W3C PROV | A general model for provenance in terms of entities, activities, and agents. |
| NIST AI Risk Management Framework | Voluntary structure for governing, mapping, measuring, and managing AI risk. |
| EU AI Act & Law Enforcement Directive | Binding obligations within their own scope; treated as jurisdictional profiles, never as global defaults. |
| STIX / TAXII, CASE / UCO, MISP, OpenCTI | Established representation and exchange of threat and investigative information, mapped rather than replaced. |
Who it is for
Written for the people who carry the consequence.
Government & defence
Vendor-neutral acceptance criteria you can put in a requirement document. A jurisdiction-neutral core with profiles for local law, rather than one country's rules exported as universal. Human accountability mandated for high-consequence determinations.
Critical infrastructure & industry
A common language for judging the quality of intelligence you buy, receive, or produce — independent of which platform produced it, and usable alongside systems you already run.
Oversight, legal & policy
Scoped, portable assessment results with an outcome derived mechanically from the evidence, so a favourable summary cannot be asserted over unfavourable detail.
Journalism, research & civil society
The same baseline a state body would apply, written so that a two-person team can implement it with lightweight records and an external challenger.
Scope
What this is not.
Precision about limits is part of the assurance. A standard that overstates itself cannot be used to check anything.
- Not a certification or accreditation scheme. Assessment records a scope and a result; it does not issue a mark.
- Not a determination of legal compliance or of whether evidence is admissible.
- Not endorsed by any government, agency, court, or vendor, and no such endorsement is implied.
- Not an intelligence platform, and not a replacement for one. It is the assurance layer around whatever you already use.
- Not a substitute for applicable law, professional training, or organisational policy.
The project is hosted by the OWASP Foundation at Incubator stage. That denotes acceptance and hosting — not technical review or endorsement of the content by the Foundation.
Status & naming
Released, and openly incomplete.
One note on names. OOVS is the OWASP OSINT Verification Standard — the requirements on this site. It is published by the OWASP project named Open Source Intelligence Standard, which also covers supporting work such as technique records and testing scenarios. Requirement identifiers carry the OOVS prefix, so citations stay unambiguous.
Version 0.1.0 is published under a Creative Commons Attribution-ShareAlike licence: ten requirements, an acceptance test bound to each, a portable format for recording results, a worked example, and the automated checks that keep the whole thing honest.
What has not happened yet is stated as plainly as what has. There is no independent assessment on record, no measured agreement between separate assessors, and no field deployment. Those are the next milestones, and the results will be published whether or not they are flattering.
| Stage | State |
|---|---|
| Ten requirements, tests, result format | Published in v0.1.0 |
| Assessor and sampling guidance | In progress |
| Agreement measured between independent assessors | Planned, protocol pre-registered |
| Reproducible end-to-end reference exercise | Planned |
| Jurisdictional profiles with legal specialists | Planned |