Abstract collection diagram: signals geocoded toward a central mission shape. PLACEHOLDER — replace with real product screenshot when available.
← Resources
article·

How Arcline's Collection Layer Works

Open-source feeds, scoped to a mission and traced to source. A look at how Arcline's live collection layer turns public data into findings an operator can act on.

By Arcline Team

Small teams can't staff a continuous watch on the environment around a mission. The information is public — global event feeds, disaster alerts, local reporting — but keeping eyes on it from planning through execution is a full-time attention job a handful of people don't have a slot for.

Arcline's collection layer is the part of the platform that does that watching. It reads open sources continuously, scopes what it finds to the missions a team actually has running, and keeps every item tied to where it came from. This is how it works today.

The sources

Collection runs on open feeds. In the default live loop, three are always on:

  • GDELT — global news-derived events across languages, queried against unrest-relevant terms (protest, civil unrest, riot, terrorism).
  • GDACS — the UN-backed disaster alert system: earthquakes, floods, cyclones, and other natural hazards.
  • RSS — curated local news feeds.

The architecture takes more than that. Additional feeds — event data, an expanded local-news registry, live track sources — are wired and can be switched on per deployment. The point isn't the raw count of feeds. It's what happens to them after ingest.

The value in open-source collection isn't secret access. It's disciplined, continuous consumption of feeds that are individually noisy and collectively overwhelming to a person.

From feed to finding

A raw feed is not intelligence. Turning one into something an operator can use runs through a defined pipeline:

Collect → observe. Each source is polled on its own cadence — event and hazard feeds every 15 minutes, news feeds every 30 — and every hit lands in a measurement store as a raw observation, timestamped and attributed.

Extract and gate. Observations get classified by taxonomy and, where useful, run through extraction to pull out the event. A geo-gate rejects anything that resolves outside the missions in play before it goes further — the first cut against noise.

Materialize into the graph. Surviving events become structured entities in the knowledge graph, with native-ID and spatial-temporal merging so the same event reported by three sources becomes one entity, corroborated, rather than three duplicates.

Discover against the mission. Monitoring intersects those entities against real mission geometry — the operating-area polygon, target locations with a radius. When something lands inside a mission's ground, it surfaces as a finding.

The operator experience is a nightly monitoring cycle plus an on-demand "run collection now" — deliberately, not a firehose of 15-minute pings. The machinery ingests continuously; what reaches the operator is scoped, merged, and deduplicated first.

Every item traces to its source

This is the part built for a skeptical user, and it's the part we're proudest of. Nothing in the system is a free-floating fact. Every observation and every graph entity carries its provenance — the source, the source URL where one exists, the timestamp, and a reliability rating.

Those ratings aren't decoration. Collection tags sources on the same reliability-credibility scale intelligence professionals use — GDACS rates high for reliability, GDELT lower, and so on — so an operator reading a finding sees not just what but how much to trust the who. (We wrote about that two-axis discipline separately in How to Rate an Intelligence Source; it's built into the tool, not left to memory.)

When a source has a URL, the operator clicks straight through to it from the finding. Follow any signal back to its origin, apply your own judgment, decide. A claim you can't check is a liability, not an asset — so the system is built so you can always check.

Open Source Intelligence dashboard

What the operator does with it

Surfaced findings land where the team is already working — a watch floor showing mission posture and open situations, and a triage queue where an operator acknowledges or dismisses each finding and opens the source when it's there. Collection feeds the picture; the operator works it.

That last point is the design line, and it holds firm: the engine surfaces signals; the operator decides. There is no recommendation layer telling a team to reroute or stand down — by design. Collection does the tireless part — reading, scoping, corroborating, tracing — and hands a checkable picture to the people whose job is to make the call.

Why it's built this way

Two principles shaped the whole layer.

Agents don't invent the ground. Collection materializes entities from real observations with real provenance. It doesn't fabricate events or add things to the map that no source reported. What you see traces to something.

Corroboration over volume. The merging, the geo-gating, the reliability tagging — all of it exists to hand an operator fewer, better items instead of more raw feed. Attention is the scarce resource on a small team; the system spends against it carefully.

Open feeds become mission-scoped, provenance-backed findings — without inventing entities and without telling the operator what to do. That's the collection layer today.

More of these as the platform grows. Next in the series: how missions are structured, so the scoping has real geometry to work against.