Field notes on the intelligence landscape.

A framing note up front: almost all the acronyms and machinery in the "defense data" world are US-specific (the US Department of Defense and Intelligence Community). NATO, the EU, and Switzerland each run parallel-but-different systems. We cover the US framework in depth — because that's where most of the industry vocabulary comes from — then flag the non-US equivalents at the end.

The three gates

However the data is tiered, legal access is the intersection of three independent things. Missing any one means no access:

• A clearance at the right level (or none, for the unclassified tiers).
• Need-to-know — a legitimate, documented reason tied to a contract or role.
• An approved environment — the right facility and network to actually touch the data.

The access mechanism changes at each data tier, so it's worth walking them bottom-up.

Publicly available data — no clearance

The easy tier, and often underrated. A lot of "defense-relevant" data is legally open:

• OSINT — Open Source Intelligence — anything derived from publicly available information.
• Data.gov, agency data portals, and FOIA (Freedom of Information Act) requests for releasable records.
• Commercial real-time feeds that are inherently open: ADS-B (aircraft transponder tracking), AIS (maritime/ship tracking), and commercial satellite imagery (Maxar, Planet, and others) — that last being publicly available GEOINT.

Access here is just procurement or registration. No security process at all.

CUI — the "sensitive but unclassified" tier

Where most defense contractors actually live day-to-day. CUI (Controlled Unclassified Information) replaced the older FOUO, SBU, and LES markings. Not classified, but protected. The closely related term is FCI (Federal Contract Information).

To legally handle CUI/FCI as a company, you generally need:

• NIST SP 800-171 — the security-controls standard for protecting CUI.
• CMMC (Cybersecurity Maturity Model Certification) — the DoD compliance regime built on top of 800-171; increasingly a prerequisite to win contracts.
• Awareness of ITAR (International Traffic in Arms Regulations) and EAR (Export Administration Regulations). These matter enormously from Switzerland: as a non-US entity, ITAR-controlled technical data is the most common legal landmine, since "export" includes sharing data with a foreign national even inside the US.

This tier rides on NIPRNet, the unclassified-but-sensitive DoD network.

Classified data: Confidential → Secret → Top Secret

You cannot self-apply for a clearance. The mechanics:

• A sponsor is required — a cleared employer or agency with a contract that needs you cleared. No sponsor, no clearance.
• You file the SF-86 via the e-QIP/eApp system. Investigation is run by DCSA (Defense Counterintelligence and Security Agency).
• Tiers: Tier 3 (Secret) and Tier 5 (Top Secret; the old SSBI).
• It now runs under Trusted Workforce 2.0 with Continuous Vetting — continuous monitoring instead of periodic reinvestigation — ending in adjudication against the federal guidelines.

And the company needs its own clearance

• FCL (Facility Clearance), governed by the NISP and its rulebook the NISPOM — now codified at 32 CFR Part 117.
• The company appoints an FSO (Facility Security Officer).
• Each classified contract carries a DD Form 254 defining exactly what's classified and at what level.
• The company holds a CAGE code and registers in SAM.gov to do business with the government at all.

Compartmented: SCI, SAPs, and SCIFs

Above Top Secret, "level" stops being the whole story — it becomes about compartments:

• SCI (Sensitive Compartmented Information) — intelligence sources and methods, walled into compartments you're "read into" individually. Often written TS/SCI.
• SAP (Special Access Program) — tighter still, with its own access lists; "black programs" live here.

Getting in requires more than a TS clearance: a formal read-in / indoctrination into the specific compartment with a signed SF-312 NDA, and often a polygraph (counterintelligence-scope or full-scope).

This is where the facilities vocabulary comes in. A SCIF ("skiff") is an accredited, physically and electronically secured space where SCI can be processed, discussed, and stored — built to ICD 705 standards. A SAPF is the SAP equivalent. TEMPEST is the discipline of preventing compromising electromagnetic emanations. An AO accredits the facility; ATO (Authority to Operate) is the IT-system equivalent.

The intelligence disciplines (the "INTs")

Data is often categorized by how it was collected, each with an owning agency:

• HUMINT (human), SIGINT (signals; subdivides into COMINT and ELINT), GEOINT (geospatial/imagery; IMINT is the older term), MASINT (measurement & signature), OSINT (open source), FININT (financial), TECHINT (technical).
• Owning agencies: NSA (SIGINT), NGA (GEOINT), DIA, NRO (the satellites), CIA — all under ODNI.

Real-time / operational data

"Real-time" usually means tactical or sensor feeds rather than archived intel:

• ISR (Intelligence, Surveillance, Reconnaissance) feeds.
• Link 16 / TDL (Tactical Data Links) — the real-time battlefield picture.
• JADC2 and ABMS — the newer DoD push to connect sensors and shooters across domains.

Access is contract- and role-gated on top of clearance — you're plugged into a specific operational system, not just "given the data."

How a contractor actually gets in

