Securities Anomalies — feature-extraction architecture

Design for the scheme-centric view that backs https://sec.atsignhandle.xyz/anomalies and (proposed) https://sec.atsignhandle.xyz/anomalies/docs. The corpus today stores documents (press releases, litigation releases, complaints, indictments, judgments) as flat rows. This doc lays out how those rows roll up into a scheme node, what features we extract from EDGAR to score scheme exposure before indictment, and how we measure detection lead-time against the historical record.

Why a scheme node

A securities-fraud prosecution typically generates 5–40 documents: an SEC press release, an SEC litigation release, a DOJ press release, a criminal complaint or indictment (sometimes superseding), a parallel civil complaint, judgments, sentencings, restitution orders, and one or more administrative orders. Today every one of those is a row in documents. To answer "what schemes exist, who was involved, how much money, and how was it caught" we need one row per scheme, with documents attached.

LLM backend routing: anomaly-classify and the scheme/feature passes share the same pool-postcrime-* aliases as the enrichment pipeline. How those route to NIM vs LAN GPUs (and why NIM usage is low) is in llm-routing.

Scheme identity

scheme_id = uuid_v5(
  namespace = "fraud-heuristics/scheme/v1",
  name      = canonical_caption || "|" || primary_filing_date
)

• canonical_caption — DOJ/SEC caption normalized: drop "v." vs "v", drop "et al.", drop "United States of America" / "Securities and Exchange Commission" prefix, lowercase, ASCII-fold.
• primary_filing_date — earliest of (criminal complaint, indictment, SEC civil complaint).
• A criminal case and its parallel civil case fold to one scheme (same caption family, dates within ~30 days, ≥1 shared defendant).
• A superseding indictment shares the scheme of the original; a separate prosecution after acquittal does not.

Scheme table — fields

Document role (per-document join)

documents.scheme_id (nullable uuid) and documents.scheme_role (enum) are the two new columns wired in via a regex+LLM pass. Roles:

Pipeline — document → scheme

1. Pre-cluster (regex pass scheme-cluster)
   • Normalize caption from documents.title.
   • Stable-hash → candidate scheme_id.
   • Materialize documents.scheme_id for the easy 80%.
2. LLM disambiguation (scheme-link, qwen3:8b)
   • Run only on residual rows that didn't bind in step 1.
   • Input: title + 2 KB of body summary + 5 nearest neighbors (by ticker + date window).
   • Output: existing scheme_id or null (creates new).
3. Field extraction (per scheme_role × per-pass)
   • Regex for: dates, dollar amounts, tickers, agencies, docket numbers, judge names.
   • LLM for: scheme type/subtype, overt-act window, evidence source, wiretap dates, cooperator counts.
4. Cross-reference (regex)
   • For each participant name resolved by entities enrichment, look up cik in edgar-universe.db via edgar-cik-resolver. Annotate participants_jsonb[i].edgar_cik.
5. Materialize scheme row
   • Insert/update schemes table; stats-miner panels read from it.

All five pass-types are added to the existing fraud-publisher queue. None require new infrastructure beyond corpus.db migrations.

Entity universe — EDGAR cross-reference

After step 4, participants_jsonb is hydrated. From there we expand the universe:

• Individual → all CIKs they're listed on (Form 4 reporting persons, S-1 officers/directors, 10-K certifications).
• Entity → all CIKs in the corporate family (sub-CIKs of same parent, predecessor name-change chain, address cluster).
• Counsel → all CIKs they signed exhibits on (filing-agent / preparer index already lives in edgar-cik-cli/counsel-index/).
• Address → all CIKs at that address (already in address-clusters.json).

The expanded universe goes back into participants_jsonb as role: "expansion-neighbor" so we keep the original-vs-derived split clean. This is how a single scheme node ends up touching the full Cane Clark / Cane O'Neill Taylor network without the LLM having to know about it.

Confidence scoring — features from EDGAR alone

Goal: given only a CIK and an accession, produce a probability that this CIK is part of an active securities-fraud scheme. Then test against historical schemes where we know the indictment date.

Feature categories (all extractable from EDGAR filings + edgar-universe.db):

Scoring: simple linear combination at first (no ML), weights set by hand. Per-CIK score = sum(w_i × present_i) / max_possible. The point isn't a perfect classifier — it's reproducible scoring that we can re-run as features are added.

Historical validation — two test sets

Test set A — blank-check unregistered-securities universe

