Question debt: what software acceleration changes

Global data centres used about 415 terawatt-hours of electricity in 2024. In the International Energy Agency's Base Case, that rises to approximately 945 TWh in 2030. The estimate is a scenario, not a certainty, but it is large enough to demand attention. Question debt is the compounding cost of questions abandoned because computing the answer is too slow or expensive. The electricity is visible. The questions that disappear before anyone submits a job are not. IEA, Energy and AI

Question debt begins before a machine does any work. It begins when a researcher removes an experiment from the agenda, when an operations team stops comparing routes, or when a founder decides that one more analysis would cost too much time. The bill does not arrive as a line item. It arrives later as uncertainty, approximation, missed alternatives, and decisions made with less evidence than the team wanted.

HexStellar is an agent-first computational platform. Cortex is its managed production surface for supported requests, while the Enterprise Low-Energy Runtime & Acceleration is the separately licensed customer-deployment path for compatible workloads under NDA. Software acceleration is the product category. Question debt is the cost that appears when a useful answer remains too expensive to request. These definitions describe public product boundaries and an editorial thesis; they do not disclose or speculate about the proprietary method.

Editorial visualization. Data-centre electrical and thermal infrastructure makes the physical cost of computation visible without presenting a quantitative chart or measurement dashboard.

Software was always part of the capacity equation

Computing capacity is usually discussed through hardware, electricity, cooling, facilities, and capital. Those inputs matter. But they are not the whole equation. The amount of work software asks a machine to perform matters too.

For large problems, researchers at MIT CSAIL found that 43% of the studied algorithm families had annual improvements that matched or exceeded the improvement associated with Moore's Law. In 14% of the problems, the software-side improvement was substantially faster. MIT CSAIL, "How fast do algorithms improve?"

Those findings do not say that software improves predictably every year. They do not say every problem has a better method waiting to be found. The study found wide variation, with progress arriving in steps rather than as a smooth curve. Its historical scope also should not be confused with a benchmark of any current product.

What it does establish is simpler and more important: hardware has never been the only source of computational progress. Software acceleration belongs in the capacity discussion because reducing the work required can change the cost of obtaining an answer. Sometimes the effect is modest. Sometimes it changes whether a large instance is practical. The correct response is measurement, not assumption.

This matters because capacity is not valuable merely as an inventory of machines. Capacity is valuable when it lets somebody ask another useful question.

How question debt accumulates

Question debt is easiest to see in ordinary decisions. It rarely announces itself as a dramatic failure. It accumulates in the alternatives that disappear from consideration.

Agenda. A laboratory must decide which experiments, instruments, people, and review steps fit into a limited week. If evaluating many possible agendas takes too long, the team chooses the first workable arrangement. The unpaid balance is not merely a less efficient calendar. It is the follow-up experiment that could not be placed, the sensitivity check left undone, and the unexpected result that never received a second run.

Routing. A service organization may have vehicles, technicians, delivery windows, changing demand, and obligations that cannot be violated. When recomputing routes is expensive, the team updates less often or reduces the number of alternatives it considers. Question debt grows between the route selected and the routes that were never evaluated. That gap can affect time, service quality, fuel, and the ability to respond when conditions change.

Experiment. A researcher may want to compare parameter choices, repeat a calculation under uncertainty, test edge cases, and challenge an early conclusion. If every additional run consumes too much budget or takes too long to return, the research agenda contracts. The first question may survive while the questions that would test it disappear. That is especially dangerous because confidence can rise while the breadth of investigation falls.

Allocation. A company, public agency, or research program must distribute scarce money, staff, equipment, or compute time. A coarse allocation may be defensible, but the team may never learn how sensitive the outcome is to different priorities or constraints. Question debt is paid when a policy is treated as inevitable even though alternatives were excluded by the cost of analysis rather than by evidence.

These are examples of the pattern, not a claim that HexStellar can represent every agenda, route, experiment, or allocation problem. A problem belongs in a computational system only when its entities, choices, constraints, objectives, and verification needs can be expressed honestly through a supported contract. If they cannot, the correct response is to explain the gap and abstain.

Access also involves more than the price of a processor. The U.S. National Science Foundation describes advanced cyberinfrastructure as an ecosystem that includes hardware, software, users, security, connections, expertise, and training. It notes that access remains limited by technical, cultural, and geographic barriers and argues that infrastructure should minimize the need for specialized skills that are not available to everyone. NSF, "Democratizing science through advanced cyberinfrastructure"

Lowering computational cost will not remove every barrier. But it can remove one reason a useful question never enters the queue.

Where I first encountered it

I encountered this idea while building Trust Carbon Infrastructure.

