Skip to content

Phase 2 Intelligence Collection Epistemic Filtering intelepi

elb-pr edited this page Apr 7, 2026 · 2 revisions

Phase 2 — Intelligence Collection & Epistemic Filtering (intelepi)

Phase 2, designated as intelepi, governs the transition from strategic planning to active digital operations. It is rooted in the "Evaluation" stage of the Intelligence Cycle, focusing on the rigorous vetting of raw data, the implementation of parallel sourcing mandates, and the preservation of a digital chain of custody. This phase ensures that every piece of information entering the system is graded for reliability and credibility before it can influence the analytical outcome.

Purpose and Scope

The primary objective of Phase 2 is to prevent cognitive biases—such as the Halo Effect or Authority Bias—from contaminating the investigation. It covers Steps 3 through 5 of the 15-step pipeline, utilizing specialized scripts for source grading, geolocation, and evidence hashing.


Step 3: Initial Vetting and Epistemic Filtering

Step 3 implements the Admiralty 6x6 Matrix, a NATO-standard intelligence grading system. This system forces a dual-axis evaluation of every discrete datum: Source Reliability (A–F) and Information Credibility (1–6).

Admiralty 6x6 Implementation

The source_grader.py script and the source-grading.md template are used to enforce these ratings.

  • Source Reliability (A-F): Based on the provider's historical track record.
  • Information Credibility (1-6): Based on internal logic and external corroboration.

Parallel Sourcing Mandate

To mitigate single-source reliance, investigators must adhere to a tiered hierarchy of sources:

  • Tier 1: Official government records (e.g., Companies House).
  • Tier 2: Verified commercial databases (e.g., Orbis, Sanctions lists).
  • Tier 3: Authenticated social media.
  • Tier 4: Secondary news and commentary.

OSINT Technical Verification

Digital media undergoes technical vetting via geolocation.py and content_archiver.py. This includes:

  • Reverse Image Search: Using Google/TinEye to identify original contexts.
  • Chronolocation: Shadow analysis (SunCalc) and weather cross-referencing to determine capture time.
  • Metadata Extraction: Extracting EXIF data and comparing it against visual findings.

Step 4: Continuous Logging and Operational Accountability

All investigative actions are recorded in real-time within the task-log.md (Actions Register) to ensure auditability and prevent "scope creep".

Key Logging Mandates

Task Requirement Code/Template Entity
Enquiry Recording Log actions at the moment of initiation; retroactive logging is forbidden. templates/database/task-log.md
Negative Results Mandatory recording of null enquiries (e.g., database search with no results). t4.2
Policy Deviation Immediate logging of any deviation from the original Investigation Plan. research/case-decision-log.md

Negative results are critical for legal disclosure (UK CPIA) and are used in Phase 5 (ACH Matrix) as evidence of inconsistency.


Step 5: Evidence Preservation and Chain of Custody

This step ensures that all captured assets are preserved for legal or regulatory scrutiny using the evidence-register.md.

Technical Preservation Workflow

  1. Digital Hashing: Every file or screenshot is processed via evidence_preservation.py to generate a SHA-256 hash at the moment of capture.
  2. Web Archiving: Pages are captured using Playwright for screenshots and submitted to the Wayback Machine via waybackpy for independent timestamping.
  3. Source Register Maintenance: A bidirectional link is maintained between the Source Register and the Entity Register. Every entity record must reference the source identifier (e.g., SRC-001) that contributed the data.

Data Flow: Collection to Evidence Register

The following diagram illustrates how raw intelligence is processed through technical scripts and logged into the persistent markdown "database" templates.

Collection and Preservation Logic

graph TD
    subgraph "Natural Language Space"
        A["Raw OSINT Source"]
        B["Manual Investigation Action"]
    end

    subgraph "Code Entity Space (Scripts)"
        S1["source_grader.py"]
        S2["evidence_preservation.py"]
        S3["geolocation.py"]
        S4["content_archiver.py"]
    end

    subgraph "Persistence Space (Templates/CSDb)"
        T1["source-grading.md"]
        T2["evidence-register.md"]
        T3["task-log.md"]
        T4["case-decision-log.md"]
    end

    A --> S1
    A --> S4
    S1 -->|"Admiralty Grade (A-F, 1-6)"| T1
    S4 -->|"WARC/PNG Capture"| S2
    S2 -->|"SHA-256 Hashing"| T2
    B -->|"Action Initiation"| T3
    B -->|"Policy Deviation"| T4
    S3 -->|"Lat/Long & Confidence"| T2
Loading

System Architecture: Epistemic Filtering Gate

This diagram shows the "hard gate" logic where intelligence is blocked from entering the analytical chain (Phase 3+) unless it passes the Admiralty grading and hashing requirements.

Epistemic Filtering Pipeline

flowchart LR
    subgraph "Phase 2: intelepi"
        direction TB
        Input["Raw Intelligence"]
        
        subgraph "Task 3.1: Grading"
            G1["source_grader.py"]
            G2["Admiralty 6x6 Matrix"]
        end
        
        subgraph "Task 5.1: Integrity"
            H1["evidence_preservation.py"]
            H2["SHA-256 Hashing"]
        end
        
        Gate{"Epistemic Gate"}
    end

    subgraph "Phase 3: colent"
        P3["Entity Resolution"]
    end

    Input --> G1
    G1 --> G2
    G2 --> Gate
    Input --> H1
    H1 --> H2
    H2 --> Gate
    
    Gate --"Validated (e.g. B2 + Hash)"--> P3
    Gate --"Ungraded / Unhashed"--> REJECT["SYSTEM FAILURE"]
Loading

Clone this wiki locally