DEV Community: Jared Ablon

I Open-Sourced the SEC 8-K Classifier Powering My Forensic Tool — Here's the Taxonomy

Jared Ablon — Fri, 03 Jul 2026 02:32:00 +0000

I Open-Sourced the SEC 8-K Classifier Powering My Forensic Tool — Here's the Taxonomy

Most of what makes a SEC 8-K interesting is what's not in the item list. Corporate filers routinely bury Item 1.03 bankruptcy-adjacent language inside an Item 8.01 "Regulation FD" disclosure, or slide an Item 3.01 delisting notice into an otherwise-routine investor update. The item-list header is a filter, not the truth.

I built a classifier that parses the body text of every 8-K and reclassifies mismatches — outputting a buried_json field for every filing that shows what items the body actually references vs. what items the filer marked. It's the engine behind the FilingFirehose forensic scoring tool, and I open-sourced it because the algorithm should be auditable.

Repo: github.com/jaablon/buried-events-parser

MIT-licensed. Pure Python. Zero LLM calls in the classifier itself (the taxonomy runs deterministically; LLMs only enter later in the pipeline for narrative synthesis).

The taxonomy

There are 25 numbered items in a 8-K filing (1.01 through 9.01). The classifier maintains a per-item lexicon of trigger phrases and sub-item patterns.

Some illustrative examples:

Item 1.03 (bankruptcy / receivership):

Direct triggers: "voluntary petition", "chapter 11", "chapter 7", "receiver appointed", "trustee appointed"
Contextual triggers: "restructuring support agreement", "DIP financing", "plan of reorganization"

Item 5.02 (officer / director events):

Direct triggers: "resignation of", "termination of", "appointment of", specific role words paired with departure verbs
Cluster detection: multiple 5.02s within a 30-day window flag "departure cluster" separately

Item 8.01 (other events):

The catchall. This is where filers hide anti-signals from search-crawlers. The classifier is most aggressive here — any 1.03/2.04/3.01/5.02 language in an 8.01 body gets tagged as buried_1_03, buried_2_04, etc.

Item 3.01 (listing standard / transfer notice):

Direct triggers: "notification of failure", "continued listing", "listing standard", "grace period", "delisting"
Presence of a standalone 3.01 filing (without other items) is itself a high-signal event — most companies file 3.01s alongside placeholder items to reduce visibility.

The interesting failure modes

Two edge cases you learn about the hard way:

Amendments (10-K/A, 10-Q/A): These are technically not 8-Ks but they carry Item 4.02 restatement disclosures. The classifier handles them by walking the amendment cover page for the "restated" keyword pattern before falling through to the body scan.
Foreign private issuers (20-F, 6-K): They don't use 8-K item codes at all — they follow SEC form-based disclosure. The classifier translates 6-K materiality flags into the closest 8-K item equivalent so the scoring pipeline downstream doesn't need to know about the alternate form.

Why open source

Every claim in the paid $49 forensic report is tied to a specific EDGAR accession number and a specific classifier output. Anyone who reads the report — customer, journalist, opposing counsel, whoever — can pull the source filing themselves and run it through the classifier locally. Zero trust required in the LLM narrative layer.

That's the trade I want to make explicit: the scoring is auditable by anyone. What you pay $49 for is the narrative synthesis, the executive summary, the accession-cited red-flag catalog, and the "what changes next" section. You're paying for the reading, not the counting.

The next thing I want to build

Cross-filing correlation. Right now the classifier operates on one filing at a time. But the most-interesting SEC disclosure risks are patterns across filings — a 5.02 cluster, an S-3 followed by a 424B5, a 10-K/A restatement following an auditor 5.02. The next release will emit a per-issuer time series so downstream tools can detect these patterns programmatically.

If you're building anything in the SEC-data or fintech space and want to plug this into your pipeline, the code is above. If you want the tool that consumes it end-to-end, FilingFirehose Forensic is free to try — paste any US ticker, get a risk score in 3 seconds, then optionally buy the $49 full report on the same ticker.

