Methodology

How StrataDB collects its evidence

StrataDB records which vendors and technologies companies use from public sources, and keeps each kind of source apart so every claim can be traced to the page it came from and the day we read it. This page says where the evidence comes from, how it is graded, how often it is read again and what it can miss.

Where the evidence comes from

• Subprocessor lists and DPAs. Many companies publish the vendors that process their customers' data, often next to their data processing agreement. StrataDB-Bot looks for that list on the company's own site, reads it, and records each vendor as declared. It is the strongest evidence we hold, because the company states it itself, and it shows backend vendors nothing else can see.
• Privacy policies. Vendors named in a privacy policy are recorded as mentioned, with their role when the policy makes one clear.
• Websites and detected tags. We render the company's homepage in a headless browser and record the scripts, tags and services it loads, the mail provider in its DNS and the job board it runs. These are detected, and each keeps the signal we saw.
• Job postings. Once a day we read the company's postings from public job board APIs, such as Greenhouse, Lever and Ashby. Technologies they ask for are recorded as hiring, as required or preferred. Personal data is removed from postings before they are stored, and only postings seen in the last 90 days count.
• Certification registries. A certification is either an official registry listing or the company's own statement. The only registry we read today is the FedRAMP Marketplace, matched by the exact website in its record. SOC 2 and HIPAA have no public registry, so for them we hold only what the company states on its own website, quoted as written. How to read certifications.

Companies enter the queue from public lists such as Wikidata, Common Crawl and the Tranco ranking, from our sister products Fundup AI and VCinfo, from the vendors we already track, and from customers asking us to read a company. Entering the queue publishes nothing: only evidence does.

How a name is accepted

• A vendor name we publish has to appear in the text of the source page. A name a model produced that is not on the page is dropped.
• A subprocessor list is accepted when a table parser and a language model read the same names, or when two separate models do. A name only one of them found is not published.
• In a privacy policy each name stands on its own: it is published only if both models found it on the page, and a role only if both agree on it.
• A self-declared certification is kept only when two models agree that the page says the company itself holds the standard, not that it helps customers with it, is working toward it or relies on a provider that holds it.
• When a page cannot be validated, we show nothing rather than guess.

Evidence types and confidence

The four kinds of evidence are never blended into one source. Each gives a claim a weight:

For a company and a vendor, each kind of evidence counts once, at its strongest. The weights combine so that agreeing sources raise a claim without any one of them counting twice: confidence is one minus the product of one minus each weight. The level reads that number: confirmed from 0.90, likely from 0.60, and possible below.

Detected and hiring evidence fades as it ages: it keeps its full weight for 30 days after we last saw it, then loses weight steadily until, at 180 days, it counts half. A declaration or a mention stays at full weight until the company withdraws it. Reading the evidence in the API.

How often it is updated

• A subprocessor list, privacy policy or homepage we have found is read again about once a week. We fetch one page at a time per domain.
• A page we could not find is looked for again after about 30 days. A list is marked as not found, gated or blocked only after two reads in a row miss it.
• Job boards are read once a day. The FedRAMP Marketplace is read once a week.
• Every claim carries the date it was first seen and the date it was last seen, on the site and in the API.

How changes are counted

The first read of a list is a baseline: nothing on it counts as added, we just started looking. After that, a vendor counts as added when a list names it for the first time, and as removed when a list we read no longer names it; removed evidence is kept in the change history, not deleted. A list that loses more than half of its names at once is usually a redesign, so it is held until the next read shows the same list.

What it can miss

• Absence proves nothing. Coverage is partial. Not finding a vendor never means a company does not use it.
• Private and gated lists. Many companies share their subprocessor list only on request, under NDA or behind a login. We do not collect those, and we say so: the list status is gated or not_found.
• Blocked sites. We follow robots.txt and do not get past bot protection. A site that does not let us read it stays unread.
• Only what the browser sees. Website detection finds what a homepage loads. Backend tools, internal systems and scripts loaded only after a login or a consent choice do not show up there.
• Hiring is intent. A job posting shows what a team works with or wants, not that the company has bought it.
• Delay. A change is seen only when the company updates its page and we read it again, so it can lag by a week or more.
• Certifications. A company's statement is not verification, a certification may not cover every product a company sells, and not finding one never means the company lacks it.

We also sort companies into industries from their own homepage. That is our classification, kept apart from the evidence, and it can be wrong.

How StrataDB Research uses this

Each post states its data source, the period it covers and how its numbers were computed, in a "Data & method" box at the top. Posts are drafted with AI assistance from StrataDB data and reviewed by the StrataDB team before they are published. If a number looks wrong, write to hello@stratadb.io.

The four sources at a glance: Data sources and grading. How our crawler behaves: StrataDB-Bot.