Who Buys the Failure Before It Happens?

On 18 November 2025, Cloudflare's network began behaving like a patient whose temperature rose and fell every five minutes. Services failed, recovered, then failed again. The team initially thought the network was under a massive cyberattack. According to the company's subsequent report, the cause was stranger and less heroic: a database-permissions change doubled the contents of a file used by its Bot Management system. The file propagated to machines across the network and exceeded the size the software could handle. A legitimate update became the route to a widespread outage S01.

The file was not published once each morning with a formal announcement. It was regenerated automatically every five minutes by a ClickHouse query. Some nodes had received the permissions update while others had not, so the system alternately received a valid file and a doubled one. Service recovered temporarily, leading observers to suspect fluctuating hostile traffic. When most servers began producing the bad version, the failure state stabilized. Core traffic was largely restored by 14:30 Coordinated Universal Time (UTC), but the company did not declare all systems back to normal until 17:06, according to the same report S01.

Five months earlier, on 12 June 2025, Google Cloud services suffered a global disruption. Again, the problem did not begin with a projectile or a breach. A quota-policy update introduced data containing blank fields, propagated globally, and activated a code path that could not handle a null value. Even after the cause had been identified, a restart wave slowed recovery in some regions because returning services placed pressure on a database they depended on S02.

The companies and their software differ, but the two incidents share an engineering affinity worth studying: the system did not fail to withstand an extraordinary catastrophe; it treated an unexpected input as impossible, then propagated the consequences of that assumption with the confidence and speed of a machine.

Incidents leave long reports behind. Engineers read them, discuss them in meetings, and add them to the archive of human experience. Months later, the same family of errors may surface in another organization, perhaps one whose engineers had already read the first report. This is where the strategic idea begins: what if a documented incident could be turned into a unit of executable knowledge—an Executable Failure Contract—that specifies the condition that triggered the failure, the behavior that must not occur, the experiment that reveals it, and the evidence that substantiates the test result?

The exported good would then be more than a monitoring tool or a one-off consulting report. It would be a test that an engineer in Riyadh could develop, an operator in Singapore could run, and a buyer in Frankfurt could verify without taking the seller at its word. The question worth scientific and commercial investigation is not whether the idea sounds attractive. It is whether the logic of a failure can move between different systems without losing its meaning, and whether a foreign customer will pay for that transfer twice.

The idea seems odd if we imagine that the software industry sells only what happens when things go well. A successful application provides a service, a chip performs a calculation, and a network carries a message. Yet a quiet economy surrounds these products: the economy of what should not have happened. An organization may pay a monthly contract for a test that discovered nothing, provided it has a sound engineering reason to trust that the experiment distinguishes correct performance from a detectable failure.

That market is not imaginary. Amazon Web Services (AWS) offers AWS Fault Injection Service (FIS). It has provided a library of ready-made scenarios since 2023, as the company explained in a guide published in 2024. The experiments can simulate the loss of an Availability Zone or the effects of disrupted connectivity, with mechanisms that stop them when defined boundaries are crossed S06S08. In May 2025, AWS published an example that generates experiment templates from natural-language descriptions using Amazon Bedrock and Large Language Models (LLMs) S07.

A Saudi venture therefore cannot credibly claim to have invented Chaos Engineering or first discovered that an incident description could be turned into an experiment. Competitors already exist, and some own the platform the customer wants to test. The proposed product's opening lies somewhere narrower and harder: translate the semantics of a failure mechanism into a test portable across environments, and attach reviewed evidence of the observed behavior, instead of binding the test to one cloud engine or merely shutting down a random server.

This distinction may fail in the market. Cloud providers may add the capability free with their subscriptions, or buyers may decide that a platform-specific solution works better. An engineering gap that looks interesting must not be mistaken for a proven investment opportunity. The real project begins with discovering who will pay to bridge that gap, not with inventing an impressive English name for it.

Incident reports use language suited to explaining events to people: timelines, decisions, assumptions, propagation details, root causes, and remedies. A computer cannot run a safe experiment merely because it has been told that a team “will improve error handling.” It needs a specific condition, an initial state, a permitted action, an observable result, and a way to stop and roll back.

I propose treating the report as raw material rather than executable code. It passes through five translations:

