April 14, 2026

What We Take to the Moon

Part I: The Thought Experiment

1. The Lunar Operations Contract

Imagine that your company has just been awarded a contract to provide the operational software for the first permanent lunar settlement. Not the rockets, not the habitats, not the rovers. The systems that keep track of what is in the warehouse, what was repaired this week, which colonist filed which medical complaint, how much oxygen has been produced by the algae bioreactors over the last fourteen-day cycle, what the spectrometer found in the regolith yesterday, and which of the printed parts in inventory have already been allocated to the next maintenance EVA. Ordinary operations software. The unglamorous substrate that makes any complex enterprise function.

You have the contract. You have the budget. You have the deadline. The first crew arrives in seven years. The settlement is intended to be permanent. The crew will rotate every two years. The sponsors include a consortium of national space agencies, three commercial space companies, two universities, and four equipment manufacturers, each of whom has been promised that their data will flow into the central operations system without losing fidelity. The settlement is expected to operate for at least fifty years. After year ten, resupply windows will be every six months at best.

How would you build this?

If you started with the data architecture practices that are standard in enterprise software today, the answer is that you would build a system that would kill people inside of two years. Not from one catastrophic flaw, but from the accumulation of small definitional drifts that produce, over time, the same operational dysfunction that mid-sized terrestrial manufacturers experience as ten-day close cycles and inventory variances and the occasional shipment that arrived but cannot be found. On Earth, those failure modes cost money and time. On the Moon, they cost lives.

This is not a thought experiment about space. It is a thought experiment about your business. The Moon is the diagnostic mirror that makes the discipline-deficit in modern enterprise data visible at a scale where it cannot be rationalized away.

2. What Would Fail, and Why

Take the list of what your settlement software would have to do well, and walk it through the standard practices that produce most enterprise systems today.

The medical records system records a colonist’s blood pressure on a tablet that the colonist taps through. Each medical clinician trains their own auto-fill habits over the course of months. The blood-pressure entry sometimes captures only the systolic number when the diastolic was meant to be edited later. The unit is sometimes mmHg, sometimes mmH2O, sometimes blank because the field doesn’t validate. The clinic in habitat module B uses a slightly different schema because it was built six months later by a different vendor whose API contract was negotiated on a different reference epoch. Three years in, the long-term blood-pressure trends across the colony cannot be reconstructed reliably, because the data has drifted in ways nobody documented. A subtle pattern of cardiovascular degradation specific to lunar gravity goes undetected for an additional eighteen months. The findings, when they finally surface, are conditioned on data that nobody fully trusts.

The life-support telemetry pipes sensor data into a central monitoring system. Each subsystem is built by a different supplier, each with its own preferred way of describing oxygen flow, CO2 partial pressure, water reclamation efficiency. The integration layer translates between them. It works most of the time. The translations are written by an engineer who left the project in year four. After her departure, when one supplier updates its firmware to report partial pressures in slightly different units, the integration layer silently passes through values that look right but represent a different physical reality. The CO2 scrubber that should be replaced at 2.8 kPa has, due to the unit change, been operating against a nominal 2.8 kPa that is actually 3.1 kPa. By the time the discrepancy surfaces, several crew members have developed mild but persistent headaches that are attributed to sleep disruption.

The inventory system records every printed part, every consumable, every spare module. Two years in, the relationship between the requisition system, the fabrication queue, and the stockroom has accreted enough special cases that nobody can answer simple questions like “how many backup oxygen tanks do we have, and where are they.” The stockroom maintains a parallel spreadsheet that is the actual source of truth. The official system shows numbers that are consistently off from the spreadsheet by amounts that nobody can explain. Mission control on Earth bases its resupply planning on the official system. The first deficit shows up when an EVA team needs a part that the system says is in stockroom B and that the stockroom can’t locate.

The exobiology lab samples regolith every Tuesday and runs spectroscopy. The results are saved to the lab’s internal database. They are also exported to the central operations system in a different schema. The two schemas drift slowly. After a year, comparisons across the two databases produce contradictions that nobody can resolve. A pattern that should have been detectable in the cross-referenced data — a localized subsurface mineral concentration that would have changed the placement of the next ISRU pilot — is not detected. The pilot is sited on the assumption of a different geology and underperforms by a factor of two.

The maintenance logging system records every repair, every part swap, every diagnostic. Each technician has their own habit for filling out the optional fields. Some are exhaustive. Some leave them blank. Some develop their own shorthand in the free-text notes. After three years, the maintenance corpus is internally inconsistent enough that machine-learning models trained on it to predict equipment failure produce results that the maintenance team has learned not to trust. The team falls back to tribal knowledge, which is a problem because the tribe rotates every two years.

None of these failure modes are speculative. Every one of them is a current pathology in terrestrial enterprise software, observed and well-documented across thousands of mid-sized companies. The novelty in the lunar context is not the failure mode. The novelty is the cost of the failure mode and the impossibility of routing around it. On Earth, you can run a parallel spreadsheet, hire a contractor to clean up the data, do an audit, replace the system. On the Moon, those are not options. The system is the operations. The failure of the system is the failure of the colony.

