OSINT investigation standards

The external standards that Birdbrain measures its acquisition, preservation, analysis, export, security, privacy, and accessibility processes against.

Status: Engineering reference

Last reviewed: 2026-07-25

Scope: Birdbrain's acquisition, preservation, analysis, export, security, privacy, accessibility, and release processes

Executive position

No single "OSINT compliant" product standard or certification exists. A defensible investigation system is built from several independent assurance layers:

1. lawful and ethical investigative methodology;
2. validated online acquisition and digital-evidence handling;
3. immutable originals, explicit derivatives, provenance, and chain of custody;
4. interoperable archival and evidence packages;
5. independently verifiable cryptography and trusted time;
6. secure, privacy-preserving, accessible software;
7. governed use of automated and AI-derived analysis; and
8. a jurisdiction- and engagement-specific admissibility process.

Birdbrain should publish narrow, versioned conformance claims for each layer. It should not claim that the application itself makes evidence admissible, proves a statement true, supplies legal authority to collect, or makes an investigator competent.

This document is an engineering baseline, not legal advice. ISO standards usually require purchase of the full text; an ISO abstract is enough to identify scope, but not enough to claim conformance.

Standards hierarchy

The tiers below describe how Birdbrain should use a source. "Project baseline" means Birdbrain chooses to treat it as normative for product decisions; it does not mean the source is law in every deployment.

Tier 1: project baseline

Tier 2: interoperability and assurance profiles

These become normative only when Birdbrain adopts the profile or makes a conformance claim.

Tier 3: jurisdiction- and customer-specific requirements

These are deployment profiles, not universal Birdbrain product claims.

United States federal proceedings

Federal Rule of Evidence 901 requires evidence sufficient to support a finding that an item is what its proponent claims; Rule 901(b)(9) addresses evidence describing a process or system and showing that it produces an accurate result. Rules 902(13) and 902(14) provide certification routes for accurate electronic processes and digitally identified copies. The official 2017 Committee Notes use retrieval of a webpage as a Rule 902(13) example and identify hash comparison as a common Rule 902(14) process, but also make clear that authentication does not resolve hearsay, relevance, authorship, truth, attribution, reliability, confrontation, or other objections. Rules 902(13) and 902(14) require a qualified person's certification using the Rule 902(11) or 902(12) procedures and reasonable advance notice to the adverse party. Rules 1001 through 1003 separately govern originals and duplicates. Check the official current-rules page for amendments and maintain separate state-law profiles.

Birdbrain emits a factual export statement naming the tool and version, operator, acquisition method, hashes, trusted-time and signature results, known limitations, and verification instructions. It is not a certification template and carries no signature line or rule citation (ADR-0043). A qualified person drafts any certification the forum requires from that record, and the rule's notice procedure remains a case responsibility.

European Union

The GDPR applies when its material and territorial scope are met. Public availability is not a general exemption. An investigation needs a documented lawful basis, purpose, minimization and retention rules, security measures, processor/transfer controls, and a DPIA when processing is likely to create high risk. Special category data, criminal-offence data, indirect collection notices, and journalistic exemptions require separate analysis under Articles 9, 10, 14, and 85 and applicable Member State law. Birdbrain should support these decisions but cannot choose the user's lawful basis.

Under consolidated eIDAS Articles 41 and 42, an ordinary electronic timestamp cannot be denied legal effect solely because it is electronic or non-qualified, while a qualified electronic timestamp receives a presumption of the accuracy of its date/time and the integrity of the linked data. An RFC 3161 token is not automatically qualified. The current EU standards reference is Commission Implementing Regulation (EU) 2025/1929. A qualified workflow must use a qualified provider and specific service listed in the official EU/EEA Trusted List Browser, record the service's qualified status at issuance, and preserve the validation material.

The EU AI Act has phased application, generally applying from 2 August 2026, with some provisions earlier or later. Before enabling an AI workflow in the EU, determine Birdbrain's and the deployer's roles, the actual intended use, whether a prohibited or high-risk category is involved, and which transparency duties apply. Generic capture analysis should not be assumed exempt or high-risk without that use-specific assessment.

Accessibility procurement

For US federal procurement, the Revised Section 508 Standards apply to covered federal ICT and incorporate WCAG 2.0 Level A and AA. Birdbrain should retain WCAG 2.2 AA as its stricter development target while documenting the exact 508 test baseline.

For covered European procurement and public-sector use, assess EN 301 549 V3.2.1. Do not claim conformance to the draft V4.1.0 until it is finalized and the applicable legal references are updated.

Architectural consequences

1. Evidence and analysis are different object classes

