Obsidian for Intelligence Analysis

BLUF

Obsidian is a local-first, plain-text-markdown knowledge management application that has become the dominant platform for intelligence analysts, OSINT researchers, and investigative journalists who require a sovereign, extensible, and graph-aware personal knowledge base. Unlike cloud-dependent tools (Notion, Roam Research), Obsidian stores files as standard markdown on the local filesystem — which means the analyst retains full control, portability, and OPSEC integrity. This guide covers the analytical workflow patterns that matter for intelligence work specifically: vault structure, bidirectional linking as relational analysis, Dataview for programmatic queries, Templater for structured analytical products, and plugin ecosystem choices that preserve or compromise operational security.


Why Obsidian for Intelligence Work

Local-First Architecture

Every note is a .md file on the local filesystem. This has specific operational consequences:

  • Sovereignty: No vendor can revoke access, modify content, or surveil the knowledge base
  • Backup: Standard filesystem backup tools work (rsync, Git, Proton Drive with encryption)
  • Portability: Moving to another tool requires no export — the files already are the format
  • Offline: Works without internet; no dependency on remote services
  • Version control: Git-native (each note is a text file Git can diff)

For analysts handling sensitive subjects, local-first architecture is not a preference — it is an OPSEC requirement. Cloud-dependent note-taking creates adversary-accessible data concentrations.

Bidirectional Linking

Obsidian’s [[wikilink]] syntax creates bidirectional graph edges between notes. This matches how intelligence analysis actually works:

  • An actor is connected to operations, locations, related actors, sources
  • A concept is connected to historical cases, theoretical antecedents, contemporary applications
  • A piece of evidence is connected to the hypotheses it supports or refutes

The knowledge graph that emerges is directly analogous to the link analysis graphs used in intelligence work — but built from analytical content rather than imposed as a separate tool.

Graph-Aware Queries (Dataview)

The Dataview plugin enables SQL-like queries over note metadata and content. Practical uses:

  • Auto-generated dashboards of recent activity across the vault
  • Tag-based navigation and content aggregation
  • Status tracking (draft → review → publish-ready)
  • Filtered views of specific content types (all active investigations; all publish-ready conflict notes)

This programmability transforms the vault from a passive archive into an operational knowledge base.


The 10-section analytical structure used in this vault:

01 Actors & Entities/
├── 11_State_Actors/
├── 12_Non-State_Actors/
├── 13_Agencies_&_Departments/
├── 14_Corporations_&_Tech/
├── 15_International_Organizations/
├── 16_Leaders_&_Figures/
├── 17_Stateless_Peoples_&_Territories/
└── 18_Geopolitical_Regions/
02 Concepts & Tactics/
03 Weapons & Systems/
04 Current Crises/
05 Historical Events/
06 Authors & Thinkers/
07 Current Investigations/
08 Guides & Manuals/
09 Repository/
10 Library/

Design rationale:

  • Section 01 provides actors (who)
  • Section 02 provides concepts (what, doctrinally)
  • Section 03 provides tools and systems (what, concretely)
  • Section 04 provides active situations (when/where, current)
  • Section 05 provides historical precedent (when/where, past)
  • Section 06 provides intellectual genealogy (whose framework)
  • Section 07 provides ongoing investigations (analytical work in progress)
  • Sections 08–10 provide operational infrastructure

Every analytical note cross-links across these dimensions, producing the relational graph essential for hybrid threat and cognitive warfare analysis.


Frontmatter Standards

Every analytical note begins with YAML frontmatter:

---
title: "Note Title"
type: "actor | concept | weapon | conflict | historical-event | author | publication | framework | methodology | investigation | guide"
section: "01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10"
subsection: "[optional]"
tags: [list, of, canonical, tags]
status: "publish-ready | draft | stub | archive"
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
aliases: ["Alias 1", "Alias 2"]
---

Critical fields:

  • title — used by Obsidian Publish for URL generation
  • status — enables Dataview filtering; essential for production management
  • aliases — ensures [[Alias]] wikilinks resolve to the canonical note

See: Tag Index for the canonical tag vocabulary.


Essential Plugins

