Technical answers for
Internet-scale decisions

Internet Mapper does not treat a single feed as a complete account of Internet state. It combines real-time BGP route and path-vector observations with active IPv4 and IPv6 reachability measurements, then connects those signals to prefixes, autonomous systems, endpoints, paths, providers, and changes over time. ‘Verified’ means that graph relationships are evaluated against multiple forms of observed evidence; it does not mean that every inferred relationship is guaranteed to represent the forwarding path of every packet.

At a high level, the knowledge graph connects BGP autonomous systems, 3M prefixes or subnets, IPv4 and IPv6 addresses, route and path vectors, observed reachability, infrastructure and provider context, and time-dependent topology changes. Relationships support traversal of routing, path, reachability, dependency, transit, concentration, chokepoint, and potential blast-radius questions. Internet Mapper does not publish the complete production schema, field list, or access-specific attribute model.

It depends on the edge type. Internet Mapper preserves the distinction between observed, contextual, and derived relationships: a BGP adjacency or AS-path relationship is control-plane evidence; an active measurement is probe evidence; a provider, ownership, or geographic association is contextual metadata; and an analytical dependency is derived. These are attributable evidence classes, not interchangeable claims about physical connectivity. Detailed customer-visible provenance labels and edge-field definitions are not published.

A derived dependency or chokepoint is an evidence-backed analytical result, not an absolute statement about all traffic. Internet Mapper evaluates source observations, recency, geographic and network diversity, repeatability, and agreement between routing and active measurements. This keeps directly observed facts distinct from derived risk indicators. Customer-visible confidence scores, evidence counts, and model-version details are not published.

Internet Mapper observes routing control-plane signals such as prefix announcements, withdrawals, origin autonomous systems, AS-path vectors, and changes in route visibility. The platform uses 500 globally distributed BGP route and path-vector crawlers at effective Internet locations, including all major Internet exchanges, to build a broad view of how routes are being advertised and how those views change.

No. A BGP AS path is a control-plane path vector associated with a route advertisement. It is evidence about how reachability is advertised between autonomous systems, but it does not by itself prove the exact data-plane path for a packet, account for every internal hop, or guarantee endpoint availability. Internet Mapper pairs routing observations with active reachability evidence so these questions are not collapsed into one signal.

Every BGP collector or crawler sees routes from its own network position and peers. A route can be visible from one location and absent, filtered, or different from another. Internet Mapper’s distributed observation footprint reduces single-vantage-point bias, but no finite set of observers can claim omniscient visibility into every private policy, peering session, or forwarding decision.

Internet Mapper surfaces origin changes, route-leak indicators, unexpected path shifts, withdrawals, and related routing changes, then correlates them with active reachability for investigation. A routing anomaly is evidence for analysis—not automatic proof of malicious intent. Investigation incorporates authorized origin data, routing policy, timing, affected prefixes, propagation, and measured impact. Detection thresholds, alert timing, policy controls, and RPKI/ROA implementation details are not published.

Internet Mapper continuously ingests and analyzes live BGP route and path-vector changes in real time rather than relying on periodic snapshots. Numeric source-to-ingestion, graph-update, UI, API, and alert-delivery latency commitments are not published.

An observation records a signal already present at an observation point—for example, a BGP announcement or withdrawal. A probe initiates a measurement toward a target and records the resulting response or non-response from a specific source, time, protocol, and configuration. Observations describe advertised control-plane state; probes test an aspect of data-plane reachability. Neither substitutes for the other.

Not necessarily. A successful probe establishes that the tested target responded under the probe’s specific conditions. It does not automatically prove application correctness, user experience, performance from every geography, or availability over untested protocols. Likewise, a non-response can reflect filtering, rate limiting, policy, transient loss, or probe-path conditions rather than a failed host.

Internet Mapper continuously verifies 10 billion active IPv4 and IPv6 addresses. This is an aggregate coverage figure; Internet Mapper does not publish the IPv4/IPv6 split, target-selection rules, probe protocols, source-vantage distribution, exclusions, or per-target measurement cadence. IPv4 and IPv6 results remain distinct because the two address families can have materially different routing, filtering, peering, and service exposure.

Internet Mapper uses repeated measurements, distributed vantage points, temporal correlation, protocol-aware interpretation, and comparison with routing changes before escalating a conclusion. A single failed probe is not treated automatically as a global outage, and a single successful probe does not erase evidence of regional or provider-specific failure. Detailed retry, quorum, suppression, and uncertainty thresholds are not published.