• Filter: submissions.sic = '6770' AND first_filing_date BETWEEN 2010 AND 2018 AND state IN ('NV','DE').
• For each CIK, compute confidence at each accession in chronological order.
• For known-bad CIKs (cross-reference DOJ/SEC schemes already in our corpus), record the accession date at which confidence ≥ 0.6 ("first flag").
• Lead-time = date_complaint − date_first_flag.
• Metric: median lead-time + recall at confidence ≥ 0.6 over the known-bad set.

Test set B — known-associate expansion

• Seed: defendants in 10 already-prosecuted schemes (Discala/Cane, Honig, Lebed, Beasley, etc.).
• Expand via the entity universe above.
• For each expansion-neighbor CIK, compute confidence trajectory.
• Metric: how many expansion-neighbors hit confidence threshold before their own prosecution (if any).

Both sets are read-only experiments against corpus.db + edgar-universe.db; no new ingest required to start.

Evidence-provenance extraction

How did the government find the scheme? This is buried in the pleadings and matters because (a) it tells us which signals to weight in future scoring, and (b) it gives us the evidence_start_date lower bound — the earliest date the government had probable cause.

evidence_start_date is the earliest dated anchor across all classes — typically the wiretap authorization date or the first dated cooperator agreement. This is the closest proxy we have to "when did the government have a viable case?".

Detection lead-time — the metric that matters

For each scheme we now have three timestamps:

T_first_flag       ← earliest accession where our confidence ≥ 0.6
T_evidence_start   ← from pleadings (wiretap / cooperator / SAR / etc.)
T_indictment       ← date_complaint

Two gaps to minimize:

Δ_detection_lead    = T_indictment      − T_first_flag    (positive = we'd have flagged first)
Δ_evidence_lead     = T_evidence_start  − T_first_flag    (positive = we'd have flagged before the wiretap began)

Δ_detection_lead is the headline. Δ_evidence_lead is the harder target — it asks whether public EDGAR data alone could have driven a SAR or a surveillance referral before the gov spent a year on a wiretap.

Per-scheme + aggregate medians populate the new /anomalies/lead-time panel.

Reference case — US v. Discala et al. (SDNY 14-cr-399 / 14-cv-5074)

A worked example used for both regression and design review.

For each ticker we walk forward through EDGAR accessions and ask: at what point would our feature catalog have flagged the issuer? The answer feeds Δ_detection_lead. For CDS specifically the predecessor-name-change chain + Cane-Clark counsel + S-8 trust pattern are all present years before 2014; the prediction is that confidence ≥ 0.6 on or before 2012-Q4 — two years before indictment, one year before the wiretap.

Roadmap

1. M1 — schema + scheme-cluster regex pass (1 week)
   • Migration: schemes table, documents.scheme_id/scheme_role columns.
   • Regex scheme-cluster pass binds the easy 80%.
   • Single /anomalies/schemes panel listing all schemes by date.
2. M2 — LLM disambiguation + role + field extraction (1 week)
   • scheme-link, scheme-fields, scheme-evidence enrichment passes.
   • Backfill across the existing corpus.
3. M3 — entity universe expansion (3 days)
   • Cross-reference participants_jsonb against edgar-universe.db.
   • Address / counsel / officer expansion.
4. M4 — feature catalog v1 + confidence column on edgar-universe.entities (1 week)
   • 15 features above, hand-weighted, materialized per-CIK.
   • /anomalies/feature-catalog doc + per-feature drill panels.
5. M5 — historical validation (1 week)
   • Test set A (blank-check) and test set B (known-associate expansion).
   • Δ_detection_lead and Δ_evidence_lead per scheme + aggregates.
6. M6 — /anomalies/lead-time + iteration loop (ongoing)
   • Each new feature is judged on whether it improves Δ_detection_lead median without dropping recall.

Open questions

• Market data: ticker-price + volume features would dramatically improve the catalog but require a new data feed (FINRA OTC market data, polygon.io, or similar). Today we only have EDGAR.
• Sealed docket detection: when a wiretap is still under seal we can't extract evidence_start_date. Need a fallback: infer wiretap presence from cooperator-density and prosecution narrative.
• De-duplication of agency PRs: DOJ and SEC sometimes issue near-identical press releases on the same scheme. They should fold to the same scheme_id but their content shouldn't double-count amounts. The scheme_role enum captures this; field extraction needs to prefer indictment > civil complaint > PR.
• Restoring sealed defendants: indictments redact sometimes; we may not see all participants. Cross-reference against the docket lists helps but isn't complete.
• Weighting: hand-weighting features is fine for v1 but eventually we want a logistic regression on known-bad/known-good. The training set is small (~100 prosecuted schemes); regularization heavy.

Where this lives