Explainability

Most results carry an evidence object, placed first in the result, that shows why the company matched. Evidence confirms the filters you sent against the company's data; it is not a readout of the company. It surfaces only what you couldn't already reconstruct from your query, such as which snippet matched a text search, and stays silent on the plain structured gates you already know you asked for.

What evidence is, and what it never does

Evidence shows the piece of a company's data that proves a condition you set. It never returns data you didn't ask about, and it never returns an attribute's value on a check that failed or was negated. To retrieve a company's actual data, use the Match & Enrich API, Firmographics, or Location Intelligence.

The evidence object is omitted entirely when there's nothing to show (for example a segmentation built only from firmographic gates).

How much is shown

Evidence shows the minimum that proves a condition, following the logic of the condition itself:

• "Any of these" (an or, or a membership in): proven by a single value. One match is shown even if several qualified, picked deterministically: the first value in your query that the company satisfies.
• "All of these" (and, or several and clauses on one attribute): one match per part.
• A negation (not_in, or an exclude block): nothing to show. The confirmation is the absence of a match, so nothing is surfaced and nothing leaks.

One entry per attribute. Clauses on the same attribute collapse into a single entry, keyed by the attribute name; the attribute and relation are never echoed back, and the entry combines the matches from each clause. So company_business_model in:[A] AND in:[B] shows both values, while company_business_model in:[A, B] shows one.

Where evidence appears, by module

The two shapes this produces:

• In supplier_discovery and segmentation, each entry maps the attribute name straight to its evidence, with no wrapper.
• In company_verification, each entry is wrapped as { "matched": <bool>, "value": <evidence | null> }: value is the matched evidence on a pass, and null on a fail or a negation.

Evidence shapes

Whatever the module, a single attribute's evidence takes the same shape:

In company_location evidence, location_role is main (the company's HQ) or secondary (any other location), and distance_km is added on a within (proximity) match.

Examples

Each module below shows the exact evidence shape for a query from the module's own page.

company_lookup returns no evidence object. A result is a ranked candidate list:

{
  "veridion_id": "…",
  "company_name": "AstraZeneca plc",
  ...
}

supplier_discovery shows evidence for the text matches only, so only company_products produces evidence:

"evidence": {
  "company_products": {
    "matched_snippets": ["…industrial battery energy storage systems…"],
    "supplier_types": ["manufacturer"],
    "product_context": { 
        "name": "Energy storage system", 
        "url": "…", 
        "description": "…" 
    }
  }
}

segmentation has the same shape, but only company_keywords can produce evidence. A keyword-themed segmentation (for example mapping the green-hydrogen market) carries just the keyword match, while the NAICS, location, and founding-year gates stay silent. A purely firmographic segmentation (like the DACH SaaS example on the segmentation page) returns no evidence object at all:

"evidence": {
  "company_keywords": { 
    "matched_snippets": ["…green hydrogen production and electrolyzer systems…"] 
  }
}

company_verification returns a verdict for every filter. In the KYB onboarding query example, each self-reported claim gets a pass or fail. Note that the two company_business_model clauses (SaaS and B2B) collapse into a single entry:

"evidence": {
  "company_website": { "matched": true, "value": "highnote.com" },
  "company_type": { "matched": true, "value": ["Private"] },
  "company_business_model": { "matched": true, "value": ["Software-as-a-Service", "Business-to-Business"] },
  "company_year_founded": { "matched": true, "value": 2019 },
  "company_employee_count": { "matched": false, "value": null },
  "company_location": { "matched": true, "value": [{ "address_string": "…San Francisco, CA, US", "location_role": "main" }] }
}

When a check fails or a negation holds, value is null: a failed check reads { "matched": false, "value": null }, and a not_in negation that passes reads { "matched": true, "value": null }.