Connection Types

DNS resolution & hierarchy

BGP & routing

WHOIS & registration

Geo

Threat intelligence & attribution

Email security & TLS

Physical infrastructure

Certificate Transparency

† CERTIFICATE — declared as an endpoint by the call above, but CALL db.labels() returns no such label. A pattern anchored on it matches nothing, at HTTP 200, with no error to tell you why.

Declared but unpopulated

None. Every edge type in this census reported rows, and none came back declaredButEmpty. There are no schema stubs to route around today.

Rows generated from CALL db.relationshipTypes() YIELD type, count, sourceLabels, targetLabels, aliasOf, declaredButEmpty against https://graph.whisper.security, fetched 2026-08-09T21:11:53Z. The counts render from that same census, so a replica disagreeing by a few million moves the number without moving the table.

Some of these planes are small enough that a zero-row result says more about Whisper's coverage than about the indicator, and reading one as evidence of absence is the most expensive mistake on this page. The row count in the table above is what tells them apart.

The ATT&CK layer is a curated reference plane, not Whisper's own attribution: 7,527 USES_TECHNIQUE and 872 USES_TACTIC edges reflect what public reporting has mapped. ATTRIBUTED_TO — the edge that would join an actor to live infrastructure — holds 4 edges on production. It answers no attribution question at scale, and an empty result from it is no-data — coverage: no-data. Not in coverage. This is not a verdict — nothing was looked at., never evidence of absence.

The three email and TLS planes are not the same size, and lumping them together hides which results you can trust: DKIM_SIGNED_BY holds 30,782 edges and DMARC_REPORTS_TO 53,736 — populated planes where an empty result usually means the domain publishes no such record. EMITS_TLS_FINGERPRINT holds 261, roughly a hundredth of either.

Coverage on this plane is partial. Expect no match on almost any indicator. A zero-row result here means Whisper holds no observation — not that the host shares no infrastructure.

Coverage on this plane is partial. github.com has none. paypal.com has none. A zero-row result here means Whisper holds no CT observation for that host. It never means the host has a clean certificate history. If certificate history is load-bearing for your decision, query a CT log directly — crt.sh or the Google CT API — and come back with the hostnames you find.

Edge types come in two kinds, and the distinction changes how you write the query. Read the split from the engine rather than from a list here: CALL db.schema('json') marks every edge type virtual: true or false. Measured 2026-08-09, that call reported 20 physical and 30 virtual.

Physical edges are materialized on disk — the DNS, geo and SPF sets, and most of the WHOIS set. An unanchored MATCH ()-[r:RESOLVES_TO]->(h) returns rows.

Virtual edges are synthesized by the VDP layer at expand time and are not in the physical store: the routing set, the whole threat and attribution set, the DMARC/DKIM/TLS-fingerprint edges, SEEN_IN_CT, and the physical-infrastructure set. BELONGS_TO is mixed — the IP → PREFIX side is stored, the FEED_SOURCE → CATEGORY taxonomy hop is synthesized — and the engine treats it as virtual when it plans a traversal. Two rules follow:

• Label or anchor at least one endpoint. A pattern with both ends bare is refused, not answered: MATCH (a)-[:LISTED_IN]->(b) RETURN a.name, b.name returns HTTP 400 query-unservable, naming the edge type and explaining that an unanchored scan of a synthesized layer would return zero rows. Label one end — MATCH ()-[:LISTED_IN]->(f:FEED_SOURCE) — and it answers.
• Write them as explicit single hops. Variable-length expansion over a synthesized edge is expensive, not broken: it will not finish on a wide plane. Stage the hops with WITH instead.

ROUTES and HAS_NAME do appear in db.relationshipTypes() with real counts — read them off the table above. Anchor them and they work.

Danger — count(r) lies on three edge types. MATCH ()-[r:LISTED_IN]->() RETURN count(r) returns 0 at HTTP 200 in milliseconds, while db.relationshipTypes() reports 10,931,701 LISTED_IN edges. ANNOUNCED_BY and CONFLICTS_WITH do the same. Read the count from CALL db.relationshipTypes() YIELD type, count or GET /api/query/stats — never from count(r).

CALL db.schema() in its default form attaches a traversalHints list to 31 of the 51 relationship rows — copy-pasteable starter patterns, and not one per virtual type as this page used to say. Check a hint before you trust it. One of them anchors on CERTIFICATE, a label CALL db.labels() does not return, so running it verbatim gives you zero rows at HTTP 200 and no error at all (measured 2026-08-09). The db.schema('json') form carries no hints. See Best Practices for the full set of query rules.

CALL db.relationshipTypes() YIELD type, sourceLabels, targetLabels
RETURN type, sourceLabels, targetLabels ORDER BY type

db.relationshipTypes() lists every edge type with the source and target labels observed on it, and it is cheap — it answers immediately. Checking it first — alongside db.labels() — is the fastest cure for silent empty results from a mistyped edge name.