Feedback on the taxonomy welcome. What SEC filing signals do you key on that I should add?

Nothing here is investment advice. The classifier surfaces disclosure-language patterns; deciding what to do with those signals is your job, not the tool's.

The One SEC Form That Reveals Dilution Before It Hits Your Position — and How I Auto-Scan It

Jared Ablon — Wed, 01 Jul 2026 21:55:48 +0000

The One SEC Form That Reveals Dilution Before It Hits Your Position — and How I Auto-Scan It

Every retail trader learns the hard way that some 10-15% overnight gaps come out of nowhere, unrelated to news. It's shelf-registered dilution. The company filed an S-3 months ago, then quietly executed on it via a 424B5 or 424B3 the night before. By the time the volume shows up, the price is already gone.

Here's the mechanic and the thing I built to catch it before you're in the trade.

The two-filing dance

An S-3 registration is a company saying "I might sell more stock later." No shares issued yet, no immediate dilution — but the shelf is now loaded.

The 424B5 (and 424B3) is a company saying "I am selling shares now, off the shelf I registered earlier." That's the actual dilution event. It's technically a prospectus supplement, but the market reads it as "the ATM machine just fired."

The gap between the S-3 and the 424B5 can be days or years. That's the window where you can front-run the dilution if you're watching the filings.

You can pull all of it from SEC EDGAR for free. But EDGAR gives you a firehose of 10,000+ filings a day and no way to say "just show me the 424B5s that landed on tickers I'm holding, and only if the raw amount is more than 5% of float."

What I built

A polling service that:

Watches EDGAR's atom feed every 60 seconds for new 8-K, S-3, 424B5, and 424B3 filings.
Parses the 424B5 body for the offering size and cross-references it against float from EDGAR's XBRL structured facts.
Scores each ticker on a proprietary red-flag taxonomy (dilution proximity, listing-standard notices, officer clustering, cyber Item 1.05, bankruptcy language). LOW/MODERATE/ELEVATED/HIGH bands.
Ships a $49 forensic report per ticker with every flag cited to the exact EDGAR accession number.

The scoring engine is the interesting part. Half of what looks like "sudden news" is actually a signal that was sitting in a prior 8-K three weeks earlier — an Item 5.02 officer departure, a buried 8.01 disclosure, an S-3 shelf registration. The tool assembles the narrative before the market does.

What one looks like

Ten pre-generated sample reports on tickers most retail traders already watch — AAPL, NVDA, TSLA, COIN, GME, PLTR, MSFT, SOFI, JPM, AMC — are here: https://filingfirehose.com/reports/samples. No paywall. They're identical in format to what a paying customer receives on any ticker.

If you want one on a specific ticker you're watching, that's the $49 report. One-time, no subscription, no-signals refund guarantee — if the engine finds zero red flags on your ticker, you get the $49 back.

The dev side

A few implementation notes for anyone building similar:

Never do parquet scans inside a request handler. I tried "wrap the scan in a threaded timeout" and took production down for 45 minutes when the polars binary held a futex lock across the timeout. Now every heavy scan is a nightly precompute → JSON blob → request handler just reads the blob. Response times dropped from 3s p99 to 8ms.
Cite everything. An LLM-written brief that says "we found dilution risk" is useless. One that says "see accession 0001193125-25-107824, an S-3 shelf registration for $500M filed on 2025-04-12, followed by a 424B5 on 2025-06-03 for $60M" is forensically defensible. Every claim in the paid report links to the source filing.
Trust the LLM for synthesis, not for extraction. Accession numbers, item codes, and dates come from a deterministic parser. The LLM only assembles the narrative. This avoids the "the AI made up a filing" credibility death spiral.
The classifier is open-source. github.com/jaablon/buried-events-parser — MIT-licensed, pure Python, zero LLM. You can audit exactly how the 8-K item classifier works before trusting any output from the paid tool.

The honest limitations

US SEC filings only. No international.
Forensic disclosure signals, not fundamentals. If you want DCF models and 15-year historical financials, use TIKR or StockAnalysis.com.
No live chat / community. It's a report, not a subscription.