Trust Carbon had a real computation cost that I was trying to reduce. I was not beginning with a manifesto about the future of computing. I was trying to make an existing system cost less to operate. Following that practical problem changed the way I understood computational expense: a cost can limit not only how often a process runs, but also how ambitious the surrounding questions are allowed to become.

I will not turn that origin into a staged discovery scene. There was no single documentary moment that readers need to believe. There was a real cost, sustained engineering work, and a result important enough to investigate beyond its original setting. That work became the starting point for HexStellar. The public HexStellar account identifies Trust Carbon as the infrastructure project in which the initial software-acceleration and energy-efficiency work arose. HexStellar

Editorial visualization. A worktable connects environmental context and material investigation to the practical computation cost from which HexStellar began.

Today, Cortex is in production as HexStellar's managed computational service. It accepts supported structured requests and returns outputs, execution evidence, receipts, and explicit assurance labels. The Enterprise Runtime is the commercially licensed, customer-deployed path for compatible workloads. These are connected products with different contracts, availability, and evidence scopes. One should not be used as automatic proof of the other. HexStellar public product boundary

My interest is obvious: I founded HexStellar, and I want people to use it. That is exactly why the standard must be public behavior and reproducible evidence rather than founder confidence.

When an AI agent can call computation

An AI agent changes the interface to computation because it can translate a human request into structured data, inspect a machine-readable contract, and manage a multi-step exchange. But natural-language fluency is not evidence that the computational answer is correct.

The useful handoff has five parts:

1. The person states the objective, constraints, relevant data, acceptable cost, and required level of assurance.

2. The agent maps those requirements to public inputs that the service actually accepts. It must not invent a command or silently discard a constraint.

3. The request is validated and estimated before any paid, sensitive, or consequential execution. Authorization remains explicit.

4. Cortex executes a supported request and returns structured outputs, observable execution behavior, metrics, a receipt, and the assurance category earned by that result.

5. The agent or user applies the appropriate check: recomputing a witness or objective, checking constraints, using a supported verification operation, or performing a separate domain review.

Editorial visualization. A responsible agent-to-computation handoff preserves public inputs, authorization, observable outputs, certainty, and verification.

This does not make the agent infallible. If the input omits a real-world constraint, a computationally valid result may still be unusable. If the requested task does not fit an available contract, the agent should say so. If the output is heuristic, the agent should present it as a candidate. If an operation checks only feasibility, the agent should not describe it as proof of global optimality.

What changes is that computation becomes a callable, inspectable step in the agent's work. The agent can move from proposing an answer in prose to submitting a defined request, receiving a labeled result, and explaining what was and was not verified. The public HexStellar documentation and client repository describe this inputs-to-results contract, including machine-readable capabilities and explicit assurance categories. Documentation · Public CLI repository

There is a further question about agents reporting failures and improvement opportunities directly back to a service. That feedback cycle deserves its own article. It is intentionally outside this manifesto.

The public evidence standard

Here is the plain statement: this manifesto presents no HexStellar performance or energy number because the allowed public source set does not supply a complete, independently reproducible matched protocol for one.

That means no HexStellar timing, memory, throughput, capacity, temperature, or energy figure belongs in this article. A number does not become independently reproducible merely because it is public. The workload, input, environment, versions, metric, denominator, comparison conditions, correctness checks, and independent verification path must be complete enough for another party to repeat the test honestly.

This is not a conclusion that HexStellar produces no measurable effects. It is a conclusion about what this manifesto can responsibly establish from its permitted sources. The distinction matters. An editorial boundary should not be widened because a result would make the argument more dramatic.

The public verification contract remains meaningful. Readers can inspect the accepted input shapes, machine-readable capabilities, documented output fields, receipts, certainty labels, and supported verification paths. They can retain the input or generator, preserve relevant versions and seeds, recompute supported properties, and report where the observed behavior differs from the stated contract. HexStellar documentation · HexStellar public repository

That contract does not ask a reader to accept a universal performance conclusion. It provides a way to state a problem, receive an observable result, identify the assurance actually earned, and test the supported properties of that result.

Future quantitative claims in this article series should meet the same standard. Public numbers should arrive with public methods. If a complete matched protocol is not available, the honest result is abstention from the number.

What this does not prove

It does not prove a universal speedup. A measured improvement for one operation, input distribution, scale, software version, or environment applies to that tested scope. Another workload may improve less, remain unchanged, or perform worse.

It does not remove computational complexity. Hard problems remain hard. Some inputs will exceed practical limits, and a useful result at one scale does not establish the same behavior at a larger scale. Software acceleration can change practical cost without changing the underlying complexity class.

