Supported Coverage

Evaluate source and destination coverage with explicit caveats instead of broad promises.

For buyers comparing pack coverage, semantic fit, and what still depends on scope, credentials, or follow-through.

Talk to an Implementation Reviewer All Docs Paths

Supported Coverage

Which sources, destinations, and pack behaviors are in scope today?

Which sources, destinations, and pack behaviors are in scope today?

Audience

Which sources, destinations, and pack behaviors are in scope today?

Solution architects, integration owners, and technical buyers.

Supported Coverage

Source and destination coverage must include caveats.

Data-pack availability is not the same as universal authority. Each source contributes evidence according to its credentials, network position, source API, and semantic contracts.

Cloud and virtualization AWS, Azure, Google Cloud, VMware, Hyper-V, OpenStack, Kubernetes, Nutanix, Terraform-style state. Cloud project/account/region, interface, IP, firewall, volume, and VM relations depend on provider metadata and committed evidence.
Identity and endpoint Intune, Entra ID, Active Directory, Jamf, Okta, Microsoft 365, Linux, Windows, and macOS host evidence. Users, groups, ownership, software catalog, and installation claims need per-source identity or per-device evidence.
Discovery, DNS, and network Nmap, DNS/AXFR, SNMP walk, IP ranges, Cisco, Meraki, Palo Alto, FortiGate, Infoblox, and Napalm-style data. Discovery-only records are observed hosts/services until correlated with authoritative lifecycle evidence.
Monitoring and operations Zabbix, PRTG, Splunk, Datadog, New Relic, Nagios, ServiceNow, Veeam, Ansible inventory, and operational exports. Monitoring observations show what is monitored; they do not automatically prove asset ownership or managed inventory authority.
Destinations and publication Native estate explorer plus recipient-native destination packs such as CMDB, ITSM, ITAM, DCIM, and workflow platforms. Destination exports should use committed estate subsets and recipient-native schemas rather than one platform's preferred model.

Data Packs

Package source knowledge as reusable integration behavior.

A data pack owns the source-specific lens: connection fields, setup guidance, source samples, runtime dependencies, semantic mappings, relation contracts, validation rules, and source-specific normalization.

Minimal manifest

source: acme_rmm
title: ACME RMM
summary: Customer endpoint data pack.
version: 1.0.0
connection_fields:
  - url
  - token
capabilities:
  - endpoint_inventory
  - software_inventory
mappings:
  hostname: device_name
  serial: serial_number
  vendor: manufacturer

Uploaded packs should not contain stored connection secrets. Licensed distribution is enforced by signed license features when licensed packs are downloaded from the distribution catalog.

Next Step

Move from documentation to a scoped review.

Use the implementation reviewer path when you want to turn this page into a concrete source, deployment, or assurance discussion.

Talk to an Implementation Reviewer

Next Step

Pair this doc page with proof, fit, and one scoped follow-up.

A documentation page should answer its question and then route the visitor to the proof artifact, coverage page, or reviewer path that finishes the evaluation.

Proof

Inspect the corresponding artifact Use the proof library to connect the written explanation to a real product surface or public-safe sample. Browse Proof Library

Coverage

Validate support and caveats Use the coverage pages to confirm what is modeled already and where scope still matters. Open A Coverage Category

Contact

Route the next technical question Escalate to an implementation reviewer only after this page made the remaining blocker explicit. Talk to an Implementation Reviewer