If you're deep in SEC filing analysis and think there's a signal class I'm missing from the taxonomy — reply here or hit me at jared@filingfirehose.com. Genuinely want feedback from other people who spend time in EDGAR.

Nothing in this post is investment advice. Dilution-risk detection is a disclosure-language read, not a recommendation to buy or sell any stock mentioned.

I Built a SEC Disclosure-Risk Audit Tool — Here's What It Found on a Real Ticker (SNBR)

Jared Ablon — Sun, 28 Jun 2026 03:53:30 +0000

I Built a SEC Disclosure-Risk Audit Tool — Here's What It Found on a Real Ticker (SNBR)

I've been building FilingFirehose for the past few months — a tool that ingests every SEC 8-K, 10-K, 10-Q, S-3, and 13D filing in real time and scores each issuer for disclosure risk. This week I shipped the first end-to-end "audit" deliverable: a 12-page forensic write-up on a single ticker, with every red flag traced back to a specific EDGAR accession number.

I want to walk through the actual audit it generated on Sleep Number Corp (SNBR) — a real, mid-cap, publicly traded company — because the patterns it surfaced are a useful illustration of what's hiding in plain sight in routine 8-K cadence.

The full sample is public: https://filingfirehose.com/audit/sample/SNBR

The TL;DR

The system pulled SNBR's last four quarters of SEC filings, ran them through a red-flag taxonomy I built (bankruptcy proximity, delisting notices, dilution proximity, restatement risk, officer departure clustering, cyber-incident disclosure, going-concern language, activist 13D filings), and produced this:

SNBR — ELEVATED risk band. 7 distinct signals across an 8-K cluster filed late May through mid-June 2026. Trajectory: worsening.

The interesting part isn't the score. It's the pattern it caught — one that any short-side analyst would also catch within 10 minutes of looking, but that most retail traders and even some IROs miss.

The Pattern

Three things happened in a 21-day window:

May 27, June 2, June 10 — three consecutive 8-K filings each carrying Item 5.02 (officer/director events). Short-side desks treat clustered 5.02s as a "departure cluster" regardless of the stated reason.
June 12 — a single 8-K carrying Items 1.01, 1.03, 2.04, 7.01, and 9.01. The presence of Item 1.03 (bankruptcy / receivership) alongside Item 2.04 (triggering events accelerating a financial obligation) is one of the highest-signal item-mixes in the 8-K vocabulary. It rarely shows up benignly.
June 17 — a standalone Item 3.01 filing. Item 3.01 is the notice category used for "notification of delisting or failure to satisfy a continued listing rule." Standalone 3.01s are uncommon and are the first item outside readers scan for.

Taken individually, none of these necessarily means anything bad. Taken as a sequence — 5.02 cluster → embedded 1.03 with 2.04 → standalone 3.01 — they form a single narrative that an experienced short-side reader will instantly assemble.

That's what the audit does: it does the assembly for you, names the narrative, cites each filing, and tells you what an outside reader is seeing.

How the System Works (high level)

This is the open-source-ish stack I'm running on Fly.io:

EDGAR full-text feed (polled every 60s)
  ↓
Parquet store of every filing back to 2023
  ↓
Taxonomy classifier (8-K item parsing + buried_json extraction)
  ↓
Per-ticker risk-signal aggregator
  ↓
Claude Opus prompt with the signal list + full context
  ↓
Structured JSON → HTML PDF + Loom-style narration script

A few decisions I made that worked out:

Pre-compute risk scores nightly instead of computing on request. Stripping parquet scans out of the request handler took the p99 response time from 3s to 8ms. Lesson: never do heavy compute in a web request, even if you "wrap it in a thread with a timeout." I tried that and it took the production app down for 45 minutes one afternoon.
Cite every claim to an EDGAR accession number. An audit that says "we found dilution risk" is useless. An audit that says "see accession 0000950103-26-008891, Item 7.01, where the company filed an Item 1.03 reference embedded in a Regulation FD disclosure" is forensically defensible. Every red flag in the deliverable links to the source filing.
Trust the LLM for synthesis, not for fact-extraction. The accession numbers, item codes, and dates come from a deterministic parser. The LLM is only used to assemble the narrative. This avoids the "the AI made up a filing" failure mode that kills credibility instantly.