3. Why the Failures Are Architectural, Not Operational

The natural response to the list above is to say that those problems are caused by sloppy procedures, undertrained staff, or insufficient quality control. The natural response is wrong, and the reason it is wrong is the reason this essay exists.

Every failure in the list is what you get when you take the standard architectural practices of modern enterprise software and apply them to a domain where the consequences of those practices are unforgiving. The practices are the cause. The procedures are the symptom. You cannot train your way out of an architectural defect, and you cannot quality-control your way out of an absent shared vocabulary. The clinicians who recorded blood pressure imperfectly were not undertrained. They were operating in a system that had been designed to accept the input they gave it and to silently propagate the inconsistencies downstream.

The same is true of every example. The integration layer that lost track of the CO2 unit change was operating exactly as designed; it had been designed by an engineer who knew the discipline cost of building the rigorous version and made a reasonable trade against the deadline. The inventory system whose numbers diverged from the spreadsheet was operating exactly as designed; it had been built with the customary number of custom fields and the customary tolerance for fuzzy joins. The exobiology data that drifted across two schemas was operating exactly as designed; it had been built by two teams who had been given separate budgets and separate vendors and no shared canonical model to map to.

What is happening in the thought experiment is not failure. It is the standard performance of the standard architecture, applied to a context where the standard performance is not survivable.

If you accept that, you have to accept its corollary. The standard architecture is not adequate for the standard terrestrial context either. It has been tolerated there because the failure modes have been diffuse enough, slow enough, and politically displaceable enough that no individual decision-maker has had to confront the cost. The Moon is not a special case. The Moon is the case where the diffusion runs out and the cost localizes onto the people who built the system. Everywhere else, the cost has been hidden by the buffers of slack, time, and externalization that earthbound enterprise still affords.

There is a version of the objection to this argument that is worth addressing directly, because it is the version most readers will reach for: the lunar thought experiment unfairly stacks the deck by populating it with different vendors, different suppliers, different teams. Of course you get fragmentation when you wire together a dozen contractors. Your terrestrial enterprise, the objection runs, is on a single ERP from a single vendor, deployed against a single database, designed to be one coherent system. That is supposed to be the protection.

The objection collapses under the slightest examination. Your single-vendor ERP is not coherent. It was never coherent. It is a collection of modules — Finance, Sales and Distribution, Materials Management, Production Planning, Quality Management, Plant Maintenance, Human Resources — each designed by a different product team, sold to a different departmental constituency, customized at implementation time by a different functional consultant, and tuned over the years by different administrators who reported to different vice presidents. Each module’s notion of what a “customer” is, what an “order” is, what an “inventory item” is, what counts as “open” or “closed” or “released” was shaped by the political weight of the department that owned that module’s procurement decision. The schemas overlap but do not match. The validation rules contradict each other. The audit trails are scoped to the module that produced the event rather than to the entity the event is about.

This is not a multi-vendor problem dressed up as a single-vendor product. It is the same problem reproduced inside a single tenant of a single product, by the same mechanism, for the same reasons. Different stakeholders with different priorities lobby for different data shapes. The product accommodates each one, because accommodation is what the product is sold on. The result is a system that looks unified from the marketing material and is fragmented from the moment its first tenant goes live. Single-vendor ERPs are multi-vendor systems wearing one logo. The lunar example is multi-vendor because realistic lunar systems will be multi-sourced. The terrestrial enterprise is multi-departmental within a single vendor because that is what every implementation actually produces. The fragmentation mechanism is identical. The only difference is that the terrestrial version is harder to see because the surface looks like one thing.

This is also why migrating from one ERP vendor to another does not solve the underlying problem. It carries the fragmentation forward, because the next vendor’s modules will be procured, customized, and operated by the same departmental power structure that produced the fragmentation in the previous instance. The vendor changed. The mechanism did not. This is the thirty-year cycle the previous essay describes, observed from the inside of a single tenant rather than across the industry.

There is a second culprit that deserves equal billing, and it has been carrying the political dysfunction forward across the decades on its back. The data architecture underneath the major ERPs was designed in the late 1960s and 1970s. SAP R/2 launched in 1979. SAP R/3 in 1992 inherited the bulk of R/2’s data model and added a client-server presentation layer rather than re-architecting the substrate. The Oracle database that sits underneath enormous quantities of enterprise software was first released in 1977. The data-modeling assumptions baked into these systems — the notion of master data, the hierarchies of organizational units, the batch-oriented update cycles, the tightly-coupled application-database relationship, the single-instance assumptions about company-wide data ownership — were made before the personal computer was widespread, before TCP/IP was standardized, before the web existed, before the concepts of microservices or event sourcing or eventual consistency or semantic interoperability had been articulated. They were correct for the world that built them. They are sixty years old.