Internet Mapper uses controlled measurement rates, maintains exclusion and opt-out handling, supports abuse response, and avoids unsafe amplification and intrusive application behavior. Specific probe-identification methods, rate limits, exclusion mechanics, and protocol boundaries are not published.

It means a navigable, time-aware model of observed Internet routing, reachability, and connected dependencies. Teams can explore how autonomous systems, prefixes, endpoints, routes, and paths relate; compare state across time; and analyze the potential operational effect of changes. It is a model built from measured evidence—not a claim to reproduce every router, private link, policy decision, or packet in the global Internet.

Internet Mapper's time-dependent knowledge graph supports comparison of historical routing, reachability, topology, and dependency state so teams can investigate how conditions changed before, during, and after an event. Internet Mapper does not publish the available history window, replay granularity, raw-evidence availability, time-zone handling, late-arriving-data behavior, or aggregation policy.

Internet Mapper supports graph traversal and centrality analysis to identify concentrated transit dependencies, highly connected infrastructure, fragile chokepoints, shared failure domains, and potential blast radius. Teams can examine which prefixes, services, regions, or providers may be exposed if a dependency changes or becomes unreachable. These results describe modeled exposure; operational decisions validate that exposure against current routing and active measurements. Specific algorithms, weighting options, depth limits, scenario controls, and export formats are not published.

No. Internet Mapper does not claim deterministic outage prediction. The digital twin supports detection, investigation, and modeled exposure analysis by revealing changing dependencies, abnormal route behavior, reachability degradation, fragile chokepoints, and potential blast radius. These signals support earlier investigation and better preparedness, but they are not a guarantee that an outage will or will not occur.

Internet Mapper uses cross-signal validation: route and path-vector observations are evaluated alongside active IPv4/IPv6 reachability, source provenance, time, and graph context. The platform also applies source-health monitoring, stale-data handling, normalization, deduplication, and conflict management before presenting results. Detailed thresholds and resolution rules are not published.

Internet Mapper applies governed retention and deletion practices across routing observations, active measurements, graph state, aggregates, alerts, customer activity, audit records, and backups. Retention supports incident reconstruction, trend analysis, audit evidence, and comparison of topology over time. Internet Mapper does not publish retention durations, regional storage commitments, deletion timing, backup expiration, or customer-configurable policy details in this FAQ.

Internet Mapper applies least-privilege and role-based access principles, tenant isolation, scoped credentials, session controls, administrative review, and audit logging to protect customer workspaces and operational data. Customer queries, saved analyses, annotations, exports, and integration credentials are treated as sensitive even when underlying Internet observations come from broadly visible sources. Specific SSO providers, MFA policy, role definitions, token scopes, audit-log coverage, retention, and security attestations are not published in this FAQ.

Security teams use Internet Mapper to correlate route-origin and path changes with active reachability, investigate possible hijacks and leaks, identify exposed infrastructure dependencies, assess provider or regional disruptions, and prioritize incidents by affected assets and likely blast radius. Internet Mapper supplies network evidence and context that teams combine with their asset inventory, authorization data, telemetry, and incident procedures.

Compliance and risk teams use Internet Mapper to document external network dependencies, identify sovereign paths and transit relationships that create jurisdictional exposure, support third-party and concentration-risk reviews, and preserve time-stamped evidence for control testing and incident reconstruction. The platform informs compliance assessments; it does not determine legal compliance or replace counsel, policy ownership, or an auditor’s judgment.

Yes. Sovereign Path Analysis combines observed routing and path evidence with contextual jurisdiction, ownership, provider, and exchange data to identify where Internet dependencies intersect locations or networks relevant to an organization's policy. Internet Mapper preserves the distinction between observed evidence and contextual interpretation. A BGP path is not a packet-level guarantee, geolocation and ownership data can change, encrypted traffic content is not inferred from routing metadata, and the analysis informs compliance and risk assessment rather than declaring legal compliance. Specific data sources, update cadence, policy controls, report fields, and evidence-retention mechanics are not published in this FAQ.

Internet Mapper provides Platform Access for interactive exploration. API, export, alerting, and integration access are available based on each customer's access configuration. Each access method exposes its own fields and freshness characteristics. Specific APIs, query languages, authentication methods, limits, pagination, streaming, webhooks, quotas, formats, and service commitments are not published in this FAQ.

Internet Mapper applies resilience principles that include redundancy, recovery planning, backup practices, dependency management, incident communication, maintenance planning, and support escalation. Numeric uptime, service-region, RTO, RPO, incident-notification, and support commitments are not published in this FAQ; customer-specific agreements define those commitments.