Enterprise software specialized the application. Every capability a complex-product organisation needs — requirements, risk, verification, change, quality, compliance — arrived as its own product, with its own object model, its own permissions and its own idea of the truth. The result is not a toolchain. It is a set of partial representations of the same programme that no one can reconcile without human effort.
M Theory inverts that. The environment is general purpose — Sheet, Doc, Canvas, Deck, Plan — and the specialization lives underneath, in the objects, relationships, governance and evidence that every surface shares. One requirement is one object; the spreadsheet, the document and the diagram are views of it.
This page sets out the argument: what the systems-engineering literature reports about document-centric work, what practitioners describe, what the accident and assurance record shows about evidence going stale, how much is already spent holding the fragments together, and what changes if the capability rather than the application is the unit of specialization.
Fragmentation is not a tooling preference; it is a documented condition of complex-product development. The findings below are the ones we build against.
INCOSE's Systems Engineering Vision 2035 describes the discipline as still largely document-based and sets model-based practice, digital engineering environments and continuous, evidence-linked assurance as the target state rather than the current one.
INCOSESystems Engineering Vision 2035· 2021US Department of Defense digital-engineering strategy frames the objective as an authoritative source of truth connecting models and data across the lifecycle — an explicit acknowledgement that the data exists but is not connected across the tools that produce it.
U.S. Department of DefenseDigital Engineering Strategy· 2018The SERC benchmarking study run with INCOSE and the NDIA Systems Engineering Division assessed organisations against the INCOSE Model-Based Enterprise Capability Matrix and found most sitting at low-to-moderate maturity, with document artifacts and manual traceability still dominant even where modelling tools are in place.
SERC / INCOSE / NDIABenchmarking the Benefits and Current Maturity of MBSE across the Enterprise· 2020A NASA Johnson Space Center study measured relative error-correction cost across life-cycle phases using three independent costing methods and found errors found late cost many times more than the same error caught at requirements or design. The NIST-commissioned RTI study reaches the same conclusion economy-wide and put the annual cost of inadequate software testing infrastructure at $59.5 billion.
The popular 1:10:100 multiplier is disputed: investigative and peer-reviewed re-examinations have found the relationship far weaker and more project-dependent than the heuristic implies. We cite the direction of the effect, which is well evidenced, not a fixed ratio.
NASA Johnson Space CenterError Cost Escalation Through the Project Life Cycle (NTRS 20100036670)· 2010Menzies, Nichols, Shull and Layman revisited cost-to-fix across the lifecycle on real project data and found the delayed-issue effect does not hold uniformly. We include this because a thesis that only cites what flatters it is not a thesis.
Empirical Software EngineeringAre Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects· 2016The NIST-commissioned RTI study estimated $59.5 billion in annual cost to the US economy from inadequate software testing infrastructure, with about $22.2 billion of that judged recoverable through earlier detection and better infrastructure.
NIST / RTIThe Economic Impacts of Inadequate Infrastructure for Software Testing· 2002NASA's software assurance and safety standard requires assurance activities, records and safety evidence to be maintained across the lifecycle as the software and its requirements change — a continuity obligation, not a one-time deliverable.
NASANASA-STD-8739.8, Software Assurance and Software Safety Standard· 2022What the condition looks like from inside a programme, in the words teams use when they describe their week.
The system of record for cross-tool truth is an export: a requirements dump joined by hand to a test log, reconciled in a review, and stale the moment it is circulated.
Trace matrices are assembled for an audit rather than read off the work. The effort scales with the audit calendar, not with the engineering.
A severity changes in one tool; whether the verification that depended on it is still valid is a question answered by whoever remembers.
ASPICE, ISO 26262 or DO-178C work runs alongside development as its own effort, staffed separately, delivering documents that mirror engineering that has already moved on.
Licences, schemas and permission models accumulate faster than they are retired, and each new one adds another partial view of the same object.
An assistant is bounded by the context it can reach. Twenty disconnected systems means twenty schemas and no single grounded representation to reason over.
The most rigorous assurance organisation on the planet has repeatedly documented the same failure mode: the evidence and the engineering drift apart, and the drift is invisible until something breaks.
“organizational barriers that prevented effective communication of critical safety information and stifled professional differences of opinion”
“The Board strongly believes that if these persistent, systemic flaws are not resolved, the scene is set for another accident.”
Read as an information-architecture finding rather than a cultural one, the pattern is consistent: safety-critical knowledge existed inside the organisation, in analyses and in individual judgement, but it was not connected to the decisions that depended on it, and nothing in the system made the disconnection visible. Every assurance regime since — NASA's own software assurance standard, ISO 26262, DO-178C, ASPICE — encodes the same requirement, that evidence must remain demonstrably attached to the thing it certifies. What none of them supply is a substrate where that attachment is maintained automatically instead of reconstructed by people.
Organisations already spend heavily to hold this together. The spend buys more specialized applications, which is what produced the fragmentation in the first place.
We deliberately do not sum these into a single headline TAM. The categories overlap, each analyst bounds them differently, and adding them would imply a precision the underlying data does not support. The honest framing is that the addressable spend is the tooling an organisation buys to compensate for the absence of a shared substrate, plus the engineering time spent reconciling those tools — and the second number is usually larger than the first, and never appears on a licence invoice. We have also left out the widely repeated claim that engineers spend a fixed percentage of their week searching for information: it is quoted everywhere and traceable to nowhere.
The answer to document-centric work is not eliminating documents. It is separating the document interface from the underlying work model, so structure, traceability and approval are properties of the work rather than deliverables produced after it.
People work in the surfaces they already know: a sheet, a document, a diagram, a deck, a plan.
What they create are addressable objects — a requirement, a hazard, a test, a decision — referenced with # from anywhere.
Relationships, revisions, approvals and impact are captured as the work happens, not assembled afterwards.
Compliance becomes a view over the graph. When something upstream changes, everything downstream of it knows.
Complexity does not disappear; it moves. The irreducible complexity of requirements, safety, compliance and configuration belongs in the platform rather than being imposed on every user through a different specialized application. The system carries more. The person carries less.