Introducing

Tagging 8-K disclosures with AI: corporate events, labelled by what actually happened

Jul 22, 2026

In the second week of September 2023, two of the biggest casino operators in the US were hacked within days of each other. Both disclosed the incidents in Form 8-K filings, the report companies must file with the SEC within four business days of a material event. Caesars filed under Item 8.01, "Other Events". MGM's first filing went in under Item 7.01, "Regulation FD Disclosure" (a fair-disclosure provision, in practice another catch-all). When MGM filed again in October with the substance (roughly a $100 million hit to quarterly earnings), that 8-K carried Items 2.02 and 7.01: "Results of Operations" and, again, "Regulation FD".

Across the three filings the companies used three different item codes, and none of them says anything about cybersecurity. That is not sloppiness on the filers' part. The SEC's 32 item codes are legal filing categories (i.e. which paragraph of the rules obliges you to file), not event labels, and in September 2023 there was no cybersecurity item to use. The SEC added one, Item 1.05, that December. Even so, in our data roughly two thirds of the cybersecurity incidents disclosed since the rule took effect still arrive under other items, mostly the 8.01 catch-all.

The only machine-readable labels on an 8-K tell you which paragraph of the rules required the filing. We have just launched 8-K Disclosures, an endpoint that instead labels the underlying event.

What the endpoint returns

We leverage LLMs to process the text of 8-K filings and classify each material event it finds into a three-tier taxonomy: 8 broad domains (like leadership_and_governance), 29 mid-level groups (like executive_leadership), and 119 specific event types (like ceo_departure). Each result is one event, and every event carries a supporting_text field: a verbatim excerpt from the filing that the classification is based on, so you can check any label against the source yourself.

Here is what the endpoint returns for that Caesars filing:

{
  "tickers": ["CZR"],
  "cik": "0001590895",
  "accession_number": "0001193125-23-235015",
  "filing_date": "2023-09-14",
  "primary_category": "risk_events",
  "secondary_category": "security_and_safety",
  "tertiary_category": "cybersecurity_incident",
  "supporting_text": "Caesars Entertainment, Inc. recently identified suspicious activity in its information technology network resulting from a social engineering attack on an outsourced IT support vendor. On September 7, 2023, we determined that the unauthorized actor acquired a copy of, among other data, our loyalty program database...",
  "filing_url": "https://www.sec.gov/Archives/edgar/data/1590895/0001193125-23-235015.txt"
}

The filing was Item 8.01. The label is cybersecurity_incident. You can query for that label directly, regardless of which item code the filer used.

One filing is often several events

That MGM filing produced three distinct events, each with its own supporting quote. A sharper example is Disney's 8-K from 21 November 2022, the one where Bob Chapek was terminated and Bob Iger returned. The endpoint returns five events for that one filing: ceo_departure, ceo_appointment, director_departure, director_appointment, and executive_compensation_change, each grounded in its own excerpt (the ceo_departure quote begins "The Company exercised its right to terminate without cause the employment of Robert A. Chapek as Chief Executive Officer...").

This is why the endpoint returns one row per event rather than one row per filing. A filing with nothing taxonomy-relevant returns no rows at all.

The market treats these categories differently

A fair question about any AI-derived dataset is whether the fine-grained categories mean anything, or whether we have just sliced the same events into prettier buckets. One way to test this without trusting the language model at all is to look at stock prices: for each filing, measure how much the filer's stock moved around it (in either direction, relative to that stock's normal daily move) and ask whether the taxonomy separates big-reaction events from routine ones. No model is involved in that measurement, it is just returns data and labels. As part of a research evaluation of the system (paper forthcoming) we did this across 182,174 filings, keeping only events where the move can be attributed to a single filing (no other filing by the same company within a day). To be clear about what this is not: it measures how markets reacted around past filings, and makes no claim about predicting returns.

Item 5.02 is the clearest illustration. It covers every officer and director change, so a CEO firing and a routine director retirement carry the same code. We split the 19,443 filings whose only substantive item is 5.02 (ignoring the routine exhibits item that accompanies most filings) by our tags:

A filing with no real news averages about 1.0 on this measure (the stock moves its normal daily amount). CEO departures average 1.32, and 17% of them move the stock more than twice its normal amount; routine executive appointments average 1.06, barely above no-news, with 10% moving twice normal. One item code is covering visibly different events.