A certified answer proves only the submitted contract. More precisely, it establishes the named property under the declared assumptions and certification basis. It does not prove that the input captured every fact about the world. Missing obligations, incorrect data, unsuitable objectives, and domain risks remain outside the certificate unless they were represented and checked.

A verified operation is not automatically a certified optimum. Recomputing feasibility or an objective can establish that the returned candidate has those properties. It does not establish global optimality unless the stated verification basis actually supports that conclusion.

Energy claims are workload- and environment-scoped. They require a defined denominator, identified hardware, software versions, operating conditions, correctness checks, measurement instruments, and comparable runs. A percentage without those details is not a portable law.

Finally, production observations from Cortex do not automatically prove the Enterprise Runtime's full energy scope. Cortex runs supported work on HexStellar-managed infrastructure. The Enterprise Runtime is commercially licensed for qualified customer workloads. Evidence from one surface may motivate a test on the other; it cannot replace that test.

These limits are not footnotes added to weaken the argument. They are the conditions that make a claim useful.

Independent evaluations are already underway

Multiple researchers are already using Cortex directly to evaluate supported workloads and run benchmark studies with HexStellar. That is a founder-reported observation about activity in progress, not an independent public result or an endorsement.

I will not name teams, pre-announce scores, or turn private runs into evidence in this article. None of that work becomes a public HexStellar claim until the workload, environment, versions, method, correctness check, and artifacts are available at the level the conclusion requires. A benchmark can still be useful to its researcher before it is public; it simply cannot support public marketing language yet.

What matters at this stage is that evaluation protocols and questions are arriving from outside our own work. I expect the public record to expand as those researchers decide what they can release. That is an expectation, not a result, publication promise, or deadline. When material becomes public, it should be cited beside the exact conclusion it supports rather than summarized as a general claim that the product is universally faster or more efficient.

What I still do not know

I do not know the scale limits across every supported problem shape. Those limits may depend on the input structure, requested assurance, execution budget, and environment. They must be measured rather than generalized from a favorable example.

I do not yet know how broadly the benefits will carry to constrained hardware. Resource limits change what can run locally, what must remain managed, and what level of verification is practical. Portability is a workload-by-workload engineering question, not a promise that follows automatically from performance elsewhere.

I do not know the sustainable economics of meaningful free entry access. Access that is too restricted does little to reduce question debt, but real computation has real operating costs. The goal is to preserve an entry path that permits genuine evaluation while preventing abuse and keeping the service sustainable. The exact balance will require evidence and adjustment.

I also do not know what people will attempt once they can give an agent a computational contract. Some uses will be obvious extensions of scheduling, routing, selection, analysis, and verification. Others will come from researchers and builders whose domain knowledge we do not have. The honest boundary is that new uses are possible only when they map to supported inputs and can be checked appropriately.

Uncertainty is not an excuse to stop. It is a list of measurements still owed.

What I am committing to

I am committing to meaningful entry access. The limits may evolve as demand and economics become clearer, but the entry path should allow a researcher, builder, or agent to perform real evaluation rather than watch a decorative demonstration.

I am committing to attach public methods to public numbers. A performance claim should identify the workload, input, scale, version, metric, denominator, environment, date, provenance, and verification path. If those elements are missing, the claim should be qualified, postponed, or removed.

I am committing to explicit certainty labels. Certified, heuristic, verified operation, recorded measurement, and abstention are different statements. We will not promote one into another because stronger language is easier to market.

I am committing to remain open to reproducible reports, including reports that show a result is slower, more expensive, less stable, or less general than we claimed. A minimal input, exact command, version, environment, output, and independent check are more valuable than either praise or vague criticism. Reproducible disagreement is part of the product.

These commitments will not eliminate question debt by themselves. They define how HexStellar can argue that it is lowering the cost without asking readers to substitute trust for evidence.

Sources and methods

The energy figures come from the IEA's Energy and AI report. The historical software findings come from MIT CSAIL. Access-barrier context comes from the U.S. National Science Foundation. Product boundaries and public verification behavior were checked against HexStellar, its documentation, and its public CLI repository.

The Gates Notes essay informed only the broad discipline of moving from stakes to limits, uncertainties, and personal commitments; no phrases or voice were adopted. The draft follows Google's people-first content guidance by identifying the author, foregrounding first-hand experience, linking claims near their sources, and stating how the piece was produced. No internal benchmark, proprietary implementation material, or non-public laboratory result was used.

The energy problem is visible. Question debt is the cost we have barely begun to count.

BRAYON PIESKE — "Bring the problem you stopped asking."