What Quantum Computing and Intent-Native Computing Share, and Where They Part
A software product starts inside the paradigm it works in and leverages what already exists. A new class of computing cannot be assembled from the old one, so the substrate has to exist before any product can run on it. This paper proposes three tests for telling a class from a product, uses quantum computing as the reference case, and argues that Essence® meets the same tests on a different axis and to a different standard of proof.
Most companies that build something new in software work inside the existing paradigm. They inherit compilers, frameworks, libraries, cloud services and model interfaces, and the path from idea to product is short because so much already exists to build on. There are real advantages to building on a paradigm. There is also an inheritance tax: the primitive comes with the components. Across the first two eras described in Paper 20, that primitive is code, written by people in Era 1 and generated by models in Era 2, so governance is applied around execution and not at it. The tax cannot be avoided from inside the paradigm. It can only be avoided by changing the primitive, which means leaving the paradigm. A new class of computing is different in kind: it cannot be assembled from the previous paradigm's components. Section 03 sets out three tests for telling a class from a product, and Section 08 states what this paper does not claim.
A question follows any company that spends a long time building something new: why not ship a narrower product sooner and let the larger platform follow? For a software product, the question is fair. A software product starts inside an existing paradigm. A team can assemble a working product from existing compilers, frameworks, libraries, cloud services and model interfaces, and the time to a first product reflects how much already exists to build on.
The question assumes the same is true of whatever is being built. This paper examines when that assumption fails. It is not a defense of any schedule. It is an argument about what kind of thing is being built, because the answer determines what a reasonable first use case looks like, and what it costs to define the work by one.
Leaving a paradigm is expensive, so the case for leaving has to be made. Building on one has real advantages. Compilers, frameworks, libraries, cloud services and model interfaces already exist, and the path from idea to product is short. The case for leaving rests on what arrives with that inheritance.
Paper 20 describes three eras by their computational primitive. In Era 1 the primitive is human-written code, and intent has to become syntax before anything can happen. Era 2 made code generation faster and cheaper and removed the developer as the authoring bottleneck. Its output is still code, so, in Paper 20's account, the governance, trust and attribution problems of the Coding Era are inherited, and in some ways amplified, because code is now generated faster than people can review it. Era 3 replaces the primitive with declared intent.
| Era 1: Coding | Era 2: AI Code | Era 3: Wantware | |
|---|---|---|---|
| Primitive | Human-written code | AI-generated code | Declared intent, resolved through Meaning Coordinates |
| Problem it addresses | Giving machines instructions | Interpreting natural language well enough to generate useful proposals | Does not solve a problem inside Era 2. Replaces the premise Era 2 was built on |
| Where governance sits | Applied around the code, external to execution | Guardrails and monitoring added to AI outputs, detection after the fact | Evaluated before execution, at the substrate |
This paper uses the term inheritance tax for what the first two eras pass on along with their tools. A product built inside the paradigm inherits the primitive as well as the components. When the primitive is code, governance is applied around execution and not at it, whether a person or a model wrote the code. The builder does not choose this cost and cannot negotiate it down, because it comes from the premise and not from any one component. The term is a framing proposed here. It is not a measured quantity, and this paper does not put a number on it.
Era 2's response to its own limits has been to add harnesses, context pipelines, agentic orchestration and guardrails. Paper 20 judges that “scaffolding around a paradigm is not a new paradigm. It is the old paradigm with more moving parts.” That is the axis test, introduced in Section 03, applied to the paradigm itself: improvement moves a system along axes the paradigm already has and does not add one. By this paper's argument, effort inside the paradigm can mitigate the tax but cannot remove it. Removing it means changing the primitive, which is what leaving means.
Leaving has a price, and the price is the other half of the argument. The builder gives up the inherited leverage for what is executed, and Section 07 returns to what that means for order. Leaving the primitive is not leaving the machine. Paper 20 states that Era 3 does not begin by discarding Era 1 or Era 2, and that code remains. Essence® deploys on existing hardware and operating systems, as Section 05 sets out.
This paper proposes three tests. They are offered as a working framework, open to challenge, and not as an established one.
None of the three tests measures importance or quality. A product can beat a class on every commercial measure. The tests sort by structure, because structure determines how the thing has to be built, and in what order.
Quantum computing is the cleanest case because the three tests give unambiguous answers. A quantum computer cannot be assembled from better classical components. It needs a different physical substrate and a different model of computation. The unit of computation is a quantum state manipulated by quantum operations, not a classical bit manipulated by logic gates.
The axis is computability. In 1994, Peter Shor showed that a quantum computer could factor large integers in polynomial time, a problem believed, though not proven, to require superpolynomial time on any classical machine. Making classical hardware faster does not change that believed scaling. A different model of computation does.
Because quantum computing fails the component test in the useful direction, no quantum computer can be delivered by assembling existing classical parts. The machine has to be built before anything can run on it. The result is also narrow: it changes what is tractable for a specific class of problems. Paper 76 credits it on exactly those terms, and this paper does the same.
Quantum computing is also a caution. A class claim says nothing about timing or commercial return, and this paper draws no parallel to quantum computing on either.
Essence® departs from code-based computing in the same structural way. Its unit of execution is declared intent, resolved through Meaning Coordinates, and not code. The existing stack of compilers, frameworks and libraries assumes that what gets executed is code, so it cannot simply be assembled into a system whose unit of execution is something else. The comparison holds at the level of structure. It does not hold at the level of scope or proof.
| Quantum computing | Essence® | |
|---|---|---|
| Axis of departure | Computability: what is tractable | Governability: whether an action can be checked against a fixed reference before it runs |
| Scope | A narrow class of problems | General-purpose computing |
| Unit of execution | Quantum state and quantum operations, not bits and logic gates | Declared intent resolved through Meaning Coordinates, not code |
| Assembled from the prior paradigm's components? | No. Different substrate and model of computation | No, for what is executed. It deploys on existing hardware and operating systems |
| Basis of the claim | Complexity theory, conditional on a conjecture about classical hardness | Architectural, with measurements reported in the series under their stated conditions. No equivalent proof |
| What a skeptic should check | Whether sufficiently large fault-tolerant machines can be built | Whether determination at execution holds beyond the domains shown, and what remains as code |
The fourth row needs the most care, because it is where the comparison is easiest to overstate. Essence deploys on the machines people already have, on Linux, Apple platforms, Windows and others, as the Common Substrate series documents. Where something runs is a different question from what it is built from. The component test asks the second question.
The Common Substrate series answers it with one doctrine, Compiled ≠ Resolved. A compiled binary is a prediction about a machine that does not exist yet. Resolution is a determination about the machine that is actually there. Some units of work in Essence still carry code inside them, which the series calls residue and does not claim away. The Bare Machine, which describes Essence with no host operating system, is described in the series as a design that is not yet booting.
Evaluation binaries of the Essence pilot runtime are available at adaptwithchameleon.com for Ubuntu 24.04 and other validated Linux distributions, for evaluation use only. They allow a reader to test the reported execution results under stated conditions. They do not test claims about platforms or domains the binaries do not cover, and they are not a test of the architectural claim for general-purpose computing. Production deployment is underway with AWS and nClouds, with funding from AWS.
Four earlier pieces of work bear on the three tests. None of them was written to make this argument, which is the reason to cite them.
Paper 20 addresses the primitive test. It describes three eras by their primitive: human-written code, AI-generated code, and declared intent. It observes that Era 2 added scaffolding around its limits, and that “scaffolding around a paradigm is not a new paradigm.” It also states that an intent-native computing architecture “is not a product category,” but a set of requirements that follow from one decision.
The Common Substrate series addresses the component test. Its fourteen papers take one mechanism, a commitment made before the machine is known versus a resolution made at execution, across fourteen substrates, and each paper carries a section stating what it does not claim.
Paper 31 addresses the axis test from the market side. Its Section 05 argues that memory, guardrails and context management are each a different thing solving a different problem, not refinements of an intent layer. Each apparent parallel is an attempt to reach a new axis by improving the old paradigm.
Paper 72 bears on adoption, which the three tests do not address. A class has no installed base, and a buyer can reasonably ask why anyone should adopt what nobody else has. Paper 72 answers in two parts. The first comes from negligence law. In The T.J. Hooper (1932), Judge Learned Hand held that industry custom is evidence of due care and never the ceiling on it, and the reasonable-alternative-design standard in the Restatement (Third) of Torts asks whether a feasible alternative was available, not whether it was common. Availability, in that paper's account, requires a working design shown to function, not a finished product at scale. The second part comes from demand. Paper 72 cites four independent 2026 surveys that place the leading barrier to scaling AI past pilots at the absence of a way to trust what a system will and will not do, not at capability. It labels the legal argument an emerging exposure argument, not a settled one: no court has applied either doctrine to an AI determination layer, and, when that paper was written, general production deployment was still ahead. Production deployment with AWS and nClouds, with funding from AWS, is now underway.
Paper 76 names the axis itself. Paper 28 describes the entrant that serves a market from a clean architecture. This paper concerns what has to exist before that clean architecture can be offered.
The first consequence is order. If a class cannot be assembled from the prior paradigm's components, the substrate has to exist before a product can run on it. That changes what a reasonable timeline looks like, and it changes what the early evidence should be: measurements of the substrate under stated conditions, not a count of customers for one application. Paper 20 reports 20–114x acceleration and up to 99.7% energy reduction, attributed there to validation by AWS and the Rowan University Digital Engineering Hub. The conditions are stated in the series and should be read there before the figures are reused.
The second consequence concerns the narrow use case. Any use case can be built once the substrate exists, and the series reports several. The risk is not that a use case gets built. The risk is that a company gets defined by one. Use cases are how the old paradigm divides the world, by application. A definition by one application is therefore a definition inside the old paradigm, which returns the work to the paradigm it departs from.
Being defined by a use case is different from entering through one. A company can sequence its first deployments without letting the first become its boundary. The difference is whether a use case is chosen as an entry point to a substrate or accepted as the limit of one. An investor reasonably asks for that sequencing, and this paper does not supply it. It is an argument about structure, not a go-to-market plan.
The third consequence is how to evaluate it. The right questions are which of the three tests it meets, on which axis, to what standard of proof, and where it fails. A list of use cases it can serve answers a different question.
The fourth consequence concerns adoption. A class starts with no installed base, so adoption cannot be argued from what others already do. Paper 72 argues that the legal standard is availability and not prevalence, and that the barrier buyers report is trust. Read with Section 02, trust is where the inheritance tax appears on the buyer's side: governance applied around execution leaves the buyer unable to say what the system will not do. That link is this paper's inference. The surveys Paper 72 cites do not make it.
The fifth consequence concerns accountability, and it is the one that matters beyond the industry. When governance is applied around code, a harm has to occur and be traced before anyone can act on it. When what is permitted is determined before an action runs, the question of what was authorized exists before the outcome does. That is the practical difference the governability axis names.
It does not claim a proof comparable to Shor's. Quantum computing's claim rests on complexity theory. Essence's claim is architectural, and it should be held to the standard that implies.
It does not claim that existing software offers no leverage. Essence deploys on existing hardware and operating systems, as the Common Substrate series documents. The claim concerns what is executed, not where it runs.
It does not claim that every part of Essence is free of code. Some units of work still carry code, and the Bare Machine is a design that is not yet booting.
It does not claim that the three tests are an established framework. They are proposed here, and a reader who rejects them should say which one and why.
It does not claim that adoption is settled. Paper 72's legal argument is an emerging exposure argument with no decided case, causation in AI harm cases is harder to prove than in a hardware case, and production deployment, although now underway with AWS and nClouds, has not yet produced a field record across the relevant market. Availability of a validated design is not the same as a field record.
It does not ask for regulatory, procurement or funding treatment on the basis of class membership. The three tests describe structure. They confer no entitlement.
It does not claim that a class is better than a product, or that class membership predicts commercial success. And it does not address funding, schedules or any company's particular history. It addresses the structure of the thing being built and why, by this paper's argument, it addresses problems that improving other paradigms does not reach.
A software product is built on the paradigm it belongs to. It inherits that paradigm's components and its primitive. For a product, the inheritance is an advantage, because so much already exists to build on. It is also a tax. Across the eras Paper 20 describes, the primitive is code, so governance is applied around execution and not at it. Improvement inside the paradigm moves a system along axes the paradigm already has. By this paper's argument, it does not add one.
The paper proposed three tests for telling a class from a product. Quantum computing meets all three on the axis of computability, for a narrow class of problems, on grounds taken from complexity theory. Essence® is argued to meet them on the axis of governability, for general-purpose computing, on an architectural claim that carries no equivalent proof. Some units of work in Essence still carry code, and the Bare Machine is a design that is not yet booting. Evaluation binaries of the pilot runtime are available at adaptwithchameleon.com for readers who want to test the reported results under stated conditions. Production deployment is underway with AWS and nClouds, with funding from AWS.
Five consequences follow. The substrate has to exist before a product can run on it. A company can enter through a use case without being defined by it. The right evaluation asks which tests are met, on which axis, to what standard of proof, and where the claim fails. Adoption rests on availability and trust, not on an installed base, as Paper 72 argues. And accountability moves earlier, to the question of what was authorized before the outcome exists.
The paper does not claim that a class is better than a product. It claims that the two differ in structure, and that the difference changes how the thing has to be built, how it should be judged, and what it can reach. The three tests are a proposal. A reader who rejects one should say which, and why.