Announcing KBL Compute Engine: Implementing the Uber Language of Compute

I have started a new open-source project to turn the ideas from my earlier Uber Language of Compute posts into an actual working library:

Project: KBL Compute Engine — uber-lang-of-compute on GitHub

The short version: this project is my attempt to implement the “Uber Language of Compute” as a time-sliced, data-local, Kubernetes-native compute fabric.

Instead of treating compute as a single monolithic application, KBL models compute as a set of declarative layers:

• Execution — what runs
• Data — what data is used, where it lives, and how it is frozen
• Provisioning — how compute/storage resources are allocated
• Routing — which universe, node, context, or time slice handles the work

That four-part model comes directly from the original post: The Uber Language of Compute. In that post I described computation as an aggregation of Execution, Data, Provisioning, and Routing. I also introduced the idea of a Pluggable Universe, where each universe has its own “laws of physics,” and a Multiverse, where routing connects many such universes.

What KBL Implements

The new library turns those ideas into concrete Kubernetes-style building blocks:

• Snapshots — immutable data views tied to a time slice
• Dominos — deterministic compute steps that run against one snapshot
• Workflows — ordered chains of dominos
• Compute Contexts — node-associated units of compute plus local data
• Compute Wheels — rotating sets of contexts processing time slices continuously
• Pluggable Universes — swappable execution/data/provisioning environments
• Multiverse Routing — routing work across universes, partitions, and time slices
• Node-local stores / TSDB — keeping data and memoized results close to compute
• Replay logs — recording exactly what ran, what was reused, and what was recomputed

The repo is organized around those concepts: Vocabulary, Architecture, CRDs, controller/runtime, examples, and a local Kind lab.

How the Library Maps Back to the Original Blog Ideas

``` ```

Original Idea	Source Blog Post	KBL Implementation
Computation is composed of Execution, Data, Provisioning, and Routing.	The Uber Language of Compute	KBL defines this as a four-DSL model. See ADR 0001: Four-DSL Model and the schemas under specs/.
A Pluggable Universe is a compute environment with its own laws of physics.	The Uber Language of Compute	KBL models this through PluggableUniverse definitions and routing abstractions. See Vocabulary and ADR 0009: Multiverse Routing.
A Multiverse routes work to many pluggable universes, including time-sliced replicas.	The Uber Language of Compute	KBL implements this through Multiverse routing, ComputeWheels, and examples like multiverse-finance.
Time-sliced computation should freeze data so results are repeatable.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL introduces Snapshot resources: immutable, sealed data views that gate computation. See ADR 0002: Snapshot Isolation.
Dominos represent deterministic compute steps tied to a snapshot.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL has Domino CRDs and workflow chains. A domino is intended to be referentially transparent: same snapshot plus same inputs equals same output.
Entropy is reduced by isolating the system at T=0, like Newtonian initial conditions.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL treats snapshots as low-entropy initial conditions. Replay logs, input hashes, and immutable snapshot sealing make computations reproducible and debuggable.
Minimize recomputation by caching prior domino results when inputs have not changed.	Minimize Entropy while maximizing Caching	KBL uses memoization: input hash to output hash and payload. Re-running the same workflow can reuse results instead of recomputing them.
Keep data local to the node where compute runs.	Minimize Entropy while maximizing Caching	KBL starts with SQLite as the MVP node-local store and evolves toward a node-local TSDB DaemonSet. See ADR 0003: Node-Local Data and ADR 0008: Node-Local TSDB.
Hot-swap containers in a daisy chain so only a small number are active at once.	Uber Language of Compute: Hot swapping containers in daisy chain	KBL models this as DominoChain / hot-swapped dominos, with placeholder slots, handoff volumes, and OpenKruise-style in-place updates. See ADR 0004: Hot-Swapped Dominos.
Finance curve/risk calculations are a good test case because they require deterministic snapshots.	Applicability to Finance ???	KBL includes finance examples, including curve snapshots and Julia-based finance dominos. See finance-curve-snapshot and julia-domino-chain.

The Key Shift: From Blog Metaphor to Runtime

The older posts were mostly conceptual. They used metaphors like physics, entropy, dominos, and multiverses to describe how repeatable computation might work if compute was broken into isolated, deterministic, time-sliced units.

KBL is the implementation path.

In the library, the metaphor becomes concrete:

• The “initial condition” becomes a sealed Snapshot.
• The “domino” becomes a deterministic compute step.
• The “low entropy lab” becomes a node-local Compute Context.
• The “pluggable universe” becomes a swappable execution/data/provisioning environment.
• The “multiverse” becomes routing across universes and time slices.
• The “conservation of work” becomes memoization and replay.

Why This Matters

Most compute systems either lean toward batch or streaming. Batch is repeatable but often slow and stale. Streaming is current but can become hard to reproduce because the underlying state is always changing.

KBL is trying to explore a third path:

Run compute against immutable time slices, keep the data local, reuse prior work when the inputs have not changed, and route work across pluggable compute universes.

The goal is not just faster compute. The goal is compute that is:

• repeatable
• auditable
• data-local
• memoized
• replayable
• routable across heterogeneous compute environments

Current State of the Project

The repo already contains the first working pieces:

• a local CLI runtime
• a Kubernetes controller path
• CRDs for snapshots, dominos, workflows, compute wheels, multiverse routing, and related resources
• examples for finance curve calculations
• memoization and replay-log concepts
• node-local storage abstraction
• a Kind lab for running the stack locally
• AWS CDK scaffolding for EKS/ECR deployment
• Julia pluggable execution for finance-oriented dominos

The project is still experimental, but the direction is now much clearer: this is the bridge between the old “Uber Language of Compute” theory and an actual Kubernetes-native runtime.

Source Links

• KBL Compute Engine GitHub Repository
• The Uber Language of Compute
• Uber Language of Compute: Hot swapping containers in daisy chain
• Newtonian Physics, entropy, computational repeatability, and determinism
• Minimize Entropy while maximizing Caching
• Visualization: A Multiverse of Computation
• Applicability to Finance ???

Next

The next step is to keep tightening the implementation until the architecture can prove the full loop:

1. seal a snapshot
2. route it to the right compute context
3. run deterministic dominos
4. reuse cached outputs when possible
5. record a replay log
6. materialize results back into the multiverse

That is the point where the Uber Language of Compute stops being only a language of ideas and starts becoming a real compute engine.