Protocol-Governed Computing: Business Software That Runs on a Domain-Neutral Substrate

Abstract

The problem Why does a new business domain still require changes to the system that runs it, when other forms of software have long been admitted without changing their substrate? Software has solved this problem before. A new application runs on an operating system nobody rebuilt for it. New bytecode runs on a virtual machine that has never heard of it. A new query runs on a database engine that was compiled years earlier. In each case the substrate stays fixed. The new work arrives as an artifact the substrate knows how to consume, and the substrate consumes it. A business domain here is a bounded area of business behavior with its own vocabulary, operations, rules and state — order handling for an e-commerce seller, loan origination for a lender, catalog management for a library. It is governed when those rules and operations are declared rather than left implicit in the code that carries them. Governed business domains are commonly implemented through a combination of domain code, configuration, deployment material and runtime services. Admitting a new domain can therefore require changing the executable composition that already carries other domains. The domain does not arrive as an artifact. It arrives as a change to the system that runs it. This paper asks whether that coupling can be removed instead. Can a governed business domain arrive as an executable artifact that a shared substrate admits and executes without acquiring behavior specific to that domain? The question is narrower than general software modularity: it concerns the boundary between a governed domain artifact and the executable substrate that consumes it. The paper does not propose another business-process framework. It examines how far two things can hold together for governed business domains: admitting a new domain without modifying the substrate, and keeping behavior particular to that domain out of the substrate. Section 1.2 states both as named conditions, Section 5 gives the mechanism, and Section 6 reports which of them the realization meets. The contribution is architectural and evidentiary — a defined property, a realization of that property within a stated scope, and measurements that test the realization’s domain neutrality.