What the Free Tool Does

If you want to try the underlying scoring engine on any US ticker — no signup, no email — it's at filingfirehose.com/forensic. Type a ticker, hit go, get a score band + breakdown in about 800ms.

The full audit deliverable (12-page PDF + every accession cited + executive summary + outside-reader interpretation) is a one-time $497 product for IROs, CFOs, and audit committees who want to know what an outside analyst is seeing in their filings before the outside analyst writes the article. It's at filingfirehose.com/audit if you want to see the landing — or just read the SNBR sample to see what one looks like in the real world.

What I'd Build Next

Two things on the roadmap:

Sector-comparative scoring — instead of an absolute score, show "you're in the 87th percentile of disclosure risk among small-cap consumer goods companies." Context beats absolutes.
Earnings-call language drift detection — pair the 8-K signal stream with transcript embeddings, surface when management's framing diverges from the filing language. This is where short-sellers actually find alpha.

If you build forensic analysis tools or run a small-cap research desk, would genuinely love to hear what signals you key on that I should add to the taxonomy. Reply here or hit me at jared@filingfirehose.com.

The SNBR audit is real and public. Nothing in this post is investment advice. The "ELEVATED risk band" is a disclosure-language read on routine SEC filings, not a financial conclusion or a recommendation to short the stock.

I parsed 4,251 SEC 8-K filings — 7.3% have buried material events nobody surfaces

Jared Ablon — Thu, 14 May 2026 04:40:13 +0000

The wedge

US public companies file Form 8-K to disclose material events between quarterly reports. Each 8-K has one or more item codes indicating what the event is — Item 1.05 for a material cybersecurity incident, Item 5.02 for a director or officer departure, Item 1.01 for a definitive material agreement, and so on.

There's also a catch-all: Item 8.01 ("Other Events"). The SEC's instructions explicitly say that if a more specific item applies, you should use that instead. In practice, filers chronically use Item 8.01 to disclose events that fit a more specific item — sometimes innocently, sometimes to bury the disclosure.

Most SEC data APIs trust the filer-reported item codes. We re-classify from the body text and surface the discrepancies.

I built FilingFirehose (a productized SEC EDGAR JSON API) and ran the body-text classifier over 4,251 8-K filings filed in a 21-business-day window. Findings:

7.3% of Item 8.01 filings contain body language strongly suggesting a more specific item code
Top suspected misclassifications: Item 1.01 (material agreement, 27 cases), Item 3.01 (notice of delisting, 17), Item 1.05 (cyber, 5), Item 5.02 (officer departure, 3), Item 2.01 (acquisition, 3), Item 1.03 (bankruptcy, 3)
Item 7.01 (Reg FD) shows a similar pattern: 4.0% of those have body language suggesting another item should have been used

Why this matters

For three audiences specifically:

Compliance teams. The SEC's 2023 cybersecurity disclosure rule explicitly flags Item 1.05 misclassification as a violation. Recent enforcement actions cite this exact pattern (a company filing a cyber breach under 8.01 when 1.05 was required). If you're monitoring competitor or watchlist filings, knowing which 8.01 filings actually contain cyber language gives you a real-time risk signal.

Quant analysts running event-driven strategies. Classification noise on filer-reported items is a known problem. The body-text classification is itself a free signal — companies that bury events under 8.01 may be doing so to delay market reaction, which means the price-impact lag is longer than naive item-code monitoring would suggest. Strategies that key off the discrepancy between filer-reported items and body-detected items have an alpha source most consumers miss entirely.

Fintech journalists. Item 8.01 filings are where the buried news lives. Manually reading every 8-K's body for cyber, officer, or material-agreement language is a Sunday-afternoon job. We do it automatically.

