Why Wantware Is Not Software
A common way to place a new kind of computing is by elimination: if it is not hardware, it must be software. That is a category error, and it skips an earlier question. The goal comes before the mode. Code was never the goal of either proprietary or open source. Governance was, and code was the medium.
With the goal fixed, modes sort by what the person supplies. Hardware takes a physical configuration. Software takes procedures. Wantware takes intent. This paper sets out the argument, answers the objection that wantware still runs on the same chips, and states what it does not claim.
The vocabulary most people have for computing has two words, hardware and software, so a system that is not one is assumed to be the other. This paper argues that the inference is a false dichotomy, and that it answers the second question before the first. The first is the goal. A mode is a means, and it is judged by how well it serves the goal. The history of software licensing shows the order: in proprietary and open source alike, code was the medium, and the goal was governance, meaning control over what technology is permitted to do, held by the owner in one case and shared in the other. Two categories are complements only if they exhaust the space, and the space has a third member. Transport offers the cleaner comparison. Cars, boats, aircraft and rockets all move things, and no one files an aircraft under cars because it is not a boat. Each is named by the medium it operates in, and the medium sets its physics, its skills, its regulation and its failure modes.
The computing equivalent is the unit of authorship: what the person supplies. In hardware it is a physical configuration. In software it is a procedure, written by a person in Era 1 or generated by a model in Era 2. In wantware it is declared intent, resolved through Meaning Coordinates and determined before anything executes. The objection that wantware still runs on the same processors proves nothing, because software also runs on hardware and is not hardware. This paper proposes four questions for sorting modes, beginning with the goal, applies them to Essence®, and states plainly where the argument is a proposal and not a proof.
The sentence takes a few forms. If it is not hardware, it is software. If it runs on a computer, it is a software company. If it has no physical product, it is software by definition. Each form reaches the same conclusion by the same route: subtract hardware and see what remains.
The sentence is usually offered in good faith, and often with a concession attached. The speaker adds that the company behaves very differently from a traditional software company, and that this is the difficulty in getting people to understand something they have never seen or worked with before. The concession is the important part. It reports a difference in behavior, and it is made inside a label that has no room for it.
This paper takes the concession seriously. If the behavior differs, the question is what kind of difference it is, and whether the existing vocabulary can hold it.
Before asking which mode a thing belongs to, ask what it is for. A mode is a means. The goal is what the means serve, and it comes first in order because it is what a mode is judged against. A question about mode that skips the goal can be answered perfectly and still miss the point.
The history of software licensing shows the order. Proprietary software concentrates control with the owner: the vendor decides what the technology does, and the license, the compiled binary and the support contract are the infrastructure for that decision. Open source distributes it. The Fix the Substrate page argues that open source succeeded because it distributed trust, not code. When anyone can read the source, verify the behavior, fork the direction and hold the project accountable, that is governance. The license, the community process and the public repository were infrastructure for deciding who controls what technology does. In that account, code was the medium and not the message.
Read that way, code was never the goal. It was the best available medium for a goal that was always something else: shared, checkable control over what technology is permitted to do. Paper 86 states the same goal as a question of authority: who or what may act, within what scope, under whose rules, with what record. When the medium is mistaken for the goal, attention goes to the artifact and away from what the artifact was for. A project judged as a code repository is judged by its commits. A project judged by its goal is judged by whether control was actually distributed.
The same order applies to modes. A mode earns its place by how well it serves the goal, not by its own properties. On the account in the Fix the Substrate page, software was the right mode while code could be read at roughly the speed it ran, and that stops holding when AI proposes and executes faster than human review can track, because the form of transparency remains and its function does not. That is the page's argument. This paper adopts it as a premise and does not prove it here.
The order also explains why the mislabel costs more than tidiness. Calling wantware software defines it by its medium, which treats the code as the point, as arguments about proprietary versus open source often do. The goal is the part that gets lost: whether anything decides what may happen before it happens.
Subtraction works only when the categories are complements. If there were exactly two kinds of thing, then not being one would make something the other. Whether that holds is an empirical question about the space, and it is not settled by the grammar of the sentence.
The same inference in another domain shows the flaw. Not a car, therefore a boat. Not a boat, therefore an aircraft. Each step is valid only if the list is complete, and the list is never complete once a new member exists. A rocket is not a car, not a boat and not an aircraft, and it is not any of them by default. It operates in a medium none of the others do.
A two-word vocabulary was adequate while the space had two modes. It stops being adequate when a third arrives, and the failure shows as a mislabel, not as an error message. The new thing is assigned to the nearest existing bucket, and the label then carries every expectation of that bucket along with it.
Transport modes are defined by medium: land, water, air, space. The medium is not a detail. It fixes the physics the vehicle has to respect, the skills needed to operate it, the rules that govern it and the way it fails. A car and a motorboat can both be driven by an internal combustion engine. That shared component does not make one a version of the other. The mode is set by where and how the thing moves, and not by what it is made of.
Computing has an equivalent, and it is not the substrate. It is the unit of authorship: what the person supplies, and what the system then does with it. With the goal from Section 02 fixed, modes can be sorted against it.
The transport comparison is imperfect at one point, and the paper relies on that point. In transport, medium and mode coincide. In computing they separate: the substrate is one thing and the unit of authorship is another. This paper sorts by the second.
| Hardware | Software | Wantware | |
|---|---|---|---|
| The person supplies | A physical configuration | Procedures or formal specifications in a language the machine class accepts, written by a person (Era 1) or generated by a model (Era 2) | Declared intent, resolved through Meaning Coordinates (Era 3) |
| The system | Does what it was built to do | Executes the steps it was given | Determines what is permitted, then runs what is approved |
| Where governance sits | Fixed at design and manufacture | Applied around the code, while it runs or after it has run | Evaluated before execution, at the substrate |
| Typical failure | A fault in the build | A defect in the procedure | An intent stated or resolved wrongly, which is reproducibly wrong and therefore findable |
| How outcomes are settled | Fixed by the build | Determinism (Era 1): the same code and input are meant to give the same result. Probabilism (Era 2): a model's output can vary between runs | Adaptive determinism (Era 3): the same intent resolves to the same governed result, while the instructions that realize it adapt to the machine |
The software column spans two eras in the account given in Paper 20. In Era 1 the procedures are written by people. In Era 2 they are generated by models. The primitive is code in both, which is why Paper 84 argues that governance in both is applied around execution and not at it. Wantware belongs to Era 3, where the primitive is declared intent.
The third row of the table is why the mode question has practical weight. A mode is a statement about where the decisions are made, and so about what can be asked of the system.
The last row of the table uses three terms for how outcomes are settled in each era. Determinism describes Era 1, where code is written to give the same result from the same input. Probabilism describes Era 2, where a model's output is drawn from a distribution and can differ between runs. Adaptive determinism is MindAptiv's name for Era 3: the result is fixed at the level of intent, and what adapts is the execution underneath, which is generated for the machine and conditions it finds. These terms describe the same three eras a second way. They are not a fourth mode and they do not replace the unit of authorship, which is still what sorts the modes.
Determinism and determination are different words and should not be read as one. Determinism is a property of outcomes: the same input gives the same result. Determination, as this series uses it, is a decision made before execution against a fixed reference, the case for which Paper 75 makes. A system can be deterministic and still ungoverned, because a fixed result says nothing about whether the action was permitted. Adaptive determinism names how the first property is kept in Era 3. Determination names where the decision sits.
The three eras answer one question differently: how does a wish become an action? Each diagram below runs from the same start to the same goal.
Programmers write exact instructions for one situation. It is predictable, but it is only one way to do the thing. When the situation changes, people rewrite it.
Generative AI picks among many likely routes. It is flexible, but it can arrive somewhere nobody intended, and the path is hard to explain afterward.
A Meaning Coordinate names where you want to end up, the way a map coordinate names a place. It can be reached from many starting points, and the result is deterministic. You choose what matters most, such as time, cost, energy or quality, without writing code.
Conceptual diagrams, adapted from the Visual Primer in MindAptiv's technical documentation. They illustrate design intent. That documentation states that only one part of the platform, a GPU optimization tool, runs publicly today.
The names follow the same convention. Hardware, software and firmware are industry terms and not brands, and MindAptiv has chosen not to register wantware as a mark for the same reason: it names a mode, and a mode belongs to everyone who works in it.
The expected objection is that wantware still runs on CPUs, still produces machine instructions and still depends on an operating system, so it is software underneath.
The objection classifies by implementation layer, and the same test would collapse the distinction it is trying to defend. Software runs on hardware. Every program executes on transistors. No one concludes that software is hardware, because the two are distinguished by what a person supplies and what the system does with it. If sharing a substrate merged modes, there would be one mode.
The comparison with transport applies again. Shared components do not merge a car and a motorboat. They share a part. What differs is the medium, and with it the skills, the rules and the failure modes.
There is a narrower and more honest version of the objection, and the series addresses it directly. Some units of work in Essence still carry code inside them, which the Common Substrate series calls residue and does not claim away. The claim in this paper concerns what the person supplies and what is determined before execution. It does not claim that nothing underneath is code.
Quantum computing tests the same independence. It is a different physical substrate, yet what the person supplies is still a formal specification in a vocabulary specific to the machine class: a circuit on gate-model machines (OpenQASM, compiled to each device as IBM's documentation describes) or an objective function on annealers (D-Wave SDK documentation). Changing the substrate did not change the mode. The goals also differ: quantum computing serves computability, and wantware serves governability, as Paper 84 sets out.
MindAptiv's hypothesis, untested, is that wantware could be used to instruct quantum computers, resolving signaled intent to the circuits that today's toolchains already compile to a device. Nothing in this paper demonstrates it. The PowerAptiv taxonomy's Engine category lists “transactional/quantum units” among its memory models, which names a place where such support could attach and is not evidence that it works.
This paper proposes four questions, asked in this order. They are a working framework offered for challenge, and not an established one. They are related to the three tests in Paper 84 but ask something different: Paper 84 asks whether a thing is a class or a product, and these ask what a thing is for and which mode it belongs to.
Applied to Essence: the goal is governance, as Papers 85 and 86 set out. The person supplies intent, which Synergy® maps to Meaning Coordinates. What may happen is determined against customer-configured scope before anything runs. And the software yardsticks transfer only in part. The answers are stated here so a reader can check them, and a reader who disagrees with one should say which and why.
None of the four questions measures quality or importance. Software is not a lesser mode. The questions sort by purpose and structure, because those decide what can reasonably be asked of the thing.
A label decides which questions get asked, and a medium-first label decides them before the goal is considered. A reader who files wantware under software will reach for software's yardsticks: feature lists, supported languages, integrations, benchmarks, release cadence. Most of those measure the procedures a person authored, and benchmarks measure how fast what runs, runs. They are reasonable questions to ask of software and they miss most of what distinguishes the third mode, because the distinguishing property is where the decision is made, which none of them measures.
The same pattern appears in the policy debate. Paper 85 sorted a set of public AI-safety responses by what they act on and found that nearly all of them extend controls software security already had: limit access, log activity, contain, evaluate. That is the software playbook applied to AI, and it is the natural result of treating the problem as a software problem. The mislabel and the inherited playbook are the same error at two scales.
There is also a plain communication cost. When a company is placed in a category with the wrong expectations, every conversation begins with a correction. A name for the mode shortens that, because it tells the listener at the start that the usual questions may not apply, and that a different set should be asked in their place.
The difference is visible at the interface. In Essence the person signals intent. Natural language is one way to do it, and the interface methods extend to any way of signaling intent: gestures, speech, brainwaves, behaviors and others. How signals other than language are resolved to coordinates is outside the scope of this paper. A model may propose how to satisfy that intent, and a proposal is not an action. Synergy® maps the proposal to Meaning Coordinates, a fixed set of primitives published as a closed set, using Grok Units authored by people. The same input resolves to the same coordinates. Whether the proposal is permitted is determined against scope the customer configures, before anything runs. What runs is approved, and a PowerAptiv synthesizes the machine instructions from the coordinates for the hardware actually present. In MindAptiv's account this is adaptive determinism: the result is fixed at the level of intent and coordinates, and the execution underneath adapts.
In that sequence the person never writes a procedure. That is the authorship question, answered. The decision about what may happen is made before execution and not around it. That is the decision-point question, answered. The case for a fixed reference, and for why a correlation cannot serve as one, is made in Paper 75. The separation between a model that proposes and a layer that determines is set out in Paper 85 and applied to open weight models in Paper 86.
None of this requires abandoning code. Paper 20 states that Era 3 does not begin by discarding Era 1 or Era 2, and Essence is designed to deploy on existing hardware and operating systems. The mode describes what the person supplies and what is determined first. It does not describe what exists underneath.
It does not claim that software is lesser, obsolete or about to be replaced. Software is a mode with its own strengths, and most of the world's computing is done in it.
It does not claim that the transport comparison is a proof. The comparison illustrates a structural point: that categories defined by medium are not complements of one another. The four questions in Section 06 carry the argument, and they are a proposal.
It does not claim that wantware can instruct quantum computers. That is a hypothesis, stated in Section 05, and it is untested.
It does not claim that the account of open source in the Fix the Substrate page is settled history. That account is the page's argument. This paper adopts it as a premise and says so where it does. The reading of proprietary software as control held by the owner is this paper's own framing and is offered the same way.
It does not claim that a mode label predicts performance, adoption or commercial success. A thing can belong to a new mode and fail, or belong to an old one and thrive.
It does not claim that no code exists underneath Essence. Some units of work carry code, and the Common Substrate series says so and does not claim it away.
It does not claim that every part of Essence described in this paper runs publicly today. MindAptiv's technical documentation states that only one part, a GPU optimization tool, runs publicly now, and that the rest returns with funded milestones. The sequence described above is the design.
It does not claim that adaptive determinism has been shown as a guarantee, or that it is an established technical term. It names MindAptiv's design claim that the same intent resolves to the same governed result while execution adapts to the machine. Whether results are identical across machines and conditions is a property to be tested, and this paper does not test it. A web search run on October 14, 2026 did not surface the phrase used as the name of a computing era among its results, and a web search cannot show that no such use exists.
It does not claim that the word wantware has no prior or competing use, or that the three-mode framing is original. A web search run on October 14, 2026 found no use of the word for a computing paradigm outside MindAptiv's own material, and found it elsewhere only in unrelated names, such as a UK retail company dissolved in 2021. It did find neighboring ideas that a reader will cite: Charles Simonyi's Intentional Programming at Microsoft Research in the mid-1990s, which expressed what software is meant to do as intentions; the intention pillar in The Three Pillars of Machine Programming (2018); Andrej Karpathy's Software 3.0, in which, as Latent Space summarizes it, English prompts are programs; and a 2026 PhilArchive paper on intent-conditioned computation. This paper's distinction from them is that it asks what the person supplies and where it is decided what may happen, and not only whether intent is the starting point. The search was a web search only. MindAptiv has chosen not to register wantware as a trademark, for the same reason software, hardware and firmware are not marks: they are industry terms, not brands.
It does not claim that the four questions are an established framework, and it does not ask for regulatory, procurement or funding treatment on the basis of mode. The questions describe structure. They confer no entitlement.
The goal comes before the mode. Neither proprietary nor open source software was ever about code. Both answer who controls what technology does, with control held by the owner in one and shared in the other, and code was the medium. In open source it was also what made shared scrutiny possible. A mode is a means, and it is judged by how well it serves the goal.
Not hardware does not mean software. The inference works only if there are two modes, and a third exists. A mode is named by the medium it operates in and by what the person supplies, and transport shows the pattern: no one calls a car an aircraft, even though both move people and may share parts.
Computing sorts the same way. Hardware takes a configuration. Software takes procedures, written by people or generated by models. Wantware takes intent and determines what may run before it runs. Running on the same processors does not merge them, because software runs on hardware and is not hardware.
The label decides which questions get asked, and so which answers get found. Software's questions measure authored procedures. The third mode needs others, asked in order: what is the system for, what does the person supply, and where is it decided what may happen. The four questions in this paper are a proposal. A reader who rejects one should say which, and why.