Putting it together, the normal sequence is: win or join a contract with a documented need → the company holds or sponsors the right FCL → the DD-254 defines what's accessible → individuals get sponsored clearances at the matching level → people are read into any compartments → work happens inside the accredited SCIF/network for that level. Procurement runs through FAR/DFARS, SAM.gov, and vehicles like GSA schedules, OTAs, and SBIR/STTR for smaller, innovative firms.

Non-US frameworks (relevant from Switzerland)

• NATO has its own ladder: NATO RESTRICTED → NATO CONFIDENTIAL → NATO SECRET → COSMIC TOP SECRET, with BICES as a shared network and NOFORN-style releasability caveats.
• EU: EU RESTRICTED through EU TOP SECRET (EUCI — EU Classified Information).
• Switzerland: governed by the Information Security Act (ISG/LSI), with its own INTERN / VERTRAULICH / GEHEIM levels. Swiss firms touching US defense data still hit ITAR/EAR walls and usually need a government-to-government framework or licensing.

Note — this is an educational overview, not legal or compliance advice. Frameworks change; export-control determinations are fact-specific. Engage qualified counsel before acting on any of it.

Two lineages dominate how serious organizations turn raw feeds into decisions: the defense / intelligence-community data-fusion tradition, and the modern entity-centric ontology tradition from commercial platforms. insigz's chain is a synthesis of both. Naming that lineage out loud is useful — it preempts the "did they just invent this?" reaction and signals that we know the canon.

The fusion lineage — the JDL model

The JDL model (Joint Directors of Laboratories), originally from the US Department of Defense and later refined as the DFIG model, is the reference framework for intelligence data fusion. It organises fusion into levels, and our stages line up with them almost one-to-one:

(Level 4, process refinement, is the platform itself — ingestion, source tasking, and the audit loop.) An analyst with a military or fusion background reads Source → Observation → Entity → Event and recognises Levels 0 → 1 → 2 immediately.

The ontology lineage — entity-centric platforms

The closer comparison for a product like insigz is the modern commercial best practice: the entity-centric ontology. In that pattern an object type defines an entity or event, a property defines its characteristics, and a link type defines the relationship between objects — all built by mapping existing data sources into objects, properties and links. Palantir's Foundry/Gotham ontology is the best-known example, and from roughly 2023 that ontology became the backbone for grounding enterprise AI agents.

That last point is exactly insigz's move: we ground the AI analyst at the observation / entity layer, so it cites rather than invents. We're aligned with where the leading platforms went.

Why we say "Case"

One term signals a specific heritage. In pure sensor-fusion vocabulary you wouldn't usually see "Case" as a stage — that work lives inside Level 2/3 situation and threat assessment. "Case" is investigative / compliance / OSINT vocabulary: law-enforcement case management, sanctions investigations, link-analysis notebooks. Given that our projects include maritime, sanctions and academic work, it's a deliberate and recognisable choice — it just flags an investigative lineage more than a sensor-fusion one. Pitching a hard-defense customer, we'd frame the same stage as "investigation."

One honest caveat — it isn't strictly linear

There's no single canonical "industry pipeline." The value is the clean synthesis, not a claim to have discovered the one true chain. And fusion isn't strictly sequential: the JDL model is often criticised precisely for implying the levels happen in order, when in practice any level can be processed on its own — situation assessment can run directly on entity-state estimates, for instance. Our left-to-right diagram is an excellent communication device; it is not a claim that data only ever flows one way.

What actually earns expert credibility

Not the noun chain — the properties around it. This is where insigz is strong, and what a serious reviewer judges:

