Data Model
Babel organises threat intelligence into eight entity types. Every entity is traceable to at least one source report, and entities are connected through typed, confidence-labeled edges.
Entity types
| Entity | Description |
|---|---|
| Actors | Named threat groups with confirmed attribution — nation-state, cybercrime, hacktivist, PSOA |
| Clusters | Unattributed activity sets tracked by behaviour. Can be graduated to Actor once attribution is confirmed. |
| Campaigns | Named operations with defined timeframes, target profiles, and objectives |
| Tools | Malware, implants, C2 frameworks, and utilities — each typed by role (backdoor, ransomware, loader...) |
| Indicators | IPs, domains, hashes, URLs, and emails extracted from reports and enriched automatically |
| TTPs | MITRE ATT&CK techniques and sub-techniques, linked to the actors and tools that use them |
| CVEs | Exploited vulnerabilities with CVSS scores and links to the actors observed exploiting them |
| Reports | Source intelligence documents — the immutable ground truth that every entity and edge links back to |
Actors vs Clusters
Babel separates Actors (confirmed attribution — known nation, motivation, country) from Clusters (activity tracked by behaviour alone, not identity). This mirrors the UNC/DEV/Storm model used by Mandiant, Microsoft, and CrowdStrike.
When an analyst confirms attribution, a cluster can be graduated to an actor — the data migrates, edges are preserved, and the original cluster ID is aliased.
Relationships
| Relationship | Direction | Meaning |
|---|---|---|
documents | Report → Entity | A report discusses or attributes this entity |
attributed_to | Campaign / Cluster → Actor / Cluster | A campaign or activity cluster is attributed to a named actor or cluster |
sub_group_of | Actor → Actor | A named actor is a functional sub-unit of another actor |
collaborates_with | Actor / Cluster ↔ Actor / Cluster | Joint operation or coordinated attack between peer groups |
successor_of | Actor / Cluster → Actor / Cluster | The group continued from or rebranded from the other (shown on the site as lineage) |
code_reuse_of | Actor / Cluster → Actor / Cluster | The group reused the other's code, payloads, or leaked source |
overlaps_with | Actor / Cluster → Actor / Cluster | A vendor explicitly states that two designations overlap or correspond; the edge keeps the vendor's words. |
possible_connection | Actor / Cluster → Actor / Cluster | The source describes a hedged or unconfirmed link ("may be related") |
hijacked_infrastructure_of | Actor → Actor | The group abused infrastructure belonging to the other |
marked_similar | Actor / Cluster ↔ Actor / Cluster | A Babel reviewer marked the pair as similar, with a written reason. Not an identity claim. |
hands_off_to | Actor → Actor | IAB handoff — one actor passes access to another |
uses_tool | Actor / Cluster / Campaign → Tool | The group uses this malware or framework |
uses_ttp | Actor / Cluster / Campaign / Tool → TTP | MITRE ATT&CK technique observed in use |
exploits | Actor / Cluster / Campaign → CVE | Vulnerability observed being exploited |
drops | Tool → Tool | Malware delivers or installs another payload |
communicates_with | Tool → Indicator | C2 communication — malware contacts an IP, domain, or URL |
contains_indicator | Report → Indicator | Indicator appears in this report (provenance) |
has_indicator | Actor / Cluster / Tool → Indicator | Pipeline-generated — not a stated relationship in a report |
has_indicator edges are written by the ingest pipeline, not extracted from report text. They link an actor, cluster, or tool to each indicator attributed to it.
Reports also carry uses_tool, uses_ttp and exploits edges to the tools, TTPs and CVEs they mention. These record provenance only.
Auto-linked edges
When a report is ingested, the pipeline writes a set of shortcut edges in addition to the LLM-stated relationships. These are called auto-linked edges and are flagged with auto_link: true in the API response.
Auto-linked edges connect the primary actor or cluster of a report directly to the tools, TTPs, CVEs, and indicators documented in the same report. They exist so that querying an actor returns its full observable footprint without requiring traversal through every intermediate report or campaign node.
When a report covers two or more primary actors or clusters, an auto-linked edge is written only where the report itself links that group to the item. Items the report does not tie to a specific group are not linked to any of them.
| Edge | Written when |
|---|---|
has_indicator | Actor / Cluster → Indicator: for each indicator the report attributes to this actor or cluster. When the same report attributes that cluster to a named actor with at least "assessed" wording, the actor gets the edge too. Indicators with no stated owner are linked to the report's primary group, under the multi-group rule above. |
has_indicator | Tool → Indicator: for each indicator the report ties to a tool |
uses_tool | Actor / Cluster → Tool: for each tool documented in the report |
uses_ttp | Actor / Cluster → TTP: for each TTP in the report not already covered by a stated campaign edge |
exploits | Actor / Cluster → CVE: for each CVE documented in the report |
Confidence labels
Every edge carries a confidence label that reflects how certain the relationship is, based on the language used in the source report:
| Label | Meaning |
|---|---|
| Confirmed | Directly stated in the source with no ambiguity ("confirmed", "definitively") |
| High confidence | Strong assessment by the source ("high confidence", "strongly assessed") |
| Assessed | Standard attribution language ("assessed", "attributed") |
| Suspected | Moderate certainty ("suspected", "likely") |
| Possible | Low certainty or speculative ("possible", "may") |
See the Methodology section for a detailed explanation of how confidence labels are assigned.