1. Separate observation from interpretation. Which facts did the system owner report? What remains an inference? Which part cannot be transferred because the necessary specifications are unavailable?
2. Extract the causal pattern. For example: a read-permissions change in a data store produces duplicate rows, enlarging a shared configuration structure until its reader cannot handle it. This describes a family of behavior, not a copy of one company's design.
3. Write a functional invariant. For example: “The presence of semantically duplicated feature records must not bring down the core service path.” The invariant itself needs a qualification: is deduplication safe in the product at hand? Record order or repetition may be an intentional part of the meaning.
4. Compile a bounded experiment. A compiler generates synthetic inputs in an isolated environment, specifies an expected outcome, and sets stop conditions and a rollback method.
5. Produce an evidence record. Which software version ran? What random seed, if any, was used? What were the test cases? What observations came from distributed traces, logs, and metrics?

The resulting unit can be represented by a clearly structured IncidentSpec file containing evidence, preconditions, stimulus, oracle, stop, rollback, environment, and limitations. These are proposed research and development fields, not an approved standard or the name of an existing Saudi product. The oracle is the decision rule that separates success from failure. The worst defect in an intelligent test is not an inability to provoke the failure. It is provoking it and then celebrating the experiment as a success because the test does not know the correct outcome.

Common cloud failures are injected by cutting a network connection, increasing latency, stopping a container, or exhausting a processor. These tests are genuinely useful. On their own, however, they do not reproduce the events that killed a service path in the two earlier cases. One cause was an oversized file; the other, a missing field in a globally distributed policy. A system may pass thousands of server-shutdown tests and then collapse when it imports one extra database row.

Computer science distinguishes a resource fault from a semantic fault. The first asks what happens if the server disappears. The second asks what happens if the server is present and fast but reads syntactically permitted information that violates a hidden assumption in the software. This second kind of test may address data corruption, schema drift, version skew, an idempotency failure, or a retry storm.

Not every bad input should be handled in the same way. A financial service cannot turn every authorization error into “let it through so the service keeps running.” In a public read-only service, conditional fail-open behavior may be more appropriate than blocking everyone. The functional invariant comes from the service's purpose and boundaries; it cannot be copied from a news article. This is where the most valuable professional service sold with the product may arise: translating the meaning of the business into measurable conditions, rather than merely translating words into a configuration file.

Software testing already offers other instruments. Property-Based Testing generates varied inputs in search of a counterexample to an invariant. Metamorphic Testing compares a system's output before and after an input transformation when the correct answer for each case is difficult to know. Differential Testing compares two implementations that claim to follow the same rule. Concurrent transactions make the problem harder: each response can look correct on its own while the complete history violates a consistency guarantee. For years, Jepsen has made a published method of running real distributed systems under faults and checking their operation histories S09.

This is not work for a creative agency that imagines a company's worst day and asks a language model to render it. It requires researchers in programming-language semantics and distributed protocols, alongside operations engineers who understand that “do not crash” is a much weaker condition than “complete the correct task without duplication or loss.”

Talk of doubled files, indexes, and distributed replicas may sound like recreation for a programmer who enjoys coffee with outage reports. It feels different when we consider the US AT&T Mobility incident of 22 February 2024. The Federal Communications Commission's (FCC) Public Safety and Homeland Security Bureau reported that a network-element misconfiguration caused a widespread cellular-service outage lasting at least twelve hours. According to data the regulator obtained from the operator, the incident blocked more than 92 million voice calls and more than 25,000 attempted calls to 911 emergency centers S03.

There is no need to invent the name of a patient who could not summon an ambulance, or to presume the outcome of every blocked call. The number and the type of service are enough to make the issue social in the fullest sense. A change to a technical element became an intervention in millions of people's ability to communicate. The transferable lesson is not to apply the call count to any particular Saudi network. It is to test how a single change propagates and how the rest of the system responds when that change is reversed, before release. The harm did not end when the error was recognized: masses of devices trying to reconnect can prolong congestion after the fix.

At this level, the three incident records differ: a duplicated feature file, a quota record with a blank field, and a misconfigured network element. Yet they converge on one question: when does a local piece of control information become a rapid collective decision that is difficult to reverse? Putting the records together does not prove that one platform can detect all three. It does create a bank of scientific hypotheses more honest than the general claim that “our artificial intelligence predicts attacks and outages.”

If we wanted to build an initial Saudi product, I would not begin with an enormous platform or a dashboard bearing a world map and slogans about readiness. I would begin with an Incident-to-Test Compiler working on a public incident register and three kinds of software the team understands well. It would not connect directly to a customer's system. First, it would request an abstract model of the service interfaces, the properties the customer considers essential, and the boundaries of the authorized environment.

