DEV Community: Jared Ablon

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