Their datasets are just our search results, read and coded by people. The pipeline that produces the candidates — SEC ingestion, full-text + section search, proximity grammar — is already ours. The only layer we don't run today is the extraction that turns a matched paragraph into a structured row. And we build exactly that layer elsewhere in this codebase.
A restatement record — {cik, form, period, type: little-r, reason, $ amount} — is produced by (a) finding the filing, then (b) reading it and coding the fields. We already do (a) at scale. Step (b) is what their offshore team does by hand, and it's precisely what an LLM extraction pass does in our gpt_* pipelines.
Each line is: their query becomes our candidate filter; an extraction pass fills the fields. The search half is done today.
| Dataset | Candidate filter (from their own queries) | Extract | Build |
|---|---|---|---|
| Non-reliance restatements | restatement / out-period / immaterial → 8-K 4.02, 10-K/A | type (Big-R/little-r), period, reason, $ amount | Medium |
| Out-of-period adjustments | out-of-period · overstate · prior period → 10-K/10-Q | direction, amount, account affected | Medium |
| Changes in estimate | estimate change · useful life · depreciation | estimate type, effect direction | Low |
| Insider pledging | pledge W/20 shares · margin · collateral → DEF 14A | person, # shares pledged, lender | Low |
| Cyber incidents | cyber · attack → 8-K Item 1.05 | incident date, material?, systems, cost | Low |
| Auditor / opinion changes | auditor · independent accountant → 8-K 4.01 | old/new auditor, reason, disagreements | Low |
"Build" rates the extraction + QA effort only — the candidate search is already live. Structured items (8-K with a named SEC item) are easiest; narrative restatements are the hardest to code accurately.
Sell them the extraction and alerts (Sheet 1). Higher margin than search, no channel conflict, and it deepens their dependence on us. We profit from every dataset they build without carrying the accuracy risk or distribution cost.
Build and sell the datasets directly. Bigger prize (we capture the full dataset margin, not the search fee) but we'd be competing with a paying customer — they'd likely pull spend the moment they noticed — and we'd have to earn trust that took them 20 years.
Audit Analytics/Ideagen is an active 40+ seat account. Competing head-on risks that revenue outright. The extraction tech serves both paths — so build the capability (Path A revenue funds it), and hold Path B for a net-new dataset where we're not cannibalizing a customer relationship.
Pick cyber incidents (8-K Item 1.05) — structured, newly regulated, and one they're only ramping, so it's the least-conflicted place to prove the method.
Filter. Run their own cyber sweep as the candidate query over 8-K 1.05, last 12 months — search half is already live.
Extract. LLM pass on matched sections → {incident date, material flag, systems, est. cost}, reusing the gpt_* pattern.
Grade. Score precision/recall against a hand-checked sample. This is the whole question — can we hit dataset-grade accuracy?
Decide. If accuracy clears the bar cheaply, we have a repeatable machine; point it at the next line. If not, Path A only — and we've learned it for the price of one pilot.
Channel conflict. Competing with a 40+ seat customer can cost the account. Mitigate by leading with Path A and reserving Path B for net-new data.
Accuracy bar. Dataset credibility is binary — a few wrong Big-R calls and researchers won't trust the feed. QA is the real cost, not extraction.
Distribution. They're embedded in WRDS/Bloomberg. Even a great dataset needs a route to buyers we don't yet own.
Backfile cost. Real-time is cheap; coding 20 years of history to match theirs is a project in itself.
Tech feasibility. Lowest-risk piece — we already run every layer. The pilot de-risks it for one dataset's cost.