For Investors
The economics of incremental computation.
HST addresses a structural inefficiency in high-performance computing: systems recompute work they already know. The cost compounds as systems scale.
Market
Fixed-topology physical networks.
Power transmission and distribution, utility and sensor hierarchies, and data-center telemetry all share one shape: a large sparse operator fixed by physical topology, a state that changes in a small clustered fraction each cycle, and an aggregate recomputed from scratch on a fixed cadence. That is the whole addressable surface, and we describe it narrowly on purpose.
The operators inside these industries that genuinely stay fixed sit around the solver, not in it — sensitivity matrices such as PTDF and LODF applied thousands of times per screening cycle, telemetry rollups over a fixed tree, and incidence propagation with the flow field frozen over a timestep. Solvers themselves relinearize every iteration and are not a market for us.
Technology
An in-process library, not a service.
HST ships as an embedded C library that the customer links into the process already holding the state. A single delta application saves well under a millisecond, so any network hop inverts the value — we measured that and deprecated our own REST and container distribution rather than sell around it.
The integration story is bounded: a small C ABI, no rewrite of the surrounding system, and direct measurement of runtime, touched nonzeros, memory behavior, and error against the customer's existing baseline. The result is exact to floating-point roundoff, not an approximation.
Stage
Two full-time founders in a team of eleven, pre-revenue. Everything below should be read against that.
Competitive Position
As of mid-2026 we have found no public delta-input sparse matvec runtime to compare against. The alternatives customers actually have are a hand-built incremental path or full recompute.
Unit Economics
Two priced components today: a trace-based fit assessment, and fixed-fee integration and tuning. The tuning is real engineering work and is priced as such rather than absorbed as pre-sales labor. The runtime itself is not one of them — the community build is Apache-2.0, unmetered, and free for production use. A recurring per-deployment license is the intended third component and does not exist: it depends on a paid build we have not yet produced, and we would rather say that than count it.
Defensibility
Two months of measured wins and measured losses across roughly fifty use cases. Knowing exactly which churn rates, locality profiles, and operator sizes work is what prices deals and kills bad ones early. The derivation itself stays offline; what ships is machine code behind a small ABI.
Risks and falsification
What would tell us we are wrong.
The envelope may be too narrow to be a business. Roughly fifty use cases have been tested. The wins cluster tightly in one shape and the failures outside it are structural rather than tuning problems. This may be one deep customer rather than a market, and we would rather find that out early than sell into it.
The buyer may be unreachable. Grid and utility software is vendor-locked and slow. Our kill signal is explicit: no pilot conversation by the end of the quarter means the segment assumption was wrong, not that we need more outreach.
"We could build this in-house" may be correct. An exact delta loop over a sparse matrix is not hard to write. What we sell beyond the kernel is the schedule machinery and the fit instrumentation. If that argument loses twice, the honest read is that this is consulting with a library attached, and it should be priced that way.
Energy claims do not generalize. Our own measurements cut both ways depending on the workload: a narrow probe favoured the kernel, a full end-to-end workload did not. Work reduction and energy reduction are not the same thing, and we quote energy per workload or not at all.
Key-person risk is real. Two full-time people, with the theory and the shipping work each concentrated in one of them.
Path forward
One proven deployment before a platform.
Near term: sell trace-based fit assessments into grid and fixed-network operators, and count documented disqualifications as a valid outcome alongside sales. The measured grid result is the opening evidence.
After that: one production integration in a customer's hot loop, with the exit criterion being a number in their monitoring rather than ours. A second vertical only after the first one holds.
Every performance figure on this site traces to a committed benchmark, and where we have only a shape argument we label it as such.