What has been called “modernization” in the intervening decades has, with very few exceptions, been wrappers. Web front-ends were grafted onto green-screen transaction logic. SOAP services were grafted onto RFC calls. REST APIs were grafted onto the SOAP services. In-memory column stores like HANA were grafted underneath the same application schemas, allowing them to run faster against fundamentally unchanged data models. Cloud-deployed versions of the same products are lift-and-shifts that preserve the data assumptions intact while changing the operational surface. Each wave of “modernization” has been a coat of new paint over a foundation that was poured before the participants were born. The substrate has not been re-architected. It has been preserved, patched, wrapped, and re-marketed.

The result is that the political fragmentation described above is not running on modern software at all. It is running on software whose data substrate was conceived in an era when most of what we now know about data architecture had not been thought of yet, and whose participants — the engineers writing the integration code, the architects designing the cloud migrations, the consultants planning the implementations — are working around assumptions that were sensible in 1975 and are obstacles now. The customizations and departmental fragmentation pile up on top of that obsolete substrate, layer by layer, decade by decade, each one a partial workaround for what the underlying architecture cannot do natively. Every workaround calcifies into permanent scar tissue because the next workaround has to assume the previous one is permanent.

The two culprits are not separable. The political mechanism produces the customizations. The architectural mechanism makes the customizations stick because the substrate cannot evolve to absorb them. A modern data architecture would let the political fragmentation play out and then refactor the model underneath it as the patterns clarified. A 1970s data architecture cannot refactor; it can only accumulate. The fragmentation that should have been a temporary expression of organizational learning becomes, instead, a permanent feature of the system, because the substrate has no mechanism for letting it dissolve back into the model once the lesson has been learned. Forty to sixty years of organizational learning has been frozen into the schemas, layer over layer, and the schemas cannot release it.

The Moon thought experiment exposes both culprits at once. A lunar settlement built on the same architectural foundation, populated by the same political mechanism, would die the same way for both reasons: the people would fragment the data along departmental lines, and the substrate would be unable to converge on a coherent picture even if the people were willing. Either failure alone would be lethal. Together, they are the architecture of slow-motion collapse that earthbound enterprise has been demonstrating, in slower motion, for decades.

The thought experiment is useful precisely because the buffers do not exist there. When you ask “would my data architecture survive on the Moon,” what you are actually asking is “is my data architecture good, when measured by the standard that would apply if the consequences of its defects were not so easy to ignore.” The answer is the same answer your terrestrial systems have been giving for years, but you have not had to listen to it because nothing has forced you to. The Moon, in this frame, is a ruthless auditor.

Part II: The Substrate Argument

4. Discipline as Rate Limit

The Moon thought experiment surfaces something that is true terrestrially but harder to see: data discipline is not one of the problems an organization has to solve. It is the substrate on which the rate of solving every other problem depends.

Take the list of unsolved engineering problems that gate sustained spaceflight. Radiation biology. Closed-loop life support. In-situ resource utilization. Long-duration propulsion. Crew psychology. In-space manufacturing. Each of these is, on its own merits, a hard problem. None of them is data architecture. But every one of them is rate-limited by the absence of a shared empirical foundation that would let researchers, engineers, and operators learn cumulatively rather than redundantly.

Radiation biology is gated on the ability to pool longitudinal exposure data across thousands of subjects, decades, and institutions. NASA, ESA, JAXA, the various national space agencies, the commercial space-medicine community, and the academic radiobiology field all generate data that should aggregate into a unified empirical structure. They do not, because each program has its own data model, its own measurement protocols, its own definitions of what constitutes exposure or confound. The empirical foundation that would let radiation biology advance at the rate the underlying science permits is not assembled, because the data does not interoperate. The science is rate-limited by the architecture.

Closed-loop life support has been studied in BIOS-3 in the 1970s, in Biosphere 2 in the 1990s, in MELiSSA at ESA, in MIT’s Mars greenhouse work, in the Chinese Lunar Palace. Each program has produced thousands of sensor-hours of data. Each program has used its own schema. The cumulative learning across sixty years of closed-loop experiments is dramatically less than the raw experimental hours suggest, because the results do not pool into a comparable corpus. We have repeatedly relearned lessons because nobody can find the previous learnings in a queryable form.

ISRU and lunar regolith characterization is happening at dozens of laboratories around the world, each producing slightly different parameter sets for what is supposedly the same material. Cross-laboratory comparisons require work that exceeds the original characterization effort. The pace of materials innovation in space contexts is bounded by how fast any single program can iterate, rather than by what the field collectively knows.

Propulsion test data, the most expensive data in aerospace, is held in vendor-specific formats by SpaceX, Blue Origin, ULA, Rocket Lab, ESA, and the various academic groups. Cross-organizational learning is approximately zero. The number of cycles each team can run is bounded by their own test capacity. The propulsion-innovation rate that would be possible if test data were interoperable is many times what is actually achieved.

The pattern is not that data discipline is one of the unsolved problems. The pattern is that the absence of data discipline is what is preventing the other unsolved problems from being solved at the rate the underlying science would permit. The substrate is the rate limit. When the substrate is degraded, every problem above it advances slower than it should.

This is exactly the dynamic at work in your business.

5. The Same Pattern, Closer to Home

Substitute “your company” for “the space industry” and “competitive advantage” for “lunar settlement” in the paragraphs above. Run the substitution carefully. The argument does not weaken.