The artificial-intelligence (AI) stage would extract candidates: “the outage may have resulted from file size”; “the reader may not handle blank fields”; “retries may amplify load.” It would attach evidence from the report to every statement and give it a status: source-documented, plausible, or non-transferable. The language model would act as a hypothesis-extraction assistant, not a judge granting permission to execute. It could misstate field names or invent a causal relation, so its outputs must never become commands that directly affect live services.

The hypothesis would then become an Intermediate Representation (IR). One adapter might produce Kubernetes experiments, another Application Programming Interface (API) tests, and a third a standalone library test with no infrastructure. A commercial subscription has no value unless meaning survives across these forms. Stopping a group of containers in one environment may superficially resemble a failure in another while omitting the shared state that made the original incident widespread.

Results would be gathered from service metrics, operation histories, and traces across interfaces. OpenTelemetry provides one available route for this data, with common interfaces for metrics, logs, and traces, as the Cloud Native Computing Foundation (CNCF) explains S11. A Saudi product does not require the invention of a Saudi monitoring protocol. Its original knowledge may lie in experiment design and the limits of interpretation, while open standards carry the evidence.

Finally, an “Execution Evidence Passport” would record the package version, environment version, injected changes, test-oracle outputs, reason for any stop, and limits on the conclusion's validity. This is a proposed research term, not an independent certification mark. A digital signature can protect a record against tampering, but it cannot make the conclusion true if the decision rule is weak. An experiment can be documented perfectly and answer the wrong question perfectly.

Figure 2. A proposed product architecture, not a deployed or published Saudi system. The arrows represent stages of knowledge translation that require human review; they do not show that automation is possible or safe in every sector S06S07S09S11.

To keep the thesis from ending as conference-program copy, we implemented a small computational model with declared limits. We wrote 16 synthetic test contracts across four families: policies with missing fields, repeated feature bundles that exceed capacity constraints, stale or unauthenticated configuration versions, and connection attempts that continue retrying. We ran the contracts against four synthetic software implementations: a naive implementation, one with input checks only, one with resource bounds only, and one combining the four required safeguards.

The program actually executed 64 test cases, recording each case with its expected and observed result. The naive implementation agreed with 7 of 16 cases; the input-validation implementation with 12; the resource-bounds implementation with 11; and the combined implementation with 16 S13. Every one of these figures is an output of code written to represent the example, not a failure-detection rate from real companies. No artificial intelligence was used to extract the cases from incident reports; we designed the contracts manually to test the idea of representing and running them.

Figure 1. The number of cases in which each implementation's output matched the declared test oracle, from four cases in each family. The proportions do not represent a commercial capacity to detect failures or their probability of occurrence. The code, case files, and results are available in the separate attachment S13.

The experiment's main lesson is not that more guards always produce more resilience. That would be circular: we wrote the fourth implementation to pass the contracts we also wrote. It shows something more modest and useful: a functional description can be converted into inputs, a decision rule, and a reproducible result record, while keeping visible the difference between a system failure and a test's failure to understand the system. Moving from this limited exercise to a production database, payment platform, or telecommunications network would require different experiments, contracts, and definitions of success.

A foreign customer will not buy “the history of the internet” from a startup; it is freely available to read. Nor will it pay for a paraphrase of a report already written better by its authors. It may pay if the package saves difficult work: turning an incident into a pattern that can be represented safely in the customer's architecture and tying the execution result to its service obligations. This service has an integration cost that could consume the licence fee if every customer needs two months of customization.

I can imagine three distinct initial products, which must not be conflated in sales:

These are proposed categories, not names of companies that have been created or services that have been sold. The work could begin with the first package and grow into the second if customers prove they need transfer across environments. Jumping directly to a comprehensive product that understands everything would more likely produce an expensive consulting practice wearing the mask of a software platform.

In April 2025, the Saudi Export Development Authority (Saudi Exports) took part in GITEX AFRICA in Marrakech with a “Made in Saudi” pavilion that included 28 national technology and telecommunications companies, according to the Saudi Press Agency (SPA) S04. In July 2026, LEAP East in Hong Kong included Saudi participation and relationships among technology companies, including an announcement that Elm had signed a memorandum of understanding with Huawei in artificial intelligence and digital infrastructure S05.

These are concrete signs of international contact and promotion channels. They are not a purchasing record for a Saudi resilience product, and they do not establish recurring revenue from a foreign customer. Access to a trade show helps a company meet buyers. An export industry begins to emerge when an independent buyer signs a second contract because it no longer wants to do without the first product.

