Where This Comes From
The method emerged from observing the same failure pattern across many organizations.
Twenty Years of Patterns
Over twenty years of work in enterprise technology, across financial services, utilities, healthcare, defense, and other sectors, I observed a consistent pattern: automation projects failed for reasons that were visible before implementation began.
The failures were not random. They clustered around a specific structural characteristic: the presence of undocumented decision-making that the automation was expected to handle.
After documenting enough of these cases, I started mapping them to existing theory. It turned out that Shannon, Turing, and Wiener had already established the relevant principles decades ago. What I did was apply their frameworks to business process analysis.
81 Cases, One Pattern
The method has been tested against 81 historical automation cases spanning from 1913 to 2024. These include well-documented failures like Phoenix, Knight Capital, and Hertz/Accenture, as well as dozens of less prominent cases across 20 industries.
The pattern holds in every case. Projects that attempted to automate tacit knowledge failed. Projects that automated explicit knowledge succeeded.
This is not a claim that the method is perfect. It is a claim that the pattern has held across every case examined so far. If someone finds a case that breaks the pattern, the framework would need revision. No one has found such a case yet.
Built on Public Science
The underlying principles are not proprietary. Shannon's information theory is public. Turing's work on computability is public. Wiener's cybernetics is public. What we provide is the application of these principles to the specific question of automation outcomes.
This means the analysis is auditable. We are not asking you to trust a black box. We are asking you to examine whether the explicit/tacit distinction applies to your situation, using a framework whose mathematical foundations you can verify independently.
Domain Knowledge
The framework draws from work across multiple industries.
Financial services
Trading systems, regulatory compliance, risk management
Utilities
Grid management, billing systems, field operations
Healthcare
Clinical workflows, EHR integration, claims processing
Defense
Logistics systems, procurement, command and control
Technology
Platform migrations, infrastructure automation, DevOps
Manufacturing
Production systems, quality control, supply chain
Each domain contributed cases that strengthened the diagnostic framework by testing it against different types of work.
Why "Eidos"
Eidos is a Greek word meaning form or structure. It refers to the underlying shape that makes something what it is.
Structural assessment is about seeing the form of a process: what is explicit, what is tacit, where the decisions actually live. The name reflects the work.
Assessment Before Commitment
Before your next automation investment, understand whether the conditions for success exist.