Your company has, over the last fifteen years, accumulated terabytes of operational data: every sales transaction, every manufacturing event, every customer interaction, every quality finding, every supplier delivery. That data, if it cohered, would constitute an empirical foundation that would let you make better decisions than you currently do. It does not cohere. The CRM does not agree with the ERP about who the customers are. The shop floor system does not agree with the planning system about what was produced. The quality database does not agree with the warranty database about which lots had which problems. Each system is internally consistent. Across systems, the empirical foundation is fragmented in ways that nobody has the bandwidth to repair.

The result is that the rate at which your company can learn from its own data is dramatically lower than the rate at which the underlying patterns would permit, if the data interoperated. The patterns are there. The data exists. The architecture is what is preventing the learning from happening. This is not a metaphorical similarity to the space-industry problem. It is the same problem, at a smaller scale and with cheaper consequences.

Now consider what happens when you try to deploy AI on top of this substrate. The promise of enterprise AI is that it will surface patterns no human analyst would find. The reality, increasingly visible through Gartner’s reporting and the experience of any organization that has piloted seriously, is that AI deployed on top of incoherent data produces fluent confidence on top of unreliable inference, and the operators learn to distrust it within months. The 95% GenAI pilot failure rate that MIT’s NANDA initiative documented in its July 2025 State of AI in Business report ^[1] is not an indictment of the AI. It is an indictment of the substrate that the AI was trained on. The AI is doing exactly what AI does. The substrate is not what AI requires it to be. Gartner’s parallel finding that 60% of AI projects without AI-ready data will be abandoned through 2026 ^[2] points at the same mechanism from a different angle.

The 2027 SAP ECC migration deadline ^[3] is the substrate problem materializing into a forced executive decision. Every company on ECC has to make a decision about what to migrate to and how to handle the data they have accumulated over the lifetime of their ECC instance. There is no such thing as an ECC substrate that is in good order. ECC instances were broken on go-live day — that is the architectural condition the platform was sold under, with custom fields, custom modules, and integration scar tissue accumulating on top of an already-fragmented foundation. They have not improved with age. The migration question is therefore not whether the substrate is good, but how degraded it is, and consequently how much remediation work has to happen during the migration window itself. The companies that recognize this and budget the substrate work as the precondition will arrive on the new system with most of the dysfunction left behind. The companies that treat it as a software-replacement project will spend three to five times their planned budget, deliver eighteen to thirty-six months late, and arrive on the new system with most of the same data pathologies they had on the old one. The migration is the moment where the substrate-quality bill comes due.

You can extend the list. The replication crisis in pharmaceutical research is a substrate problem. The data-quality issues in machine learning research are substrate problems. The chronic difficulty of cross-departmental analytics in any organization above two hundred employees is a substrate problem. The increasing difficulty of doing reliable epidemiology, climate science, or genomics at the rate the underlying science would permit is a substrate problem. In every case, the rate of progress in the headline domain is bounded by the discipline that has or has not been built into the data infrastructure underneath.

The Moon thought experiment makes this visible because the consequences are unforgiving and the duration is long. The same dynamic operates in your quarterly forecasting, your warranty analytics, your supply-chain optimization, and your AI roadmap. It is operating now. It will continue to operate. It does not stop operating because nobody is paying attention.

6. The Voices Already Saying This

The argument in this essay is not original to me. It has been made, in pieces, by a number of practitioners and writers who have been describing one or another facet of it for some time.

Cory Doctorow has been writing about extraction-based platform dynamics under the banner of “enshittification” for several years, and consolidated the argument in his 2025 book Enshittification: Why Everything Suddenly Got Worse and What To Do About It ^[4]. His framing applies most visibly to consumer technology, but the underlying mechanism — that platforms accumulate value by erecting switching costs, then extract that value by degrading the experience — is precisely the dynamic that has produced the enterprise data architecture this essay describes. The substrate is degraded because degrading it is profitable for the parties who control it.

Benn Stancil, formerly chief analyst at Mode and now writing at Every, has documented for years the dysfunction of the modern data industry from inside it ^[5]. His phrase “labyrinthine moats” describes the same lock-in mechanism that the substrate problem depends on. The data industry’s preferred solutions to its own dysfunction tend to be more tooling, more layers, more vendors. Stancil’s quieter argument is that the substrate problem cannot be solved by adding more software to the top of it.

Chad Sanderson and the data contracts movement have identified the schema-agreement problem at the producer-consumer boundary ^[6]. Their work treats the symptom seriously and has produced real tooling. They tend to stop short of the architectural critique that this essay makes, because the contract-level fix is operationally tractable in a way that the architectural fix is not. The contract is a band-aid on a wound the architecture inflicted. It is a useful band-aid. It is not a cure.

Martin Kleppmann’s Designing Data-Intensive Applications ^[7] is the book that engineers reach for when they want to understand what serious data architecture looks like at scale. Kleppmann does not write about ERP, but the principles he documents are the principles that the substrate argument depends on. The book is more than a decade of careful thinking distilled into something a working engineer can apply. It is the most important text in this space, and almost nobody in the enterprise-software vendor ecosystem has internalized it.

