Manu's Vault

Domain-Adaptation-for-Automation

4 min readStatus:Seedling

Core Idea

Domains can be redesigned to reduce the Essential Complexity of software serving them — analogous to how software is redesigned to be testable. The reduction of complexity happens at the domain level, not the software level.

What Is Domain Adaptation for Automation?

When making software testable, you don’t just add tests to existing code — you redesign the code itself: dependency injection, separation of concerns, explicit interfaces, deterministic functions. The software adapts to make verification tractable.

The same principle applies to automation. Domain processes and solutions can be redesigned to be more software-friendly — not just software built to fit an existing domain. When this happens, the Essential Complexity of the translation between domain and software is reduced at its source.

This is a strategic, not technical, capability. Organizations that invest in making their domain processes more explicit, computable, and machine-friendly — not just in building better software — will extract substantially more value from AI and automation.

Historical Examples

  • Manufacturing: Assembly lines weren’t automated by adding robots to existing human workflows. The production line itself was redesigned around what machines could reliably do — standardized parts, explicit sequencing, measurable tolerances. Henry Ford’s moving assembly line is domain adaptation for automation.
  • Healthcare: EHR adoption didn’t just digitize paper records. Clinical workflows were restructured to be computable — standardized diagnostic codes (ICD), defined consent flows, explicit medication reconciliation steps. The clinical process adapted to make software integration tractable.
  • Finance: Algorithmic trading didn’t just automate existing trading practices. Financial instruments were redesigned to be more computationally tractable — standardized contracts, defined settlement rules, explicit pricing models.
  • Urban infrastructure: Smart city software doesn’t just monitor existing infrastructure. Buildings and systems are designed from the start with sensor integration, data schemas, and API contracts in mind.

In each case, the domain moved toward the software — not only the software toward the domain.

The Critical Constraint

Domain adaptation requires domain expertise to decide which adaptations preserve customer value and which degrade the solution.

  • You cannot make a clinical workflow more computable by removing the judgment steps
  • You must identify which steps can be made explicit without compromising care quality
  • This judgment is itself Essential Complexity that only domain experts can resolve

This is why domain adaptation cannot be delegated entirely to software engineers or AI. It is a collaborative redesign effort requiring deep domain knowledge.

Architectural and Business Implications

  • Architects advising organizations on AI or automation initiatives should ask: “Is the domain ready to be automated?” before “What software should we build?”
  • The bottleneck for automation ROI is often domain design, not software capability
  • AI and low-code tools lower the cost of building software — but cannot reduce Accidental Complexity introduced by domains that were never designed to be computable
  • Domain adaptation is a long-term organizational investment, not a one-time project

Sources

  • Original synthesis based on the analogy between testability in software and domain adaptation for automation. Extends Brooks’ essential complexity framework applied to domain design.
  • Ford, Henry and Samuel Crowther (1922). My Life and Work. Doubleday, Page & Company.
    • Moving assembly line as a historical example of domain adaptation for automation; standardization of parts and process as prerequisite for mechanization
  • Shortliffe, Edward H. and James J. Cimino (eds.) (2006). Biomedical Informatics: Computer Applications in Health Care and Biomedicine. 3rd ed. Springer. ISBN: 978-0-387-28986-1.
    • Clinical workflow restructuring for EHR integration as domain adaptation; role of standardized codes (ICD, SNOMED) in making clinical processes computable
  • Evans, Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN: 978-0-321-12521-7.
    • Ubiquitous language as a mechanism for domain-software co-adaptation; bounded contexts as a way to manage translation complexity at domain boundaries

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks