A dead airline’s archive became a contested AI asset
Spirit Airlines stopped flying on 2 May 2026, in its second Chapter 11 in two years. What remained was the part of a company nobody itemizes on a balance sheet: the internal record of how it actually operated.
In August that record went to auction. Per court filings reported by Axios and CNN, Google submitted the highest bid, $10 million, for a package reported to include roughly 100 million corporate emails, about 500 million Microsoft Teams messages and collaboration records, 516 source code repositories holding on the order of 30 million lines of code, 667,563 IT tickets, and employee records reaching back to 1986. Google outbid the AI data firm Mercor.io, which offered $7.5 million.
The sale is not settled. The Association of Flight Attendants-CWA objected on employee-privacy grounds, a bankruptcy judge in the Southern District of New York postponed the approval hearing, and the AI training startup Micro1 filed a late counter-offer of $12.5 million. As this is published, no final ruling has been reported. Whether Google ends up owning this archive is genuinely unresolved.
Two details matter more than the headline number. The package is corporate and operational rather than consumer: reporting indicates it excludes Spirit’s roughly 97.5 million passenger profiles and its Free Spirit loyalty records. And the data is to be deidentified, with the buyer agreeing not to attempt re-identification.
So remove the passenger data. Remove the identities. What is left still drew a $7.5 million rival bid at auction and a $12.5 million counter-offer afterward, both from AI data firms, for the correspondence of a company that no longer exists.
The contested asset is not the identities and not the passengers. It is the record of how one organization decided things, for as long as it operated.
Volume is not what makes an archive valuable
It is tempting to read a number like 500 million Teams messages as the point. It is not. Most of any corporate archive is logistics: scheduling, acknowledgements, forwarded threads, status updates that mattered for a week. Nobody pays seven figures for that.
What gives an operational archive durable value is that it contains the reasoning of a working organization under real constraints. Somewhere in those threads are the moments where a company confronted a tradeoff and resolved it. Those moments are scattered, unlabelled, and interleaved with noise, but they are there, and they are qualitatively different from the rest of the corpus.
Read a sample of any large company’s internal communication and you will find sentences with this shape:
- “We cannot use that library, legal rejected the licence in March.”
- “Customer identity stays out of this service. That was the whole point of the split.”
- “Nothing in this layer talks to the database directly.”
- “This vendor is not approved for EU customer data.”
- “Fine as a temporary exception, but only until the migration lands.”
- “This supersedes what we agreed last quarter.”
Each of those is a decision. Almost none of them were ever written down as one. They were made in passing, recorded incidentally, and then relied upon for years by people who were present when they were made.
Every organization has a latent decision corpus
A company’s formal decision record, the architecture decision records and the approved policies, is the small visible portion. The larger portion is distributed across email, chat, tickets, review comments, meeting transcripts, and the memory of long-tenured engineers. We would call that the latent decision corpus: the set of decisions that genuinely govern how a system is built, most of which exist in no canonical form.
The latent corpus has three properties that make it awkward. It is unlabelled, so a decision looks exactly like an opinion. It is undated in any useful sense, so a superseded decision looks exactly like a current one. And it is unscoped, so a decision that applied to one service reads as though it applied to the whole system.
This is not a documentation-hygiene complaint. Organizations have been told to write more things down for thirty years and the latent corpus persists anyway, because most decisions are not recognized as decisions at the moment they are made. They are recognized later, usually when somebody violates one.
Language models made recovery plausible
The reason this is worth discussing now, rather than in 2015, is that extracting decisions from unstructured text used to be impractical and is no longer. A model can read a decade of threads and propose a normalized record: the decision, the stated reason, the apparent scope, the people involved, the date, what it appears to replace, and the passages it was drawn from.
That capability is what makes a bankrupt airline’s correspondence a purchasable asset rather than a storage cost. And it is why the interesting question for an enterprise is no longer whether its own history could be mined. It is what the output of that mining is actually worth.
Here the answer gets more constrained than the excitement suggests.
Recovering a decision is not inheriting its authority
An extracted decision is a claim about what an organization once decided. It is not yet a rule, and the distinction is the whole problem.
A model reading a Teams thread cannot reliably tell the difference between a principal engineer stating a binding constraint and a confident engineer stating a preference that was overruled twenty minutes later in a meeting that left no record. Both look like assertions. Both are fluent. Only one has authority.
Authority is an organizational property, not a textual one. It cannot be inferred from tone, seniority in a signature block, or how often something was repeated. Which means the output of decision recovery has to be treated as a queue of candidates for human confirmation, not as a policy set.
| Stage | What it establishes | What it does not establish |
|---|---|---|
| Extraction | That someone asserted this | That the organization adopted it |
| Verification | That it was adopted and still holds | Where it applies |
| Scoping | Which code and which changes it governs | That anything enforces it |
| Enforcement | That a violating change is actually stopped | — |
Skipping a row produces a specific failure. Extraction without verification promotes old arguments into fake policy. Verification without scoping produces rules that are technically true and operationally useless, because a constraint that applies everywhere gets ignored everywhere. And all three without the last row produce a very well-organized description of rules that nothing obeys.
The last row is the one that keeps being skipped
This is the same gap we have written about in narrower settings, and it does not change shape as the input gets bigger. Structured knowledge formats make organizational decisions portable and discoverable without making them binding. Retrieval puts the right decision in front of an agent without constraining what the agent then does. Persistent context helps an agent recall a constraint, which is not the same as obeying it.
Decision recovery would sit upstream of all of those. It would make the corpus larger and more complete. It would not, by itself, change what happens when an agent proposes a change that contradicts one of the recovered decisions. That still depends on whether the decision was ever compiled into something a machine checks before the change lands.
An organization that recovers ten thousand decisions and enforces none of them has produced an excellent history and no additional control.
Where this actually leads
The Spirit auction is being read as a story about training data. The more durable reading is about what companies are carrying without knowing it. A firm with thirty years of operating history holds a decision record that is more specific to its systems than any general-purpose model will ever be, and that record is currently doing no work.
The sequence that would make it do work is not complicated to state:
- Recover candidate decisions from wherever they were actually made.
- Verify which ones the organization adopted and still stands behind.
- Scope each one to the systems and changes it governs.
- Compile the subset that can be expressed mechanically into constraints.
- Enforce those constraints where changes are proposed, and keep the evidence.
Most of the current enthusiasm is concentrated in the first step, because that is the step language models made easy. The value is concentrated in the last two, because that is where a decision stops being a description and starts being a control.
It is also where the privacy argument resolves. The objection raised in the Spirit case is that decades of employee communication are being transferred wholesale for model training. A verified decision record is a far smaller artifact than the corpus it was derived from. An organization that extracts constraints inside its own boundary and retains the decisions rather than the correspondence ends up with something more useful and considerably less sensitive than the archive it started with.
What Mneme does and does not do here
To be precise about our own position: Mneme HQ today operates on explicit architectural decisions in a repository. It compiles the ones that can be expressed mechanically into constraints, and enforces those constraints deterministically against proposed changes, with a single compiled constraint set applied across agents and CI. That is shipped and you can run it on your own code in a few minutes.
Recovering decisions from email, chat, tickets and meeting transcripts across an enterprise is not something Mneme does. It is a direction we find credible, and the argument above is the reason, but it is a thesis about where this goes rather than a description of a product. We would rather state that plainly than let an interesting idea imply a capability that does not exist.
The part that is available now is narrower and more testable. If you want to know how much of your architecture is currently protected rather than merely documented, that is a question you can answer today against a real repository.