The Kimball Group, in 2010, published a sharp critique of industry-standard data models titled “Industry Standard Data Models Fall Short” ^[8] that was correct then and is still correct now. The critique was largely ignored by the industry, which continued to ship the same kind of bloated, committee-designed canonical models that the critique objected to. It is worth rereading because it is an early statement of the position this essay extends.

Frank Pasquale ^[9] and Lina Khan ^[10] have made the regulatory and antitrust case for treating the platform-power problem as a structural rather than a consumer-protection issue. Their work is upstream of the enterprise-software liability case that has not yet been brought but that is becoming, year by year, more obviously necessary.

You are not, if you are reading this and recognizing the pattern, alone. There are perhaps two dozen people writing seriously about pieces of the substrate problem. There is no consolidated voice yet. The discourse is fragmented because the problem is fragmented, and the people who could see the whole pattern have generally been too busy operating systems to write about them.

What is missing is the voice that connects the dots between the consumer-platform critique, the data-engineering practitioner critique, the academic database-theory tradition, and the specific operational dysfunction of enterprise software. That voice would not be saying anything new. It would be saying everything already being said, by everyone, in one connected place. That is the voice this essay is trying to be, in this essay and the one it follows.

Part III: What Discipline Actually Looks Like

7. The Successful Substrates

The places where data discipline has been built — the cases where humans have actually managed to assemble a cumulative empirical foundation across institutions and time — are visible enough that we can study what they have in common.

The metric system is the canonical example. A meter is a meter is a meter, in every laboratory in every country, defined originally by physical artifact and now by the speed of light. Before standardization, every village had its own units of measure, every guild its own calibration, every kingdom its own conversion table. Trade across boundaries required expert intermediaries. Science across boundaries was nearly impossible. After standardization, both became routine. The metric system was not adopted because it was technically superior to local units. It was adopted because the cost of fragmentation, once visible, became unacceptable.

The IUPAC chemical nomenclature is another. Before IUPAC, the same molecule had different names in different traditions. A French chemist’s “essence of vinegar” was a German chemist’s “acetic acid,” and reproducing each other’s experiments required cross-referencing through expert intermediaries. After IUPAC, any chemist anywhere in the world can name a molecule unambiguously and any other chemist can reconstruct the molecule from the name. The empirical foundation of chemistry could not have advanced past a certain point without that standardization, and the rate of chemical innovation accelerated visibly once it was in place.

International Air Transport Association airport codes are a smaller example with a clear structural lesson. Three letters per airport, globally unique, centrally maintained, available to anyone, modifiable only through a defined process. The result is that anyone in the world can write a flight itinerary that any other person in the world can interpret. The IATA system is mundane infrastructure. It is also a precondition for the entire modern aviation industry. Without it, every airline would be running on its own internal codes and translation tables, and the cost of operating across boundaries would consume most of what air travel currently produces in value.

Standard time zones, established in the late nineteenth century, are a case where the discipline was forced by the railroad industry’s inability to operate across the chaos of local mean time. Before standardization, each town set its own clocks by local noon. Trains, which had to operate on schedules that crossed many local times, were the first industry to find this intolerable. The standardization that followed did not benefit the railroads alone. It made everything from international finance to scientific collaboration to wartime coordination possible. Standardization that began as an industrial necessity became civilizational infrastructure.

The Gregorian calendar, adopted at different times by different nations, eventually became a universal standard for date-keeping. Before it was universal, the same date in correspondence between two countries could refer to different days. After it was universal, a date was a date, anywhere. Modern logistics, finance, and science depend on this so completely that it is invisible.

In every one of these cases, the standardization was resisted at the time by the parties whose local conventions had to be displaced. Local units of measure were profitable for local merchants who controlled the conversion. Local time was a matter of civic pride. Local chemical names reflected national scientific traditions. The standardization happened, in every case, because the cost of fragmentation eventually exceeded the political cost of standardization, and a moment arrived where the standardization was forced through.

The lesson is not that standardization happens easily. It does not. The lesson is that, in domains where humans are trying to operate at scale across institutions and time, the standardization eventually happens, and the domains that get there first are the ones that capture the compounding benefits earliest. Before the metric system, every science was bounded by its national reach. After it, science became transnational. Before IATA codes, aviation was a collection of national operators. After them, it was a global industry.

The substrate is what determines whether a domain can scale. It is determined by deliberate choices made early, by participants who often resisted the choices, in moments where the cost of fragmentation finally exceeded the cost of agreement. Enterprise data is in the late phase of that arc, where the cost of fragmentation has been mounting for thirty years and the standardization has not yet been forced. The Moon thought experiment makes the cost visible at a scale that cannot be hand-waved away. The 2027 ECC migration deadline is the moment where the cost begins materializing in mid-market boardrooms.

8. What Discipline Requires

The substrates that succeeded share three properties, which are the same three properties the previous essay identified and which are worth restating in this context because they are the conditions for cumulative knowledge in any domain that needs it.

The vocabulary has to be fixed. Not mostly fixed. Not extensible by well-meaning participants. Fixed. A meter is a meter. An IATA code is exactly three letters. An IUPAC name is the IUPAC name. The participants in each system can do anything they want with what is inside the standard — what they trade, what they fly, what they synthesize — but they cannot modify the envelope. The moment the envelope is extensible, every participant becomes incentivized to extend it in ways that benefit them locally and degrade the system globally. The extensibility is the failure.

The custodian of the standard cannot benefit commercially from its adoption beyond its existence. The metric system is maintained by an international body that does not sell metric implementations. IATA is a cooperative of member airlines. IUPAC is a federation of national chemistry societies. The General Conference on Weights and Measures has no commercial interest in the metric system’s adoption. This neutrality is not incidental. It is the precondition that makes universal adoption rational for the participants. If the standard’s custodian were also the standard’s largest commercial beneficiary, every other participant would have a reason to propose an alternative. Every standardization attempt that has been led by a single commercial actor with extractable interest in the standard’s success has failed for this reason. The successful standards have been led by parties whose interest was in the standard’s existence, not in capturing the value of its adoption.

The constraint has to be enforced at the infrastructure layer, not the application layer. A non-conforming chemical name does not register in the chemical literature. An invalid IATA code does not appear in any flight system. A non-metric measurement is silently invisible to instruments calibrated to the metric system. The enforcement is automatic. It happens before the participant’s intent is consulted. This is the property that distinguishes an actual standard from a marketing claim. Every successful standardization has a moment where deviation is rejected by mechanism rather than negotiated between parties.

These three properties are not preferences. They are the necessary and sufficient conditions for a cumulative empirical substrate to form in a domain that requires one. They have been discovered empirically, through a hundred and fifty years of attempts at standardization across many fields. They are the discipline that determines whether an empirical foundation can be built at all.

The enterprise software industry has, over the last thirty years, operated in deliberate violation of all three. The vocabularies of major ERPs are extensible by every customer. The custodians of those vocabularies are the largest commercial beneficiaries of their adoption. The constraints are enforced at the application layer, not the infrastructure layer, which means they are negotiated between parties and frequently bypassed. The result is the substrate that this essay is describing. It is not an accident. It is the predictable consequence of architectural choices that violate the conditions under which cumulative knowledge becomes possible.

9. What Cumulative Knowledge Buys

The reason the substrate matters, in any domain, is that it is the precondition for compounding. Compounding is what lets a discipline produce results that are larger than the sum of the individual contributions to it. Without compounding, every researcher, every operator, every analyst is limited to what they can build from scratch within their own institutional and temporal horizon. With compounding, each participant builds on the foundation of every prior participant, and the field as a whole produces results that no individual participant could have reached.

The clearest example is in physics. The standard model of particle physics is the cumulative product of more than a hundred years of experimental data, theoretical work, and instrumentation, contributed by thousands of researchers across dozens of institutions. The standard model is not the product of any single laboratory or any single career. It is the product of a substrate — peer review, open publication, agreed-upon units, shared notation, common training — that allowed the contributions to compound. Every subsequent generation of physicists started from the foundation the previous generation left and built upward. The pace of physical discovery in the twentieth century is what compounding looks like.

The contrast in industries that lack the substrate is sharp. Aerospace propulsion has been worked by the brightest engineers for seventy years and, by a measure of what the field collectively knows versus what the field could know if its empirical foundation interoperated, has produced perhaps a third of what the underlying science would permit. Pharmaceutical drug discovery has been working the same biochemistry for forty years and is increasingly producing diminishing returns per dollar invested, in part because the empirical foundation across institutions does not pool. The replication crisis in psychology is the visible surface of a deeper coordination failure that has been operating for decades.

Your company’s analytics function is the same dynamic. The empirical foundation that would let your sales, operations, finance, and quality teams reason from a shared picture of the business does not exist, because the data does not interoperate. Every analytical question requires a custom data-engineering project to assemble the inputs. Every project produces a different result depending on the assembly choices. The cumulative analytical knowledge of the company across years of work is far less than the raw effort would suggest, because the work does not compound. It is reset, partially, every time a new analyst joins, every time a new tool is adopted, every time a new question is asked.

This is the cost of the substrate problem expressed in terms of opportunity rather than failure. The companies that operate on a cumulative empirical foundation can answer questions, ship products, and deploy intelligence at a rate that companies operating without one cannot match. The gap is not constant. It grows. A company with good substrate compounds. A company without it does not. Over a decade, the gap becomes structural. Over two decades, it becomes existential.

This is the actual prize for fixing the discipline problem. Not a slightly cleaner dashboard. Not a more efficient month-end close. The ability to compound. The ability to produce results that scale with the data you have rather than with the headcount you can throw at it. The ability to deploy AI systems that work, because they are built on a substrate the AI can actually reason over. The ability to navigate a 2027 migration without losing institutional knowledge in the process. The ability, eventually, to operate at the kind of scale that humans operating off this planet will require, because the discipline that lets you operate well terrestrially is the same discipline that determines whether you can operate at all in environments where mistakes are unforgiving.

Part IV: What Executives Should Do, and What Time Is Left

