Train and ground your models on the whole company universe
Models learn the distribution you hand them. Canonical delivers the complete verified company dataset into your own storage, so training and retrieval run against the full population instead of whatever a rate limit let you collect.
01 — The problem
Where this breaks down today
Teams building AI products over company data hit the same wall. The model is only as good as the corpus behind it, and the corpus is being assembled one API call at a time. A few hundred thousand calls in, you have a sample shaped by your rate limit rather than by your problem, and every training run reads from a slightly different slice of it.
Bulk delivery removes the collection step entirely. The complete company dataset — verified profiles with firmographics, funding, investors, founders, and headcount — lands in your S3 bucket, Snowflake account, or BigQuery dataset, ready to feed a training pipeline, an embedding job, or a retrieval index you own end to end.
Assembling a training corpus through a search or enrichment API means paying per row for data you intend to read thousands of times. Rate limits stretch collection over weeks, so the corpus ends up stitched together from different points in time. Retries and partial failures leave gaps you cannot distinguish from genuine absences. And when a reviewer asks why the model behaves oddly on mid-market European companies, you have no way to tell whether the pattern is real or an artifact of which calls happened to succeed.
02 — Why bulk delivery
Why an API per record is the wrong shape
Training and retrieval are read-heavy, repeated, and offline — precisely the workload a per-call API handles worst. A model also needs the negative class: the companies that do not match, which no query returns because you never thought to ask for them. Embeddings have to be regenerated over the entire corpus every time the model changes, which is a cost multiplier on metered calls and a non-event on a local file. And a training set must be frozen to be reproducible, while a live API is a moving target you cannot pin a model version against.
03 — How it works
How Canonical solves it
Canonical delivers the complete company dataset as a full snapshot to Amazon S3 (Apache Parquet recommended), to Snowflake via Secure Data Sharing, or as a shared BigQuery dataset. Each delivery replaces the last, so every training run reads one coherent copy of the universe with no diffs to reconcile. Because the dataset includes the long tail — the companies that thin sources and web scrapes miss — the distribution your model learns reflects the real market rather than the well-covered top of it. Choose a weekly, monthly, or quarterly cadence, and pin a training set to a specific delivery when you need a run to be reproducible.
-
Tell us what the model needs
Walk us through the task — pretraining, fine-tuning, embeddings, or retrieval — and which attribute groups matter for it. We scope the delivery against that and send a sample dataset before anything is committed.
-
Data lands in your environment
Deliveries arrive in the storage you already run on, through each platform's own sharing mechanism. Nothing passes through a third party, and there is no manual file transfer to babysit.
-
Rebuild on your own schedule
Each snapshot fully replaces the previous one, so refreshing the corpus is a re-read rather than a merge. Regenerate embeddings and retrain whenever a delivery lands, at no per-row cost.
04 — What's delivered
The attributes this use case relies on
Attribute groups, not an exact schema — the delivery schema is finalized with you during onboarding. See everything a delivery contains.
-
companyCanonical name, domain, founding year, and description.
-
headquartersCity, region, and country of the primary HQ.
-
fundingTotal raised, round count, and the latest round's series, date, amount, and lead investor.
-
investorsKnown investors across the company's funding rounds.
-
foundersFounders and key leadership with their roles.
-
employee_countLatest estimated headcount.
-
firmographicsIndustry, business model, and offering attributes.
05 — FAQ
Frequently asked questions
Can I use Canonical data to train a model?
Yes — bulk delivery exists for exactly this workload. Commercial terms for training and derivative use are agreed as part of onboarding, so the licensing conversation happens before you build on the data rather than after. Book a demo and we will walk through both a sample dataset and the terms.
How is this different from calling the search API in a loop?
Cost and shape. Assembling millions of rows through metered calls is slow and expensive, and it leaves you with a sample defined by your rate limit rather than the full population. A snapshot is one delivery you can read as many times as you like, and it includes the companies no query of yours would have surfaced.
Does this work for RAG and agent grounding, not just training?
Yes. The same snapshot backs a retrieval index you host yourself: you control chunking, embeddings, and refresh, and lookups run at your own latency with no external call in the request path. Teams that want grounding without hosting anything usually start with the MCP server instead, and plenty of them end up using both.
How fresh is the data?
As fresh as the cadence you pick, up to weekly. Bulk delivery is the right tool for a corpus you rebuild periodically, not for a question you need answered to the minute. For live lookups, use the search API or the MCP server.
Do I get the whole universe or a filtered slice?
The complete dataset by default — a consistent copy of the entire company universe, which is what makes the negative class usable for training. If a narrower population is genuinely all you need, say so during onboarding and we will scope the delivery to it.
Start with a sample dataset.
Tell us what you're building and we'll scope the delivery around it, then send a sample so you can test the join before committing to anything.