Across the whole taxonomy the spread is wider: average reactions span roughly a threefold range, from clinical trial results at 2.75 times the normal daily move (34% of those filings move more than twice normal) down to auditor engagements and annual-meeting results sitting on the no-news line. Nine of the fifteen most market-moving event types are filed mostly under Item 8.01, the catch-all; for clinical trial results specifically, 86% of the events we serve sit under it.

The cybersecurity rule change makes a natural experiment for the same point:

An item-code watcher gets zero incidents before 2024 (the code did not exist) and about a third of them after. The content-based tag measures the event class continuously across the rule change.

How the tagging works, and how we check it

The pipeline has a few stages, and they leave evidence you can check.

In the first stage a language model reads the filing against the full taxonomy (with definitions) and proposes tags. Two checks run on everything it produces. A tag whose event type is not an exact taxonomy entry is rejected and retried, so the output vocabulary is fixed at exactly 119 types. And every tag must cite a supporting quote, which we verify deterministically against the filing text word for word (allowing for whitespace and punctuation): a quote that does not genuinely appear in the filing fails validation. That check means the cited evidence is real language from the filing; it cannot by itself confirm the evidence establishes the event, which is what the second stage is for. There, each tag's quote is re-read in isolation against the category definition and scored on how well it establishes that the event actually happened, and only high-scoring events are served through the API.

Doing the scoring in a dedicated second pass, rather than having the extraction model rate its own tags as it produces them, turned out to matter more than we expected: rated inline, the model puts roughly three quarters of its tags at the top score, which makes the rating close to useless as a filter, while a fresh call that sees only the quote and the definition spreads the same tags across the whole range and tracks their actual precision closely. See the full paper for more details.

To measure how well this works, we had a separate, more capable model judge 5,125 tags drawn from every event type and every score level, with the full filing in front of it. On that sample, the tags above our serving threshold measured about 93% precision, and the top-scoring tags (roughly six in ten of what we serve) 96%. The rarer and more serious failure, a tag whose claimed event is not in the filing at all, essentially disappears above the threshold: about 0.1% at the serving level, and none among the top-scoring tags in our sample. The errors that remain are mostly near-misses, a real event given a sibling category (an accounting error correction tagged on what is actually a full financial restatement), and supporting_text always shows exactly what a label was based on.

Two caveats. The precision numbers come from an LLM judge rather than human annotators. And we quote no recall number: the quality filter deliberately trades away thin, ambiguous disclosures (like MGM's first filing) to keep what is served reliable.

Why not just search the filing text?

You could use our 8-K Text endpoint and search for "chief executive" and "resign". In practice that breaks in both directions: filings announce a CEO departure as a retirement, a transition, or a mutual separation, and plenty of filings mention the words without the event (biographies, forward-looking boilerplate, references to other companies). The taxonomy approach labels what happened rather than which words appeared, deduplicates it into one row per event, and hands you the sentence it relied on.

Using the endpoint

A query for recent CEO departures looks like this (replace vX with the current version from the docs):

curl "https://api.massive.com/stocks/filings/8-K/vX/disclosures?tertiary_category=ceo_departure&filing_date.gte=2026-06-01&apiKey=YOUR_API_KEY"

The taxonomy itself (categories plus plain-language definitions) comes from the companion Disclosure Categories endpoint, useful for discovering what you can filter on:

curl "https://api.massive.com/stocks/taxonomies/vX/disclosures?secondary_category=executive_leadership&apiKey=YOUR_API_KEY"

Things worth knowing before you build:

• Coverage starts in January 2022. Today that is over 300,000 served events across nearly 200,000 filings from more than 9,000 companies (the high-confidence subset of a larger tagged corpus). Very large filings that are mostly exhibit attachments rather than disclosure text are not processed.
• Updates are daily. New filings become queryable on the next day's load.
• Filters: tickers, cik, filing_date (with range operators), and tertiary_category (exact match). To get everything under a broader group like executive_leadership, look up its tertiary types in the categories endpoint and query each of those types.
• One row per event. A filing can return several rows (same accession_number) or none.
• The taxonomy is versioned (v1.0 at launch). If we revise categories in future, older versions remain queryable, so a filter you build today keeps meaning the same thing.
• It is currently market experimental and available in all plans (including free) but this will change in the future when it comes out of experimental.

The categories are AI-assigned and occasional errors will get through. When a label surprises you, read its supporting_text first; that is what it was assigned on, and it resolves most surprises. If it is genuinely wrong, flag it through support.

The docs have the full field reference. We also wrote up the extraction system and its evaluation as a research paper, which is available as a preprint on arXiv.

• 

  Rian Dolphin

  rian

  Read More