10. The Honest Executive Assessment

If you are responsible for a significant operational system in any organization above small-business scale, the questions worth sitting with are uncomfortable.

The first question is whether your data architecture would survive the lunar test. Run the substitution for your own systems. Imagine that the cost of every data inconsistency, every silent translation error, every fuzzy join, every undocumented assumption, every custom field whose meaning is held in someone’s head, was paid in human consequences rather than in reconciliation hours. Would the system survive? In most organizations, the honest answer is no. The system survives terrestrially because the consequences of its defects are diffused across many people, many quarters, and many small inconveniences that nobody adds up. Concentrated, they would be intolerable.

The second question is whether the rate at which your organization can learn from its own data is approximately the rate at which the underlying patterns would permit. In most organizations, the honest answer is no. The data exists. The patterns exist. The architecture is what is preventing the learning from happening at the rate that would be possible. The gap between actual learning and possible learning is a measure of the substrate-quality deficit specific to your organization.

The third question is what your AI roadmap depends on, and whether the substrate it depends on actually exists. If you have signed off on AI initiatives expected to deliver material value over the next two to three years, those initiatives are betting on a data substrate of a quality that, in most organizations, has never been audited. The 95% pilot failure rate that MIT documented is the system telling you that the substrate is, in most cases, not what the AI requires it to be. Your roadmap is optimistic by some unknown but significant factor.

The fourth question is what happens in 2027, when the SAP ECC support deadline arrives and the migration moment becomes unavoidable for everyone on that platform. If you are on ECC, your substrate is degraded — that is the universal starting condition, not a worst case. The decision in front of you is whether to budget the substrate remediation as a deliberate, scoped piece of work that happens before or alongside the migration, or to assume the platform vendor’s promises about how their tooling will handle it for you. The first path is hard but produces a system that compounds. The second path is the path that produces the three-to-five-times overruns that have characterized every wave of ECC migrations to date.

These questions are not catastrophizing. They are diagnostic. The Moon thought experiment is useful because it makes visible what the diffuse terrestrial cost has been hiding. Once you have run the thought experiment honestly, the questions answer themselves.

11. What to Do This Year

If you accept the diagnosis, the operational implications are concrete enough to act on.

Audit the substrate. You cannot fix what you have not measured, and the measurement has to be structured in a way that an auditor, a regulator, or a migration team can trust. The first action is to commission a semantic audit of your data across the major operational systems — the kind of engagement that produces a deterministic, human-reviewed manifest of how each important entity (customer, part, order, inventory item, employee) is defined, populated, and reconciled across every system that touches it. The audit should not be AI-driven, because AI classifications drift and cannot be defended in front of an auditor or a regulator; it should produce the same answer every time it is run against the same data. It should be vendor-neutral, because an audit conducted by the vendor of the system being audited is not an audit. It should be scoped to complete in days rather than months, because a substrate audit that takes six months is a consulting retainer, not a diagnostic. The output is a baseline, a roadmap, and — often more valuable than either — a moment of organizational clarity about what you actually have.

Stop creating new debt. Every new custom field, every new point-to-point integration, every new dialect of an existing vocabulary is debt that will mature five to ten years out. The cost of preventing new debt is small relative to the cost of remediating old debt. Most organizations are still creating new debt as fast as they are remediating old debt, because the prevention requires governance discipline that the organization has not built. Build it.

Treat your AI initiatives as substrate-dependent. Any AI system that operates on your operational data is bottlenecked by the quality of that data. Treating AI as if it were a separable initiative from the substrate is the most common cause of AI pilot failure. The realistic AI roadmap budgets the substrate work as a precondition, not as a parallel track. The companies that get this right will deploy AI that works. The companies that do not will continue to produce confidently wrong recommendations until they stop trying.

Consider the migration decision deliberately. If you are on SAP ECC, the 2027 deadline is a forced decision point, and the substrate work should ideally be done before the migration, not during it. If you are on another platform, the question of when the next migration will be forced is worth asking explicitly, because the answer is probably sooner than you think and the substrate quality is the largest determinant of outcome.

Hire or reassign someone whose job is the substrate. Most organizations do not have anyone whose responsibility includes the long-term integrity of the data architecture. Data engineers maintain pipelines. Data scientists build models. Database administrators tune queries. Nobody owns the question of whether the empirical foundation is in good order. Put someone there. Give them authority, give them a budget for the tooling that produces a deterministic baseline of semantic consistency — the kind of governance platform that can tell you, at any moment, how far each operational system has drifted from the shared vocabulary you are trying to maintain — and give them the organizational standing to refuse new customizations that would compound the debt. Their work will look, for the first eighteen months, like nothing is happening. After that, it will look like everything is starting to work.

Stop tolerating the dialects. Every organization has a moment, every quarter or two, where it could enforce a vocabulary discipline and chooses not to because the political cost is high. Reverse the default. The political cost of enforcing the discipline is paid once. The cost of not enforcing it is paid every quarter for the next decade.

12. The Time Left, and What It Means

The honest read on the calendar is that the next three years are decisive for any organization above mid-market scale, and the next ten are decisive for the enterprise software industry as a whole.