• A captured original is immutable and content-addressed.
• Screenshots, extracted text, OCR, annotations, redactions, translations, summaries, reports, and AI output are derived objects.
• Every derivative records its source object(s), operation, tool/version, parameters, operator or automated agent, start/end time, output hash, and success/error state.
• Corrections create a new object or event; they never rewrite an original or historical event.
• Claims and findings cite the exact source object and location, record confidence and corroboration, and can represent contradiction or uncertainty.

2. Acquisition records the observation context

For each attempt, successful or not, record at least:

• requested URL, redirect sequence, final URL, and capture trigger;
• UTC time plus the displayed local offset, clock source, and trusted-time state;
• operator or pseudonymous operator identifier and case authorization reference;
• Birdbrain, extension, browser, operating system, and capture-component versions;
• user agent, viewport, locale, timezone, network/profile region, and authenticated-session mode;
• HTTP status and available request/response headers, DNS/TLS facts, and referenced resources;
• artifact sizes, formats, hashes, truncation/omission flags, and capture errors; and
• cache/service-worker behavior and other known conditions that could change displayed content.

Never persist session secrets, authorization headers, or cookies merely to make the metadata complete. Record the mode and a secret-free identifier instead.

3. Capture is multi-representation

The target evidence profile should preserve:

1. transaction-level content and protocol metadata in WARC;
2. browser-state representation in MHTML where available;
3. visual context in a screenshot or, when necessary, a screen recording;
4. extracted text and structured metadata as derivatives; and
5. an explicit inventory of resources that failed, were blocked, were lazy-loaded, were cross-origin, or could not be represented.

No representation is authoritative for every question. The UI and report must expose conflicts between what the network returned, what the browser rendered, and what extraction produced.

4. The evidence package is a versioned public protocol

• Publish Birdbrain Evidence Profile vN, JSON Schemas, media types, canonicalization rules, path rules, stable identifiers, test vectors, and compatibility policy.
• Include all payload and metadata hashes, manifest chain, signatures, timestamps, public keys, certificate chains, verification policy, and a plain-language inventory.
• Give every verification result a machine-readable status and reason. "Unverified" is not "tampered."
• Maintain a standalone verifier and test the profile with at least one implementation path that is not the capture/export code path.
• Map exports to WACZ/BagIt, PREMIS/PROV, and CASE rather than forcing those standards into the transactional internal schema.

5. Cryptography includes policy and lifecycle

• Store algorithm, parameters, key identifier, public key or certificate, signature format, and profile version with every signed object.
• Define key generation, protection, backup, rotation, compromise, revocation, and retirement.
• Preserve the material needed for later verification, including TSA chains and status evidence.
• Support timestamp renewal or preservation events before algorithms or credentials become weak.
• Clearly distinguish: content hash, manifest-chain integrity, signer identity, trusted time, and source attribution. Success in one axis must not be displayed as success in another.

6. Validation is release-specific

Maintain a public validation corpus covering static, dynamic, authenticated, localized, infinite-scroll, iframe, service-worker, streaming, deleted, redirected, erroring, oversized, malicious, and partially captured pages. For each release:

• state requirements and expected results before testing;
• test every evidence-affecting path and all supported operating systems/browser versions;
• compare artifacts against known truth or an independent acquisition method;
• exercise tampering, truncation, reordering, deletion, key, timestamp, import, and export cases;
• publish the test environment, results, deviations, false positives/negatives, and limitations;
• rerun impacted validation after dependency, browser, extension, crypto, or packaging changes.

Passing ordinary unit and end-to-end tests is necessary but is not forensic method validation.

7. Hostile-content security is an evidence requirement

A capture can be intentionally crafted to attack the investigator. Render originals in a sandboxed, offline replay context with scripting and live navigation disabled by default. Separate evidence parsing from privileged Electron processes, validate every IPC and archive boundary, constrain file paths and decompression, cap resource use, and make any live-network request visible and deliberate. Security failures can expose sources and can also contaminate evidence.

8. Privacy and human-rights safeguards are product behavior

• Collect the minimum case metadata needed for a declared purpose.
• Provide case retention, legal-hold, deletion, encrypted backup, and secure export controls.
• Keep audit facts useful for custody while minimizing identities and secrets in logs.
• Maintain immutable originals privately and create controlled disclosure derivatives.
• Warn before exports or AI requests transfer personal or sensitive data to another party.
• Record processor, model provider, region, retention setting, and user authorization for each external disclosure.
• Support source-risk and harm assessments, not just evidentiary relevance.

Local-first operation reduces exposure; it does not by itself provide encryption, authorization, lawful processing, safe retention, or safe publication.

9. AI output cannot silently become evidence

Birdbrain has no AI analysis feature. These requirements apply to any AI feature added later.