Core Plugin Set (OPSEC-Safe)

PluginFunctionOPSEC assessment
DataviewSQL-like queriesLocal-only; safe
TemplaterTemplate-based note creationLocal-only; safe
BreadcrumbsHierarchy visualizationLocal-only; safe
Local REST APIHTTP access to vault (for n8n integration)Local-only; safe but exposes vault via localhost
Obsidian GitVersion control integrationSyncs to chosen Git remote — choose carefully
ExcalidrawIn-vault diagramsLocal-only; safe

Plugins to Avoid (OPSEC Concerns)

  • Any plugin requiring cloud services for core functionality (some AI integrations)
  • Sync plugins that send content outside your chosen sync path — verify before installing
  • Analytics plugins that phone home to developer servers

AI Integration Considerations

Plugins that send note content to LLM APIs (Claude, GPT, Gemini) create external-data-transfer paths. For sensitive content:

  • Default to no: Sensitive analytical content should not leave the local environment
  • If using: Use API providers with data retention guarantees; never include classified or sensitive information in prompts; prefer self-hosted models for sensitive workflows
  • Audit trail: Know which notes have been processed by external AI and reassess periodically

Analytical Workflow Patterns

Daily Intake

  1. New information (article, document, observation) → 00_Inbox/YYYY-MM-DD_SourceTitle.md
  2. Brief captures go to a daily note: Daily/YYYY-MM-DD.md
  3. Later: process inbox into appropriate section folders with proper frontmatter

Note Creation from Template

Using Templater, structured templates for each content type:

  • Actor profile template (BLUF, Grand Strategy, Capabilities, Network, Leadership, Key Connections)
  • Conflict note template (BLUF, Actors, Timeline, Analytical Dimensions, Intelligence Gaps, Key Connections)
  • Investigation note template (BLUF, Key Findings, Open Threads, Source Record, Key Connections)

Analysis Workflow

For a new analytical question:

  1. Create note in Section 07 (Current Investigations) with the question and initial hypothesis
  2. Apply ACH structure to the note
  3. Cross-link to relevant actors (Section 01), concepts (Section 02), systems (Section 03), historical precedent (Section 05)
  4. As evidence accumulates, update ACH matrix
  5. When conclusion reaches sufficient confidence: publish-ready note; Signal Brief draft; Quartz article draft

Publication Workflow

Obsidian Publish (for intelligencenotes.com) or self-hosted Quartz:

  • publish.json controls which folders publish
  • status: publish-ready frontmatter gates individual notes
  • OPSEC critical: PIA/, Automation/, Publish/Beehiiv drafts must be in the excluded list
  • Regular audit of what is actually published vs. what should be

Dataview Query Examples

Recent Publish-Ready Notes

TABLE file.mtime AS "Updated"
FROM ""
WHERE status = "publish-ready" AND file.mtime >= date(today) - dur(30 days)
SORT file.mtime DESC

All Active Investigations

LIST
FROM "07 Current Investigations/Active Investigations"
WHERE status = "active"

Notes Citing a Specific Concept

LIST
FROM [[02 Concepts & Tactics/Algorithmic Warfare]]
SORT file.name

Stale Notes (Not Updated in 180 Days)

TABLE file.mtime AS "Last Updated", status
FROM ""
WHERE file.mtime <= date(today) - dur(180 days) AND status != "archive"
SORT file.mtime ASC

OPSEC Considerations

What Goes in the Vault

  • Open-source research and analysis
  • Structured frameworks and methodologies
  • Historical analysis
  • Published intelligence products

What Does NOT Go in the Vault

  • Classified information (where applicable by jurisdiction)
  • Privileged source identities that would be compromised by inadvertent disclosure
  • Operational details that would compromise ongoing investigations if leaked
  • Any material covered by NDAs or confidentiality agreements

Publication Gate Discipline

Every analyst operating a public-facing vault (e.g., via Obsidian Publish) must maintain rigorous discipline:

  • publish.json audited quarterly
  • status field applied intentionally to every note
  • New sections’ publish status explicitly set, not defaulted
  • Signal Brief drafts and other staging content kept in explicitly excluded folders

Key Connections