• Provenance & lineage — can a claim be traced back to its source observation? Every claim resolves to a signed observation.
• Entity resolution — the quality of how observations collapse onto stable canonical entities.
• Grounding — the analyst cites [OBS-####] and refuses what it can't support, rather than hallucinating.
• Auditability — every change is versioned and logged; the audit trail is the evidence of responsible use.
• Time-travel / reconstruction — pin the world to any past moment (the AsOf control) and replay how a situation actually unfolded.

Note — the JDL/DFIG and ontology frameworks referenced here are described for orientation. Names and level definitions vary across the literature; treat this as a positioning map, not a standards citation.

Adding a source has always taken two specialists: a connector engineer to wire the feed and map its fields, and a canonical-model steward to decide how those fields become entities and events without forking the schema. That's slow, and it's the bottleneck that keeps most platforms from scaling past a handful of feeds. The Ontology Agent compresses both into a single, standardised flow you drive from the analyst chat.

You drop a source into the chat — a URL, an API spec, a sample payload, an uploaded file, or a pick from the catalog — and the agent profiles it, drafts the connector, drafts the field-to-Observation mapping, proposes which entity and event types it maps onto (reusing existing ones wherever it can), proposes resolution keys, and dry-runs the whole thing against a live sample so you can see exactly what it would produce.

It drafts; a human commits (doctrine Q9)

The agent removes the labour of onboarding, not the judgement. The canonical model is the shared contract every project, case and report depends on — a bad autonomous change there poisons everything downstream. So we treat the model like a protected branch: the agent opens the pull request, a human merges it. Every proposed connector, mapping, new type and resolution rule is presented to the Steward as one reviewable diff, approved with who/when recorded in the audit log. This is principle Q9 — the direct extension of Q8 ("AI supports, never decides") into the data layer.

The guided flow

A fixed, auditable pipeline. Each stage proposes an artifact and waits for approve / edit / reject — you never see raw plumbing unless you ask for it.

Stages 0–7 make a source exist and be trustworthy (the org layer); the final connect — deciding to use it in a project — is the existing project-layer flow on the Sources surface.

What the agent automates — and what stays human

• Automated: protocol & field detection, unit/timestamp/geo normalisation, connector generation, the field→Observation mapping, proposed resolution keys, the dry-run with conflict and dedup detection, and — crucially — suggesting reuse of existing types so the model doesn't sprawl.
• Human-gated: committing a new type to the model (Steward, Q9), supplying credentials and classification (Admin), merging two entities in the review band (analyst), and connecting a source into a project (Project Lead).

A worked example — onboarding "Spire satellite AIS"

An analyst pastes the Spire endpoint and a sample message into the chat. The agent reads it as a WebSocket stream, identifies mmsi as a vessel identifier and lat/lon/ts/sog as position, time and speed, and drafts the connector and mapping. At the ontology step it reports: "this maps onto your existing VESSEL type — match 0.97, recommend reuse, no new type." The dry-run replays 500 messages: 412 resolve to existing vessels, 71 are new candidates, 3 land in the review band (queued), 1 has a flag-state conflict (both values kept). The Steward approves the diff in one click; Spire AIS is catalogued, and the project lead connects it to Baltic Maritime Watch, immediately filling the AIS coverage gaps behind the cable-corridor case.

Total human effort: a handful of confirmations and one approval — versus the multi-day, two-specialist path it replaces.

A Standing Watch runs a grounded agent against the live feed on a trigger or schedule. When it matches, it doesn't act — it stages a Proposal in an inbox, where a human Accepts, Modifies or Rejects it. Accepting commits an ordinary Event, Case-update or Alert to the canonical model, logged with who and when. Every proposal carries its grounding: the cited [OBS-####] observations, the tool-use trace, and the reasoning — one click away under "Show Logic".

Bounded, reversible autonomy (Q10)

A watch may auto-apply only internal, reversible outcomes above a high confidence threshold — attach an observation, flag an entity, raise an alert, open a watch-status case. Anything customer-facing or irreversible — a report draft, a published artifact, an external notification — always stages for human review. It's enforced twice: in the product and, later, server-side. Q10 extends our older principles (AI supports never decides; agent-drafts/human-commits) from one-off approvals to always-on monitoring.

Proof before trust

Trust Evals score an agent before it ships — citation accuracy, refusal correctness, answer fidelity — against a baseline, and emit a signed Scorecard ("every claim cited · 0.98 · n=120") you can attach to a report or case. Analyst Studio lets you build new grounded agents without code; every one inherits citation-required and the refusal contract, so an ungrounded analyst can't be shipped.

Every node is an entity from the canonical model; every edge is a tie derived from shared observations and events — co-occurrence on the same case, an ownership link, a port call, a beneficial-owner relationship. The graph is laid out with a force-directed simulation and rendered as a live 3D point cloud you can grab, spin, and zoom. It is a way to navigate the model, not a picture of it.

Community detection & centrality

Nodes are coloured by detected community, so the clusters that matter separate visually without anyone tagging them — an ownership network, a fleet, a port of convenience. Node size and brightness track centrality: the connectors and the bridge entity that ties two clusters together are exactly the ones an analyst wants to look at first. You can recolour by community, by entity type, or by risk, and brush to the ego-network around any single node.

Grounded, not guessed

An edge exists because the data says it does. Click any node to open the Entity Inspector and walk each tie back to the observations and events that established it. When the autonomy layer infers a relationship, it does not draw it as fact — it stages a dashed, agent-suggested link that a human confirms or rejects, the same agent-drafts/human-commits line that governs the rest of the platform (Q10).

The baseline band is computed from the entity's own history using robust statistics — medians and robust spread rather than a mean and standard deviation — so a single noisy day doesn't drag the band around, and a genuine regime shift stands out clearly. The band is the expected envelope; activity inside it is normal, activity outside it is worth a look.

Scoring the deviation

Each anomalous bucket carries a deviation score (a robust z against the baseline) and a direction: quiet when it should be busy, or busy when it should be quiet — and the two mean very different things for a vessel, a cable, or a sanctioned counterparty. You can brush a window to quantify a span (total observations, peak, anomaly count against expected) or click a single bucket to inspect that moment and open the evidence behind it.

From signal to watch

A deviation is precisely the kind of trigger a Standing Watch fires on. Pattern of Life is where the watch's condition is defined and tuned; when activity crosses the band, the watch stages a grounded Proposal for a human to act on. The early-warning surface and the autonomy layer are two ends of the same mechanism.