--- title: "One Sign Error Withdrew Three Papers in a Day. That Was the Good Outcome." slug: "openai-math-sign-error-cascade-agent-dependency-graph" author: "ibl.ai Engineering" date: "2026-10-13 09:00:00" category: "Premium" topics: "cascading agent failures, AI agent dependency graph, agent observability, multi-agent error propagation, OpenAI math manuscripts, Lean formalization, agent audit trail, ontology layer, self-hosted AI agents, enterprise AI risk" summary: "OpenAI published 722 AI-generated mathematical manuscripts on 6 October 2026 and withdrew three of them the next day, because one sign error invalidated the construction two dependent papers were built on. The cascade was contained in about 24 hours for a reason enterprises cannot copy by buying a better model: the dependency was written down in a public history file. This post gives the primary-source record and the five things an agent chain has to declare before a cascade can be traced." banner: "" thumbnail: "" linkedin: | One sign error took down three papers in a day, and that was the good outcome. The dates are checkable in about five minutes. → 6 October 2026: OpenAI published 722 mathematical manuscripts, produced by an unreleased internal model, to a public repository. → 7 October 2026: three of them came down. The repository's own history file says that in "Algebraicity of Weil classes on split abelian eightfolds" a sign error "invalidates a stabilization-trace cancellation argument and the construction used by two dependent papers." → Same entry: 14 more manuscripts revised with "proof repairs, corrected statements, clearer hypotheses and dependencies," and 13 others updated purely to cite the repaired editions. Read that last line again. Thirteen documents needed no mathematical correction at all. They needed a correction because of what they pointed at. The circulating version of this story is that AI-generated math is unreliable. Too easy, and it misses what actually happened. One error was found, named, scoped to its dependents, and closed inside a day, on a corpus of 719 manuscripts where about 42 percent of top-line results carry a machine-checked Lean proof. That is not luck. The cascade was traceable because three things existed before it happened: a public artifact, a declared dependency between artifacts, and a change log that records who changed what and when. Now count how many of those three your agent chain has. An agent classifies a document, a second extracts fields on the strength of that classification, a third routes, a fourth acts. When the first one is wrong, nothing in that chain writes down that the fourth decision inherited it. So the enterprise question is not "how accurate is the model." A 98 percent classifier is excellent in isolation and still hands its 2 percent to every agent downstream at full strength. The question is whether you can enumerate what consumed a given output after you learn it was wrong. That is a property of the stack you operate, not a benchmark score. It needs typed relationships between your systems, run-level transcripts, and an audit log whose retention policy is yours. With ibl.ai you own all the code and the data, self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. #iblai #AgenticAI #EnterpriseAI #AIGovernance #Observability --- ## The Short Answer **A cascading AI agent failure is one agent's wrong output becoming every downstream agent's input. OpenAI's math repository contained one on 6 October 2026 and closed it in about a day, because the dependency was written down in a public history file. Enterprise agent chains rarely write theirs down. The durable fix is a declared dependency graph plus an audit trail you hold, which is why on ibl.ai you own all the code and the data.** The circulating version of this story is that AI-generated mathematics is unreliable. That is the least interesting reading available, and it gets the lesson backwards. What happened in that repository is closer to a demonstration of working error containment than a demonstration of model failure. The containment is the part an enterprise cannot buy, and the part worth copying. ## What actually happened with OpenAI's 722 AI-generated math manuscripts? A public repository went up, and a day later it published its own corrections. [github.com/openai/math](https://github.com/openai/math) was created **6 October 2026 at 21:47 UTC** and holds mathematical manuscripts produced by what its README calls "an unreleased internal OpenAI model." The scale is stated by the source rather than inferred. The catalogue now lists **719 manuscripts organized into 372 families**, the model was "posed approximately 4,000 problems," and "on average, each result used three hours of ChatGPT Pro thinking compute." The repository carried **14,563 stars** when this post was written on 13 October 2026. On **7 October 2026** its [history file](https://github.com/openai/math/blob/main/history.md) recorded the first withdrawals, in its own words: > In "Algebraicity of Weil classes on split abelian eightfolds" a sign error invalidates a stabilization-trace cancellation argument and the construction used by two dependent papers. Three manuscripts came down: that one, "Algebraicity of Kuga–Satake Correspondences for K3 Surfaces," and "The rational Hodge conjecture for products of K3 surfaces." Two further numbers in that same entry matter more than the three withdrawals, and almost nobody quoted them. **14 other manuscripts** were revised with "proof repairs, corrected statements, clearer hypotheses and dependencies." And **13 additional manuscripts** were updated for one reason only: to "cite the revised editions of companion papers." Thirteen documents required no mathematical correction whatsoever. They required a correction because of what they pointed at. That is the shape of a dependency cascade, recorded by the system that produced it, in public, within 24 hours. ## Why was one sign error taking down three papers a good outcome? Because it was found, scoped, and closed, which is three things more than most failure chains manage. A corrected count helps here, since the brief this post came from framed it loosely. The error did not propagate into three *other* papers. It sat in one paper and invalidated the construction used by **two** dependents, for three withdrawals in total. Nor is it accurate to say it ran undetected. The repository's own change log is the evidence that it did not. The containment rested on three properties that existed **before** the error did:
Property In the math repository In a typical agent chain
A durable artifact per step A versioned manuscript, with prior editions kept accessible An ephemeral message passed to the next agent
A declared dependency Citations, naming which paper rests on which construction Implicit in the orchestration code, recorded nowhere
A change log with attribution A dated history file stating what changed and why Application logs, if anyone kept them at this granularity
Machine checking on part of it 300 of 719 top-line results formalized in Lean, about 42 percent Evaluation on a benchmark, run before deployment, not per decision
Note what the fourth row does not claim. Formal verification did not catch this error, and the repository says plainly that "some of the unformalized results could have issues." It is a partial net, openly described as partial. That honesty is itself the fourth property. ## Why can't an enterprise catch a cascading AI agent failure the same way? Because the artifacts are ephemeral and the dependencies were never written down. Consider the chain that actually ships. One agent classifies an inbound document. A second extracts structured fields on the strength of that classification. A third routes the extracted record to a system of record. A fourth takes an action because the record arrived. Each of those agents may be individually excellent. Suppose the classifier is right 98 percent of the time. That 2 percent does not stay 2 percent. For every case landing in the wrong branch, the downstream agents are not degraded, they are confidently wrong, because they were given no reason to doubt their input. The accuracy metric that made the classifier look good measured it alone. Nothing measured the branch. And the business version is worse than the mathematical version in a specific way. A false proof is false; a routed expense, an approved claim, or a generated filing can be **plausibly** wrong, close enough to clear review, and systematically biased in one direction. Picture the healthcare instance, stated as the hypothetical it is rather than as a reported event. A coding agent assigns the wrong diagnosis code. A prior-authorization agent builds its request on that code. A protocol agent proposes treatment for the authorized condition. Four decisions, one root cause. Now ask the question the math repository could answer in a day and most deployments cannot answer at all: *after you learn the first output was wrong, can you enumerate every decision that consumed it?* ## What does an agent chain have to declare before a cascade can be traced? Five things, and four of them are recording decisions rather than modeling choices.
Declare What it answers after a bad output
Typed relationships between systems Which records in which systems are downstream of this one at all
Per-run provenance Which inputs, retrievals and tools produced this specific output
Consumer lists Who read it afterwards, which is the question citations answer for papers
A dated change log with attribution What was altered, by whom, and when the configuration changed under you
Scored checks on the steps that matter Which branch to re-run, and whether the repair held
The third row is the one almost no stack has. Tracing forward from a run is now routine; enumerating backwards from a known-bad output to everything that trusted it is not. Terence Tao put the structural version of this at Caltech on **9 October 2026**, in an [AIM Public Lecture](https://www.caltech.edu/campus-life-events/calendar/aim-public-lecture-series-terence-tao-1) titled ["Math 2.0"](https://teorth.github.io/tao-web/slides/math-2-0-caltech-2026.pdf). He separates mathematical work into generation, verification, and *digestion*, meaning understanding and contextualizing a result, and argues that the field has moved from proof scarcity to proof abundance. His warning, in the wording carried by [his own running summary of these views](https://teorth.github.io/tao-web/ai-views.html), is unambiguous: "further blind optimization of problem-solving alone is now actively harmful to the long-term health of mathematics." Swap the nouns and the sentence holds for enterprise deployments. Generation is cheap, verification is improving, and digestion, knowing what a result is connected to, is where the gap opens. ## Does a more accurate model reduce cascading agent failure risk? It reduces the frequency of the first error and does nothing to the blast radius of the ones that get through. Accuracy is a per-step property. Cascade depth is a property of the topology you wired. Raising a classifier from 98 to 99 percent halves the cases entering the bad branch and changes nothing about what happens to a case once it is in there. This is why the procurement instinct to solve it by buying the strongest available model is a category error. The thing you need is not a better generator, it is a record of what consumed the generator's output. Our position on this is unchanged from the observability case. No purchasable cross-vendor standard exists yet: OpenTelemetry deprecated every `gen_ai.*` convention out of its main repository on 12 June 2026, and the dedicated replacement still has no tagged release, which we documented in [AI Agent Observability Has No Standard to Buy Yet](/blog/agent-observability-fragmenting-stack-own-the-audit-trail). The narrower engineering problem of locating the failing step inside one long run is also still open, and we covered what Microsoft actually shipped against it in [Finding Where a 50-Step Agent Run Dies Is Not Solved](/blog/microsoft-agent-observability-debugging-multi-step-failures). A cascade across several agents and several systems of record is the harder case, because the evidence is spread across components that were never designed to be read together. ## How does ibl.ai make the AI agent dependency graph explicit? By building the relationships as a layer you own, then recording every run against it. The dependency graph is the [ontology layer](https://ibl.ai/architecture#agentic-development): typed relationships over your existing systems of record, exposed in place through connectors rather than copied into a new store. A prerequisite link between two courses and a mapping from a CRM contact to a learner record are the same kind of object, and they make "what is downstream of this" a query rather than an investigation. Run-level evidence sits in Analytics. [Transcripts](https://ibl.ai/docs/os/analytics/transcripts) hold what was said and what was retrieved, [Costs](https://ibl.ai/docs/os/analytics/costs) hold per-run spend, and [Data Reports](https://ibl.ai/docs/os/analytics/data-reports) export to CSV and JSON for whatever system your auditors already read. *(Existing ibl.ai capability.)* Configuration drift is covered by the per-agent [Audit panel](https://ibl.ai/docs/os/agent-settings/audit), which records who changed what and when down to the individual field, the user's email, and the timestamp, and is itself permission-gated. The equivalent of the partial Lean net is [Evaluations](https://ibl.ai/docs/os/agent-settings/evals): LLM-as-judge scoring plus human annotation on the steps that carry consequence, with results exportable. Like formalization, it is a partial net, and it is worth more when you know which steps it covers. Access scoping belongs in the same answer, because a cascade can only reach what the chain is permitted to touch. [Roles and RBAC](https://ibl.ai/docs/os/organization-settings/roles) is deny-by-default, and the broker injects credentials per caller. What makes all of that durable rather than rented is the deployment model. You receive the source under a perpetual license and run it inside your own perimeter, so the ontology, the transcripts, the retention policy, and the schema you reshape when the conventions finally settle are yours. [ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.](https://ibl.ai/about) **1.6M+ users across 400+ organizations** run the platform this way, including NVIDIA, MIT, and Syracuse University. The math repository's advantage was never a better model. It was that somebody had written down what depended on what, before they needed to know. --- *Sources: the repository creation timestamp (6 October 2026, 21:47 UTC) and star count read from the GitHub API on 13 October 2026 for [openai/math](https://github.com/openai/math); the 719-manuscript and 372-family catalogue size, the "approximately 4,000 problems," the three hours of ChatGPT Pro thinking compute per result, the "unreleased internal OpenAI model" description, the ~42% formalization figure and the "some of the unformalized results could have issues" caveat quoted from [that repository's README](https://github.com/openai/math/blob/main/README.md); the sign-error wording, the three withdrawn titles, the 14 revised manuscripts, the 13 citation-only updates and the 300 of 719 Lean total quoted verbatim from [its history file](https://github.com/openai/math/blob/main/history.md); the proof-scarcity-to-abundance framing, the generation/verification/digestion decomposition and the "actively harmful" quotation and the digestion gloss taken from [Terence Tao's own running summary of his views on AI](https://teorth.github.io/tao-web/ai-views.html) rather than from [the "Math 2.0" slide deck](https://teorth.github.io/tao-web/slides/math-2-0-caltech-2026.pdf) itself, which is an image-only PDF whose text cannot be read programmatically, delivered 9 October 2026 in [Caltech's AIM Public Lecture Series](https://www.caltech.edu/campus-life-events/calendar/aim-public-lecture-series-terence-tao-1); the OpenTelemetry dates from [semantic-conventions v1.42.0](https://github.com/open-telemetry/semantic-conventions/releases/tag/v1.42.0). Two framings from the briefs were corrected rather than carried: the error did not propagate into three other papers, it invalidated the construction used by two dependents for three withdrawals in total; and it was not missed, it was recorded by the repository within about 24 hours. A brief's attribution of the sentence "We are now entering an era of proof abundance" to Tao as a direct quotation was replaced with the wording his slides actually carry. The healthcare chain is presented as a hypothetical, because no source reports it as an event.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.