Observable infrastructure
Datazag focuses on public internet signals such as domains, DNS, certificates, hosting, ASN context, routing and provider footprints.
Trust & Governance
Use infrastructure intelligence you can inspect and govern.
Datazag products are built around observable internet infrastructure, explainable evidence, controlled product scope and clear licensing boundaries.
This page explains the trust model behind reports, alerts, APIs, data shares, marketplace datasets and partner-delivered services.
Buyer assurance
Evidence, scope and licence clarity
Trust comes from knowing what is included, what is excluded, how output can be used and where human review or contractual approval is needed.
Trust dimensions
Evidence
Reason codes
Licensing
Privacy
False positives
Data shares
Partner use
Governance
Trust principles
Evidence first. Scope explicit. Rights controlled.
Buyers need more than a data feed. They need to understand what evidence supports the output, how it can be used and where the boundaries sit.
Evidence over black boxes
Reports, alerts and enrichment outputs include evidence, reason codes and context so teams can inspect why a finding exists.
Product-specific scope
A free report, alert, API response and data share do not expose the same fields. Each product has its own scope, use case and delivery controls.
Clear licensing boundaries
Datazag separates internal intelligence operations from sellable data products, partner services and marketplace-ready outputs.
What customers can inspect
The evidence behind reports, alerts and data products.
The exact fields vary by product, but Datazag output is designed to expose enough context for a buyer to understand and challenge the result.
Observed facts
Domain, DNS, certificate, mail, hosting, ASN, prefix, registrar and provider context that supports a report or alert finding.
DomainsDNSCertificatesASNProviders
Reason codes
Readable explanations of why a domain, IP, infrastructure relationship, platform pattern or posture issue was considered relevant.
Risk reasonsPosture reasonsAlert reasonsEvidence fields
Confidence context
Signals that help teams decide whether to automate, block, investigate, de-escalate, monitor or route to human review.
ConfidenceSeverityRoutingReview path
Known-good and provider context
Cloud, CDN, mailbox, hosting, platform and customer-approved context used to reduce accidental over-classification.
CloudCDNMXNSAllowlists
History and change
Where included, point-in-time records and change history help buyers understand what changed and when it changed.
SnapshotsDeltasTime travelChange detection
Product controls
Different products expose different slices of the intelligence layer.
A report, alert, API response and cloud data share can draw on the same intelligence foundation, but each has its own field scope and intended use.
Reports
Designed for business-readable findings, DNS defence analysis, threat exposure, remediation priorities and portfolio summaries.
Alerts
Designed for operational delivery with alert class, reason codes, infrastructure context, recommended action and de-escalation paths.
API
Designed for real-time scoring and enrichment inside customer products, analyst workflows and partner platforms.
Cloud data shares
Designed for analytical joins, historical review, data science, threat hunting and marketplace-style consumption.
Partner services
Designed so MSSPs, ESPs and service providers can package intelligence into their own services without reselling raw data by default.
Licensing and permitted use
Built for operational use, not uncontrolled raw data resale.
Licensing should be simple to understand: use the intelligence in the contracted workflow, but do not redistribute raw data or extend rights to downstream partners without agreement.
Included by default
- • Use Datazag outputs inside the licensed product or workflow.
- • Use reports, alerts and enrichment to support internal decisions and customer-facing managed services where contracted.
- • Use permitted fields, schemas and delivery routes defined for the product purchased.
Not included by default
- • Raw data resale, bulk redistribution or standalone sublicensing.
- • Publishing Datazag data into another marketplace or public dataset.
- • Allowing downstream resellers, franchisees or channel partners to use or resell Datazag-powered services without written approval.
Handled by agreement
- • Partner-branded reporting and portal features.
- • Portfolio-wide or multi-client use cases.
- • Marketplace, data-share, white-label and downstream partner rights.
Privacy and customer context
External intelligence with clear customer-input boundaries.
Most Datazag products focus on externally observable infrastructure. Customer-supplied context is used to make the output more relevant and reduce noise.
Public internet data
Most intelligence products are built from externally observable infrastructure, not from customer inboxes, endpoint telemetry or private network traffic.
Report requests
For free reports, the submitted work email is used to derive the domain, process the request and deliver the report.
Marketing consent
Marketing follow-up should be separate from the processing needed to generate a requested report.
Customer context
Customer-supplied brands, domains, watchlists or approved baselines are used to make outputs more relevant and reduce false positives.
False-positive controls
Useful intelligence needs tuning and challenge paths.
Security teams need confidence that platform names, brand terms and provider patterns are not being treated as malicious without context.
Known-good infrastructure
Provider attribution, customer-approved infrastructure and common platform footprints help avoid obvious misclassification.
Context before action
A platform or brand term alone should not determine severity. DNS, certificate, hosting, history and relationship signals change routing.
De-escalation path
Operational products can include review and de-escalation workflows so accepted or known-good findings do not remain noisy.
Human-readable evidence
Reason codes and evidence fields give analysts and customers a way to challenge, validate or tune the output.
Marketplace and data-share boundaries
Data products are controlled at publish time.
Cloud marketplace and data-share buyers need to know what is included, what is excluded and what redistribution rights do not come with the product by default.
Derived intelligence
Marketplace and data-share products should expose derived Datazag intelligence, public infrastructure facts and product-approved context.
Restricted inputs
Internal-only feeds, restricted popularity data and raw third-party threat-feed rows are not published as standalone resale fields by default.
Schema discipline
Published datasets need explicit field scope, refresh cadence, historical coverage and licensing boundaries.
Buyer clarity
Customers should be able to understand what the dataset contains, how it can be used and what redistribution is not permitted.
Next step
Use intelligence with evidence and boundaries.
Start with a report or alert workflow, then agree the product scope, delivery route and permitted use that fits your team, partner model or data-share requirement.