• Send AI only the data the user explicitly selects and disclose the destination before transfer.
• Record provider, model identifier, model-reported version where available, system prompt, user prompt, parameters, input object hashes, time, output, and safety/error state.
• Label output as machine-generated analysis and retain the exact response separately from human edits.
• Require a named human review event before an AI assertion becomes a report finding.
• Link every factual assertion back to captured sources; unsupported assertions remain visibly unsupported.
• Test hallucination, prompt injection from captured pages, bias, privacy leakage, content poisoning, non-determinism, and provider/model change.
• Never allow captured page text to issue tool instructions or alter evidence, case state, or verification status.

10. Releases are attestable artifacts

Every release should have:

• a signed digest and platform code signature;
• an SBOM, dependency and license inventory, and vulnerability disposition;
• SLSA provenance bound to the source revision and build inputs;
• reproducible-build results where feasible;
• signed update metadata with expiry, rollback protection, and key-rotation procedures;
• the evidence-profile version and forensic validation report;
• security, privacy, accessibility, and AI-control test reports; and
• a vulnerability disclosure policy, support window, and security update process.

Required assurance documents

Birdbrain should maintain these versioned artifacts in addition to source code:

1. Standards register: source, version, legal status, owner, review date, applicability, controls, implementation evidence, deviations, and supersession status.
2. Evidence profile: normative schemas and semantics for originals, derivatives, events, packages, signing, timestamping, and verification.
3. Method specification and SOP: intended uses, excluded uses, prerequisites, operator steps, expected outputs, quality controls, and known limitations.
4. Validation plan and report: requirements, reference datasets, environments, test cases, results, anomalies, acceptance decision, approver, and affected versions.
5. Conformance statement: exact standards/profile versions, conforming features, exceptions, evidence links, and claim wording.
6. Threat and privacy models: evidence-integrity threats, hostile-content threats, source safety, personal-data flows, retention, external transfers, and mitigations.
7. AI system record, for any AI feature: intended use, prohibited uses, data flow, model/provider inventory, evaluation results, human oversight, incident process, and change history.
8. Jurisdiction profiles: legal authority and admissibility checklist maintained with qualified counsel and practitioners for each target workflow.

Architecture decision gate

No evidence-affecting ADR is complete until it answers:

1. Which standard, investigation need, and threat require the decision?
2. What claim will Birdbrain make, and what does it explicitly not prove?
3. Which original, derivative, activity, agent, and custody events are created?
4. Can a skeptical third party verify the result without trusting the Birdbrain UI?
5. What information can be lost, altered, omitted, or disclosed, and how is that surfaced?
6. What privacy, human-rights, accessibility, and operator-safety impacts result?
7. Which export/interchange mappings change, and how is backward compatibility handled?
8. What known-truth validation demonstrates fitness for purpose, on which exact versions?
9. What operational procedure or user competence is still required outside the software?
10. Which jurisdiction-specific review or claim restriction applies?

Prohibited claims without additional evidence

Do not use these claims generically:

• "Court-admissible" or "court-ready": admissibility is jurisdictional, procedural, and fact-specific.
• "Forensically sound" or "forensic-grade": name the method, profile, validation report, supported versions, and limits instead.
• "Tamper-proof": describe which modifications verification detects and which trusted actors or endpoints remain capable of compromise.
• "Authentic" or "true": a valid hash/signature can establish integrity and origin under a stated trust policy, not the truth of captured claims or identity of a page author.
• "Qualified timestamp": reserve this for a timestamp meeting the applicable eIDAS requirements from a qualified service whose status has been verified.
• "GDPR compliant," "Section 508 compliant," or "AI Act compliant": publish a scoped conformance assessment tied to a product version, deployment, role, and use.

Maintenance and known caveats

• Review this register at least quarterly and before every evidence-profile release.
• Pin exact versions in conformance documents. Living sources such as Electron guidance, TUF, trusted lists, and regulator guidance change without a new Birdbrain release.
• ISO/IEC 27037:2012 and ISO/IEC 27041:2015 remain published but are in review cycles; monitor replacements before asserting current conformance.
• FIPS 180-4 remains current, but NIST has decided to revise it; keep the cryptographic profile versioned and algorithm-agile rather than embedding one edition forever.
• NIST Privacy Framework 1.0 remains the stable baseline while 1.1 is in draft. NIST AI RMF 1.0 is also under revision as of this review.
• SWGDE requires citations to include document version/status and warns readers to check for revised, deprecated, or sunsetted documents.
• CASE/UCO, WACZ, C2PA, SLSA, OWASP, and PREMIS are valuable consensus or community specifications but do not create legal admissibility or organizational accreditation.
• A product can enable a compliant workflow. The investigator and organization remain responsible for legal authority, competence, SOPs, disclosure, testimony, and case-specific decisions.