01Collection-led
Collection leads, requirements follow
Teams ingest whatever the feeds provide, then work out afterwards which question it answered. The requirement becomes a justification rather than a starting point.
Intelligence operating system
Know what you’re not collecting.
GroundLine connects business objectives to intelligence requirements, collection and evidence, so security teams can see what matters, what is covered, and what isn’t.
Private beta · Taking design partners
- Objectives
- 14
- Requirements
- 67
- Gaps
- 23
The problem
Most intelligence programmes run backwards.
The work starts from whatever arrives, not from what the business needs to know. Three things follow.
02Blind spots
Coverage is invisible
Nobody can point at what is not being collected against. Gaps surface when something is missed, which is the one moment they are most expensive to find.
03Unmeasured
Value is asserted, not measured
Output gets defended on volume. The link between what the team produced and what the business actually cares about is a story told after the fact.
TodayCollection-first
- Feeds
- Collection
- Analysis
- Report
- Requirement?
With GroundLineRequirements-first
- Objective
- Requirement
- Tasking
- Evidence
- Coverage
How it works
Requirements first. Everything else follows.
Three moves turn a business priority into a collection plan you can measure.
- 01Define
Define the objective
Business objectives carry an owner, a delivery date, and a weighted value score built from your own value drivers. The weighting is yours, not a fixed industry scale.
- 02Decompose
Break it into requirements
A structured hierarchy of CIRs, PIRs, SIRs, FIRs and EEIs, each tied to the objectives it serves. Sources are tasked against requirements, and evidence is linked back to them with a weight.
- 03Measure
See the gap
Every requirement plotted by the business value it carries against how well it is actually satisfied. The corner that matters is high value and low coverage.
The Gap View
Worth the most. Collected the least.
Each dot is one requirement. It sits further right the more business value its objectives carry, and higher the more it has been satisfied. Colour shows priority. The ring shows how soon the objective is due.
Unaligned requirements
Requirements tied to no business objective are surfaced as a finding, not hidden.
Unscored objectives
An objective nobody has valued is never treated as a zero-value objective.
Evidence-backed satisfaction
Coverage is computed from linked evidence and analyst judgement, with the override on record.
Higher = more satisfied. The shaded corner is high value, low satisfaction: act there first.
- Priority
- Critical
- High
- Medium
- Low
- Due
- Overdue
- Upcoming
Requirements model
A hierarchy your analysts already think in.
- CIRCritical
- PIRPriority
- SIRSpecific
- FIRFriendly force
- EEIEssential element
- PIR-1Which threat actors are actively targeting our online banking infrastructure?Critical
- SIR-1.1Which APT groups have demonstrated capability against financial web applications?50%
- EEI-1.1.1What ransom demand ranges and negotiation patterns characterise these groups?90%
- SIR-1.2Which ransomware-as-a-service operations have hit financial institutions recently?0%
- EEI-1.2.1Which authentication flows still permit one-time-code fallback?0%
Rev 14 · append-onlyCoverage rolls up ↑
- 01
Priority and Specific Intelligence Requirements and Essential Elements of Information
CIRs, PIRs, SIRs, FIRs and EEIs, nested as deep as the work needs. Every level inherits its parent’s context and reports its own coverage upward.
- 02
Linked to the objectives they serve
A requirement can serve several objectives. Change what the business values and the whole picture reorders, without anyone rewriting the plan.
- 03
Versioned, with the history intact
Requirements and intelligence objects carry append-only revisions, so how a judgement changed is as legible as what it is now.
The platform
One place the whole cycle lives.
Plan, task, collect, assess and answer, on the same requirements, with the same record.
- 01
Collection plans
The requirement tree, its health, and what each branch is waiting on, in one view.
- 02
Source tasking
Task a source against a specific requirement and track what came back against what was asked.
- 03
Evidence and satisfaction
Link intelligence to the requirement it answers, with a weight and an analyst note on the record.
- 04
Intelligence library
STIX-aligned objects with TLP handling, relationships as first-class edges, and full revision history.
- 05
RFI portal
Requests arrive tied to a business unit and an objective, so repeated asks with nothing behind them become visible.
- 06
Analyst workbench
A review queue where proposed links and drafts are approved, amended or rejected by a person.
Built for security teams
Assume the buyer will audit you.
Your customers review vendors for a living. The platform is built on that assumption rather than retrofitted to it.
US-only infrastructure
Application, database and authentication all run in US West. No region is parameterised.
Role-based access
Admin, Analyst and a read-only Leadership role, enforced at the API rather than hidden in the interface.
Append-only audit log
Every mutation stamped with the actor who made it, written centrally rather than per feature.
Tenant isolation
Multi-tenant from the schema up, with cross-tenant access guarded and covered by tests.
Private beta · Design partners
We’re taking a small number of design partners.
If you run a threat intelligence function and the gap between what the business asks for and what actually gets collected is a live problem, we’d like to talk.
No public sign-up · US-hosted