A row of company data looks uniform: a domain, a team size, a founder's name, an email address. The columns are not equally true. Some were read off a page the company controls, some were worked out from evidence, and some were produced by applying a rule to a name. A dataset that does not say which is which hands the reader a guess formatted as a fact.
Three layers: stated, derived, constructed
The distinction this cluster is organised around:
| Layer | What it is | Example |
|---|---|---|
| Stated | A value the source publishes | A YC company's domain, batch and team size |
| Derived | A value inferred from published evidence, with a count of that evidence | first.last, matched from 20 company addresses in commits |
| Constructed | A value produced by applying a rule to a name | A founder address built from that pattern |
The constructed layer is only as good as the derived one beneath it, and when nothing was derived, the rule falls back to a default — the most common format for the company's mail provider. Both Actors in this cluster label that case explicitly, with an inferred flag and a confidence between 0.05 and 0.10, because it is the case that gets mistaken for data.
What the YC directory states
Y Combinator's public directory listed 6,267 companies on 1 October 2026. For each one it states a name, website, one-liner, batch, status, stage, team size, industries, tags and regions; the company page adds founders with title, bio and social links, open jobs, news and launch posts. The Y Combinator Scraper measured how often those are filled on 80 Latin American companies: domain on 100%, company LinkedIn on 93.8%, founder LinkedIn on 99.4% of 80 founders. The walkthrough is in how to scrape the Y Combinator companies list.
What the directory does not state is a founder's email. The founder profile carries a hasEmail flag and nothing else. Every founder address in any YC-derived dataset was therefore constructed, by this Actor or by whoever built the dataset.
Where an email pattern comes from
A pattern is derived when real addresses on the company's domain can be lined up against the names of the people who use them. The two Actors look for that pairing in different places:
| Source of evidence | Measured on | Pattern backed by evidence |
|---|---|---|
| Emails the company published on its YC pages | 80 Latin American YC companies | 6 of 80 (7.5%) |
| Commits in the company's public GitHub organization | 44 companies whose organization was found, of 46 | 38 of 44 (86.4%) |
The two rates are not a ranking of the tools; they measure different populations. The GitHub sample was 46 tech companies chosen before measuring, which skews toward companies that commit in public. What the comparison does show is where evidence tends to exist: engineers commit with their work address far more often than a startup prints a named address on its directory page. The mechanics are in finding a company's email format from GitHub commits.
An MX record is not a verified address
Both Actors resolve the domain's MX records over DNS. That answers two questions: is mail for this domain routed anywhere, and to which provider. RFC 5321 makes the MX lookup the first step any sending server takes, so it is the cheapest true thing to know about a domain's mail.
It does not answer whether ana.perez@ exists. That requires opening a connection to the mail server and asking, which both Actors refuse to do, so catchAll is always null rather than estimated. The same limit — DNS tells you about infrastructure, not about the people behind it — runs through what a nameserver can and cannot tell you.
Which Actor answers which question
| Question | Actor | Primary price |
|---|---|---|
| Which YC companies match a region, batch or tag, and who founded them? | Y Combinator Scraper | $0.008 per company with founders and jobs |
| What email format does a company I already know use? | Company Email Pattern Finder | $0.03 per domain with a GitHub organization |
They compose: the YC Actor's domain column, filled on every company row, is exactly the input the pattern finder takes. Running the second on the domains where the first returned inferred: true replaces guesses with evidence where any exists.
Founders are people
A founder row is personal data under the GDPR regardless of how professional the context is, and a constructed address is personal data as much as an observed one. That is why the YC Actor withholds founders of EU, EEA, UK and Swiss companies by default, and why the pattern finder returns company-level data unless asked otherwise. The legal texts, and what they require of whoever runs outreach on this data, are set out in founder data under the GDPR and CCPA. For contrast, the Wellfound Actor draws the line further back and does not read people at all — the startup data that Actor will not collect. Every rate on this page carries its sample for the reason given in publishing measured fill rates.