The pipeline

The whole thing is ~2k LOC of Python. Stack:

EDGAR poller: standard SEC getcurrent atom feed at 2-second cadence
Filing fetch: per-filing HTML body via requests (cached aggressively — EDGAR rate-limits at 10 req/s)
Body extraction: BeautifulSoup with custom rules for the SEC's idiosyncratic HTML
Classification: deterministic regex + keyword + co-occurrence rules. No transformer. Domain phrases are specific enough that rule-based beats LLM accuracy on this task, with no per-filing inference cost.
Storage: Polars LazyFrames over a partitioned Parquet store (form_type / date). The classifier output stored as a JSON column alongside the parsed metadata.
Re-runs nightly: full body-text re-parse with current rules; results overwrite the JSON column.

Sample classifier rule for Item 1.05 (cyber):

def detect_item_105(body: str) -> bool:
    """Detect material cybersecurity incident language."""
    body_lower = body.lower()
    has_breach_lang = any(p in body_lower for p in [
        "material cybersecurity incident",
        "unauthorized access",
        "data exfiltration",
        "ransomware",
        "cyber attack",
        "cybersecurity event",
    ])
    has_temporal = any(p in body_lower for p in [
        "on [date]",
        "we became aware",
        "discovered on",
        "identified on",
    ])
    has_materiality = any(p in body_lower for p in [
        "material",
        "significant impact",
        "operations were affected",
    ])
    return has_breach_lang and (has_temporal or has_materiality)

(Real implementation has more rules + scoring. False positive rate on a 50-filing manual audit: ~12%. False negative rate on 100 unflagged filings: 1%.)

The output

Every 8-K record in our API includes:

{
  "accession_number": "0001234567-26-001234",
  "company_name": "Example Corp",
  "filed_at": "2026-05-10T16:00:00-04:00",
  "filer_reported_items": ["8.01"],
  "detected_items": ["8.01", "1.05"],
  "discrepancy_items": ["1.05"],
  "suspected_buried_events": ["reported as Item 8.01 but body suggests Item 1.05"]
}

The discrepancy_items field is the difference between detected and reported. The suspected_buried_events field is a human-readable string explaining the flag.

How to query it

The free public tier covers the past 72 hours, no API key required:

# All 8-Ks with suspected buried events from the last 72h
curl "https://filingfirehose.com/v1/public/8k?suspected_buried_only=true"

# Filter by item code
curl "https://filingfirehose.com/v1/public/8k?items=1.05"

# Recent activist 13D filings (separate endpoint)
curl "https://filingfirehose.com/v1/public/13d?activist=Saba"

# Recent ATM offerings on S-3/424B5
curl "https://filingfirehose.com/v1/public/atm?min_shelf_million_usd=100"

For the full archive (10+ years) + webhook delivery + 10× rate limit, there's a free 14-day Pro trial, no card required.

Live data

Today's flagged filings: filingfirehose.com/today
Public leaderboard of companies ranked by buried-event rate: filingfirehose.com/leaderboard
Per-ticker pages: filingfirehose.com/sec/{TICKER} for any listed US company
Methodology piece: filingfirehose.com/research/buried-events
MCP server for Claude Desktop / Cursor / Windsurf: add https://filingfirehose.com/mcp to your config
ChatGPT custom GPT: chatgpt.com/g/g-6a00c51251c08191ad99bf16dc80f4b3-filingfirehose

What I'd love feedback on

Other body-text patterns worth testing. Going-concern language buried under generic 8-K items is on my list. What else?
The classifier's false-positive rate. 12% feels acceptable for a screening tool but may be too noisy for a trading signal. Curious if anyone here has experience tuning rule-based classifiers in this regime.
Other forms worth body-text-parsing. S-1 amendments, proxy statements, going-concern 10-Q sections — what would compound the most?

If you're building anything in this space, happy to chat. The source on the parsing rules isn't fully open (it's the moat) but I'll share the methodology in detail with anyone serious.

— Jared