The computation structure is stable. HST reads it once and keeps it.
Speeding up compute with HST
HST routes only the tiles that moved, then returns an exact result or falls back when the update is no longer local. Hierarchical Sparse Transform helps changing systems avoid repeating work they already know.
Tell us what changes in your system, what must remain exact, and your deployment target (container, stack, or orchestrator). That is usually enough to give a first-fit estimate quickly.
Grid
64 × 32
Changed tiles
—
Motion density
—
Tiles reused
—
The idea
Most systems do not start over because everything changed.
Cameras, books, grids, rankings, and scoring systems usually move in pieces. A few inputs change. The structure around them stays familiar.
HST is built for that shape: keep the reusable work, update the changed state, and fall back to the exact path when the change is no longer local.
A small input moves. HST finds the affected boundary, not the full domain.
Exact routes match full recompute; approximate routes report error and fall back when required.
Local update streams can avoid broad sparse traversal when the dirty region stays small.
HST keeps the long pole small by reusing what is already known.
Measured against sparse baselines with matrix size, touched work, runtime, and relative error reported.
The operating loop
From changed state to exact answer, without paying for the unchanged middle.
HST sits between the source system and the expensive compute path. It watches the delta, maps the dependency boundary, updates the necessary region, and hands the result back through the interface teams already understand.
-
01
Capture the delta
New frame, new event, changed sparse row, or updated grid cell.
-
02
Find the boundary
The math layer asks which dependencies actually moved.
-
03
Reuse the known work
Stable state remains cached, structured, and cheap.
-
04
Return the result
Exact mode preserves correctness; budgeted mode prioritizes impact.
Use cases for HST
HST is the math layer that sits between full recomputation systems and changing workloads.
HST treats each input as a sparse edit. It builds dependency boundaries, updates only the impacted region with fast local math, and stitches in a mathematically exact result when needed. Think: an intermediate layer that absorbs local change before a global system pays full cost.
Model the fit
Choose the workload shape. Watch where HST inserts itself.
Sparse kernels are a direct fit: replace the familiar call, keep the workflow intact, and use HST to avoid low-impact memory traffic.
Mode
Exact sparse call
Reused state
71%
Pressure point
Memory traffic
Streaming input systems
Many event updates are local. HST tracks changed columns and routes the sparse delta through affected operator regions.
Stateful compute pipelines
HST keeps prior state available, applies A dx against the fixed operator, and reports the route used.
Simulation and scoring workloads
When a state cell changes, HST identifies the operator support touched by that delta and checks error against exact baselines.
Search and ranking refresh loops
Small ranking deltas can be propagated through sparse operator edges without rescoring cold regions.
Physics, vision, and CV pipelines
HST sits as the boundary-aware math function between frames, so unchanged regions remain frozen and cheap.
Deployment
HST runs where your compute already runs.
HST ships as a single container image behind a versioned REST contract. Run it standalone, drop it into the stack you already have, or hand it to your orchestrator. The integration point does not change: your service sends the delta, HST returns the exact result with timing and accuracy telemetry.
Run it as its own service
One image, one command. HST comes up on port 8080 with a persistent operator cache. Your application calls it over REST or WebSocket and receives the recomputed result.
docker compose up -d
Sit beside what you already run
Add the HST image to the Compose file or pod you already deploy. Your service swaps its expensive call for a localhost request. No new infrastructure, no data leaving your network.
image: hst-service:1.0.0
Push to your registry, scale it out
Publish to ECR or GHCR, then run on ECS Fargate or Kubernetes with the provided Helm chart. Health checks and resource limits ship in the box.
helm install hst hornesci/hst
In production mode, your license and API keys mount as secrets from your own secrets manager. HST runs entirely inside your boundary and never calls home.
Compare notes
Bring the workload shape and deployment plan.
HorneSci is strongest in sparse, structured systems where local changes should not trigger broad sparse traversal. Bring your workload profile (changed data pattern + target latency), your exactness requirements, and how you prefer to deploy: sidecar service, standalone container, or orchestrated rollout.
Boundary
If everything changes, HST should say so.
The product is strongest when updates are local. When they are not, the answer should be boring and honest: use the exact route.