Saudi Arabia does not need to create every tool in the global software stack to specialize in this gap. It has a large operating market, potential operators across computing, telecommunications, services, payments, and logistics, and research and engineering capabilities that can be developed. Yet describing this environment as an “ideal laboratory” is a hypothesis that must be tested. A local customer may be adept at organizing a large project but unwilling to expose its services to hypothetical tests. The product may remain trapped in bespoke requests that are hard to repeat. Willingness to pay, permission to test, rights to use incident data, and the marginal cost of adding a new customer are all questions that broad claims about national advantages cannot resolve.

Gulf experience of compound pressures may also help create useful test cases for digital supply chains, network timing, thermal loads on computing systems, and changing connectivity sources. Moving from a complex reality to general knowledge is legitimate, provided the patterns come from public data or authorized environments, rather than sensitive facility maps or access details that give an attacker a ready-made target list.

A local organization might build an attractive platform capable of running a hundred contracts, only to discover that post-sale maintenance costs more than the licence fee. Exportable software needs unit economics that do not confuse recurring revenue with a one-off development project. A single experiment may require new understanding of a customer's transactions, interfaces, and safety rules, along with legal review, documentation in the customer's language, and execution support. It may then change when the system is updated.

I will not assume a market size or an average global subscription price. A founder should instead test four ratios with actual pilot customers: customization hours per customer, the proportion of contracts that run without specialist intervention, maintenance cost for each new version, and the rate of paid renewals outside Saudi Arabia. “We have an international customer” is not enough. Consulting performed in another country is an export of a professional service, but it may not be a deep-technology software product that can be replicated at attractive economic multiples.

From the buyer's side, one can write an approximate upper bound for the expected annual value of testing: the number of failure families the tests might prevent before they reach users, multiplied by their true probability and the avoidable loss, less the cost and development impact of the tests and the price paid. Yet probabilities for rare failures and counterfactual losses are not easy to know. The expression is useful as a framework for purchasing decisions; it cannot be populated with imaginary figures and presented as a guaranteed Return on Investment (ROI).

There is also a deep commercial tension. If a company sells “test success,” it gains an incentive to write tests that are easy to pass. If it sells “the number of failures discovered,” it gains an incentive to make cases stranger and less relevant. The product therefore needs measures that are harder to manipulate: blind tests not written during service development, negative cases that should not be rejected, comparisons with existing tools, and the full cost of execution. This is not governance laid on top of the work. It is the quality of the product itself.

A language model can rapidly read thousands of incident reports and create initial families of hypotheses. Code-generation models can write an adapter or case generator and run it in a closed computational laboratory. But an incident report is not a complete specification of the system that failed. It may omit an internal interface, remove sensitive data, or use general language that leaves the sequence of events unspecified. What appears in the text as a “cause” may be a temporal coincidence or a summary of the final operational decision.

I therefore propose evaluating the compiler at three independent levels: accurate evidence retrieval from the report, executable validity, and truthful judgment of system behavior in new environments—cross-system transfer validity. The first does not establish the second, and correct code does not guarantee the third. A test can run without errors and still judge legitimate behavior incorrectly.

This reveals one of artificial intelligence's more interesting paradoxes. It is relatively easy to make a machine suggest “what should break.” It is harder to make it understand what must remain true when conditions change. That is the work of deep computer science, from semantics and consistency to temporal logic and state modeling. As code generation becomes easier, the value rises of a question that people and machines can formulate together in falsifiable terms.

The strongest objection does not say the idea is bad. It says the idea may be a feature inside existing tools rather than an independent company. If a cloud service can generate the experiment, execute it, and display its result inside the customer's platform, why should the customer buy an external compiler? If a specialist project such as Jepsen has provided independent consistency testing for distributed systems for years, where exactly is the new gap? If the incident record omits the proprietary specifications that produced the failure, what will rediscovering them for every customer cost?

The answer is not a claim of superiority. We need a commercial experiment that distinguishes three possibilities: specialist packages sold with limited support may succeed; a strong offering may prove to be valuable engineering consulting but fail to scale like software; or both may lose to free tools and services from major platforms. The third outcome would not be a national defeat. It would save money and time that could be invested in another problem.

A real market-entry test could settle the question: a small Saudi team, two or three packages for public incident families, two local customers consenting to safe experiments, followed by customers in other countries with no reason to flatter the country or founder. For each customer, measure installation time, how many lines of code changed, whether the test found a defect missed by the current suite, whether it remained useful after two releases, and whether the customer paid for it again. The negative control should come first: a customer whose tests are already strong and who may not need the product.