In the next three years, the SAP ECC migration wave forces the substrate question into every executive boardroom that has been deferring it. The AI failure pattern that has been visible in pilots becomes visible in production deployments. The cost of not having the substrate stops being theoretical and becomes a line item in earnings reports. The companies that are ready will pull ahead. The companies that are not will absorb the cost in ways that show up in operating margin, customer satisfaction, and the speed at which they can respond to whatever the next wave of competition brings.

In the next ten years, the regulatory environment around data portability, AI accountability, and platform extraction will mature. The EU is leading. The US is following at state level. The lock-in patterns that have made enterprise software a profitable extractive business for thirty years will become legally exposed in ways the industry has not had to plan for. Vendors who built their commercial position on extraction will face restructuring. Vendors who built their position on interoperability and discipline will be advantaged.

In the next twenty-five years, the question of whether humans can sustain off-Earth settlement at any scale will be tested. The substrate that we build now, for the operational systems that handle terrestrial commerce, is the same substrate that the off-Earth operational systems will inherit. The companies that build serious data discipline into their products in the next decade are the companies whose work will be the foundation of those off-world systems. The companies that do not will be replaced, in the long arc, by ones that do.

This is not a prediction with a single timeline. It is a structural observation. The pattern operates at the quarter-by-quarter scale, at the migration-cycle scale, at the regulatory-cycle scale, and at the civilizational scale, all at once. The same dynamic is visible at every scale because the same underlying truth is operating at every scale: substrate determines compounding, and compounding determines outcomes over time.

The Moon is not a fanciful destination in this argument. It is the test case that cannot be hand-waved. Every other test case admits some buffer, some excuse, some alternative explanation. The Moon does not. If your data architecture would not survive there, it is not surviving here either. It is just being subsidized by the buffers that earthbound enterprise still affords. The buffers are running out. The auditor is on the way.

13. What We Take

The phrase that gives this essay its title is meant to be read literally and seriously. What we take to the Moon is not the rockets, not the habitats, not the rovers. Those will be built by people who specialize in them. What we take is the operational discipline that determines whether the systems running underneath those vehicles can be trusted by the people whose lives depend on them.

That discipline is not built somewhere else. It is built here, in the systems we operate now, in the architectural choices we are making this quarter, in the standards we either enforce or do not. The companies that build the discipline now will be the ones whose work the next generation of human operations rests on. The companies that defer the discipline will produce a substrate that the next generation cannot inherit, because the substrate will fail in environments where its defects are not survivable.

This is, in the most literal sense, a generational responsibility. We are the generation that built the data infrastructure that the world is operating on. We are the generation that has begun to recognize the cost of having built it badly. We are the generation that still has time to build it correctly, in the products and the practices that we ship between now and the moment when the consequences of the choice begin to matter at scales that are no longer terrestrial.

The Moon is a useful image because it is concrete enough to motivate the discipline. The discipline itself, however, is not about the Moon. It is about every system we build between now and then. Each one of those systems is either a step toward a substrate that can be inherited, or a step toward more of the dysfunction that we have already produced. The choice is being made now, by the people writing the specifications for the next migration, by the executives signing off on the next ERP, by the engineers designing the next data model. It is being made implicitly in most cases. The argument of this essay is that it should be made explicitly, because the consequences are larger than they appear when made implicitly.

If the executive reading this finishes the essay and changes one decision in the next quarter as a result — declines one custom field, demands one substrate audit, reframes one AI roadmap to budget the data work as the precondition rather than the afterthought — that change compounds. Over a decade, across an organization, the compounded effect of those small decisions is the difference between a company that has built a substrate and one that has not. Across an industry, the compounded effect is the difference between a discipline that can be inherited by the systems running off-world and one that cannot.

The work is small at the scale of any individual decision. It is civilizational at the scale of the cumulative consequence. The companies and the executives who recognize that get to be the ones who built what came next. The ones who do not get to be the ones whose work was replaced by the ones who did.

What we take to the Moon is the discipline we are building today, in the systems we are operating today, in the choices we are making today. There is no other source for it. It does not get built somewhere else and shipped at the moment of departure. It either exists, here, in the work we are doing now, or it does not exist at all.

That is what the title means. That is the stake. That is the reason this essay is longer than the situation should require, and the reason the argument keeps coming back to the substrate even when the temptation is to talk about anything else. The substrate is the thing. Everything else is a consequence of it.

If you found this useful, the companion essay “The Cost of Convenience” covers the broader argument about how the enterprise software industry got into this state and what it would take to get out. Subscribe for the rest of the sequence.

About the author. Chris Gaither spent fifteen years in manufacturing operations before founding Mimir Labs, where he and his team build the tools described in this essay’s prescriptive section: a deterministic, vendor-neutral governance platform (Ratatosk) for the semantic audit, a migration engine (Ragnarok) for when the audit results justify movement, a canonical reference model (Mimisbrunnr) as the neutral vocabulary everything maps to, and an integration layer (Bifrost) for ongoing interoperability. Reach him at [email protected] or learn more at mimirlabs.net.