Between 2026 and 2035, three conditional outcomes are imaginable. In the first, cloud providers absorb the idea into their products, making it smarter to sell them specialist adapters or advanced testing services than to compete on the general platform. In the second, a market settles around sectors that require independent evidence across multiple vendors, allowing an independent product to succeed by demonstrating the limits and portability of its tests. In the third, the work remains a series of consulting engagements: useful engineering knowledge, but insufficient to build an industry with recurring software revenue.

These are not estimated probabilities. Each future has an observable signal: buyers' reliance on integrated tools, growth in multivendor contracts, or persistently high customization hours in every project. We cannot write the conclusion first and then select news that makes it look inevitable.

The most consequential national opportunity is deeper than building a company that uses artificial intelligence. It is the creation of an executable knowledge asset: problems the world has already faced, restated as tests that can be transferred, run, and inspected, followed by learning from the differences between the experimental and real-world outcomes. A Saudi team gains research experience where words struggle to substitute for proof; the customer acquires a good whose metaphors it need not believe.

Traditional factories take in raw material and produce an object that can be weighed. The proposed factory might take in an incident report and produce a condition that can be falsified. If it can sell that condition repeatedly to independent buyers, we may have the nucleus of a new industry. If it cannot, we will at least have answered a useful question that impressive names leave unresolved: which part of the knowledge of failure can cross borders without losing its meaning?

1. Cloudflare (Matthew Prince), Cloudflare outage on November 18, 2025, 18 November 2025. https://blog.cloudflare.com/18-november-2025-outage/
2. Google Cloud, Incident details: June 12, 2025 Google Cloud service outage, original post-incident timeline and root-cause updates, 2025. https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW
3. Federal Communications Commission, Public Safety and Homeland Security Bureau, February 22, 2024 AT&T Mobility Network Outage, July 22, 2024. https://docs.fcc.gov/public/attachments/DOC-404150A1.pdf
4. Saudi Press Agency, ‘Made in Saudi’ Pavilion at GITEX AFRICA Showcases 28 Leading Tech Companies, 14 April 2025. https://www.spa.gov.sa/en/N2297562
5. Saudi Press Agency, Elm Signs MoU with Huawei to Advance Cooperation in AI and Digital Infrastructure, 9 July 2026. https://www.spa.gov.sa/en/N2630981
6. AWS, Bootstrap your chaos engineering journey with AWS Fault Injection Service Scenarios Library, 1 October 2024. https://aws.amazon.com/blogs/mt/bootstrap-your-chaos-engineering-journey-with-aws-fault-injection-service-scenarios-library/
7. AWS, Chaos engineering made clear: Generate AWS FIS experiments using natural language through Amazon Bedrock, 13 May 2025. https://aws.amazon.com/blogs/publicsector/chaos-engineering-made-clear-generate-aws-fis-experiments-using-natural-language-through-amazon-bedrock/
8. AWS, Stop conditions for AWS FIS, official documentation. https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html
9. Jepsen, Analyses and Research Ethics, author-operated research and testing documentation. https://jepsen.io/analyses and https://jepsen.io/analyses/ethics
10. Principles of Chaos Engineering, Principles of Chaos Engineering. https://principlesofchaos.org/
11. Cloud Native Computing Foundation, OpenTelemetry has graduated… Now what?, 24 July 2026. https://www.cncf.io/blog/2026/07/24/opentelemetry-has-graduated-now-what/
12. AWS, REL12-BP04 Test resiliency using chaos engineering, AWS Well-Architected Reliability Pillar. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html
13. Author-supplied materials, Executable incident contract toy demonstration. See analysis/reproduce.py, data/contract_cases.json, data/contract_test_results.csv, data/contract_summary.csv, and data/execution_meta.json in the article package. These are explicitly artificial inputs and outputs, not observed Saudi or other operators' incidents.

Executable Failure Contract; Incident-to-Test Compiler; invariant; test oracle; Property-Based Testing; Differential Testing; Metamorphic Testing; retry storm; distributed traces; proposed Execution Evidence Passport; unit economics; transferable value.

Disclosure: This article was edited and analyzed with assistance from artificial intelligence and with reference to public sources. No interviews or experiments on production systems were conducted, and neither the article nor the accompanying paper has undergone independent peer review. The named concepts proposed here are not published products or standards.