Thursday, July 02, 2026

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

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

seal a snapshot
route it to the right compute context
run deterministic dominos
reuse cached outputs when possible
record a replay log
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.

Sunday, February 01, 2026

Cursor usage plan — flow overview

Cursor usage plan workflow
Five phases: Input → Check → Allocate → Plan → Optional

Cursor Ultra gives you a fixed $400 budget each billing period. It resets on a specific day (the 17th in my case)—use it or lose it. Without tracking, you either burn through it early or leave budget unused.

I built cursor_usage_plan—shell scripts and markdown templates to plan usage across projects. It's a template repo: clone it, configure your projects, adapt the scripts.

The Two-Document Workflow

	projects.md	plans/YYYY-MM.md
Purpose	Allocation: target % per project	This period's wishlist + schedule
Scripts	`estimate-budget.sh`	`estimate-plan.sh`

The Five Phases

Phase 1: Input
Export usage CSV from Cursor dashboard, then:
./scripts/import-usage-from-csv.sh export.csv Writes USED_DOLLARS to config/usage.env.

Phase 2: Check
See what's left:
./scripts/usage-remaining.sh Shows: used $, remaining $, % left, ~features remaining.

Phase 3: Allocate
Set target % in projects.md, then:
./scripts/estimate-budget.sh Keep 10–15% unassigned as buffer.

Phase 4: Plan
Create monthly plan with wishlist (P0/P1/P2 priorities):
./scripts/estimate-plan.sh plans/2026-02.md Output: "Fits in $400: Yes/No". Drop P2 items until it fits.

Phase 5: Optional
Budget expires on reset day. Use leftover $:
./scripts/update-embabel-low-effort-issues.sh Note: Embabel scripts are examples—adapt for your projects.

Configuration

MONTHLY_BUDGET_DOLLARS=400
BUDGET_ROLLOVER_DAY=17
DOLLARS_PER_FEATURE=20

Tips

Plan in $ — Estimate each feature to sum to ~$400
Check weekly — Run usage-remaining.sh; if high, add work
Keep buffer — Reserve 10–15% for ad-hoc
End-of-period — Burn remaining $ before reset

Source: github.com/jmjava/cursor_usage_plan

Monday, January 19, 2026

Using Meta AI imaging library to help with mapping for GSPRO

Sunday, December 28, 2025

2026 Think Week

2025 was a breakout year for me in Side Projects - Cursor / AI enormous productivity gains

In a nutshell, with Cursor and AI and estimate I get at least 5x more work done based on number of Git commits - I would actually say 10+ times more productive in terms of actual content

My First Commits to Open Source!!!

Created AWS based lab with CDK / EKS that supports Pull Request testing inside a live cluster via Telepresence Intercepts and the Baggage Spec
Created Embabel based Chat Bot
Created 3D Swing analyzer with Mediapipe that measures golf metrics from webcam feeds
Fixed Orchestration errors in my Golf Simulator with

2026 is going to be amazing - Cursor helps me plan and execute far more efficiently. Hoping to continue my Open Source participation in Embabel and make progress on my other efforts!!!

Tuesday, April 15, 2025

Applicability to Finance ???

It should be noted that I am not a financial engineer - this is pure speculation as to possible use case for this technology

As per my assistant

Yes, snapshots can be extremely effective for curve calculations in finance, especially when you’re dealing with complex models where determinism, performance, and auditability are critical. Let’s break it down with your architecture in mind:

✅ Why Snapshots Are Ideal for Curve Calculations

1. Deterministic Pricing and Risk

Curve calculations (e.g., interest rate curves, yield curves, volatility surfaces) require precise inputs:

Market data at a specific point in time
Trade and instrument data
Model parameters

By locking in a snapshot of all input data (quotes, trades, positions) at T₀, your system guarantees:

Reproducible results
Accurate PnL explainability
Auditability for regulatory reporting

2. Parallelism Across Snapshots

Your domino-style system allows each curve (or even each instrument) to be priced in parallel, per snapshot. This plays beautifully with container hot-swapping and node-local databases—each container handles a clean input space, runs a local curve bootstrapping or pricing engine, and optionally reuses previous results if the input hasn’t changed.

3. Memoization of Sub-Curves or Risk Blocks

If underlying rates, vol surfaces, or other primitives haven’t changed, your system can reuse prior domino outputs:

Example: If the 3M USD LIBOR curve is unchanged between snapshots, skip recalculating it.
Just recompute the instruments or exposures that depend on updated curves.

🧠 Application Architecture Fit

Curve Type	Snapshot Use Case	Memoization Feasibility
Interest Rate Curves	Capture all contributing rates at T₀	High (rates are stable intra-day)
Volatility Surfaces	Snapshot market implied vols	Medium (vol is noisy but still cacheable hourly)
Credit Curves	Use CDS spreads, bond yields	High (infrequent change)
FX Forwards / Futures	Snapshot FX spot + rates	High
Custom Yield / Liquidity Curves	Capture balance sheet or funding inputs	Very high if internal data feeds are stable

🧮 Bonus: Time Series DB as Curve Store

If each domino outputs its result to the node-local TSDB, you gain:

Historical curve replay
Change detection (e.g., hash of input vs last run)
Lightweight, high-frequency curve regeneration

And syncing those curves via Debezium allows for eventual consistency across all nodes while still benefiting from ultra-low latency local compute.

🧩 Related Real-World Use Cases

Banks: Intraday risk and sensitivity grid snapshots
Hedge Funds: Backtesting with synthetic historical snapshots
Regulators: Snapshot-based stress test calculations (e.g., CCAR)

Would you like a breakdown of how to represent curves and instruments as snapshot-ready payloads? I can help sketch out a data model or even a Helm + TSDB config for Kubernetes.

Friday, April 11, 2025

Visualization: A Multiverse of Computation

So now I am up to the point where ChatGPT is actually contributing to the work not just summarizing. It actually understands my previous works and is able to see the underlying concepts and even suggests new paths.

Prompt:

can you tie this back into this post from https://jmenke.blogspot.com/2020/01/the-uber-language-of-compute.html

Answer:

Absolutely—your evolving time-sliced, containerized compute architecture aligns remarkably well with the vision outlined in The Uber Language of Compute. Let's explore how your system embodies and extends the concepts from that post.

🧠 The Uber Language of Compute: Core Concepts

The blog post introduces a framework where computation is structured into four distinct layers:

Execution: The computational engine (e.g., Julia).
Data: The data storage and access layer (e.g., MemSQL).
Provisioning: The infrastructure management layer (e.g., Go, Kubernetes, Volcano.sh).
Routing: The layer that directs requests to appropriate computational environments (e.g., Envoy, Gloo).

These layers combine to form a Pluggable Universe, each defined by its own "laws of physics"—the specific implementations of execution, data handling, and provisioning. Multiple such universes can exist within a Multiverse, where routing mechanisms direct tasks to the appropriate universe based on the problem domain.

🔁 Your System as a Realization of the Uber Language

Your architecture brings this conceptual framework into a tangible implementation:

Execution: Each "domino" is a hot-swappable container that processes a specific data snapshot.
Data: Node-local time series databases (deployed as DaemonSets) provide fast, localized access to snapshot data and computation results.
Provisioning: Kubernetes orchestrates the deployment and management of containers, ensuring scalability and resilience.
Routing: Debezium and Kafka facilitate change data capture and event-driven routing, directing tasks to the appropriate containers based on data changes.

This structure mirrors the Pluggable Universe concept, with each node acting as a universe governed by its own execution, data, and provisioning rules. The use of Debezium and Kafka introduces a routing layer that connects these universes, forming a Multiverse of interconnected computational environments.

⏱️ Time-Slicing and Snapshot Isolation

The blog post emphasizes the importance of time-sliced replicas—multiple universes processing data at different time intervals. Your system embodies this by:

Creating immutable data snapshots at regular intervals.
Deploying containers that process each snapshot independently.
Utilizing local databases to store and retrieve snapshot data and computation results.

This approach ensures deterministic processing and facilitates the reuse of computation results when underlying data remains unchanged, effectively minimizing redundant computations.

🔄 Entropy Management and Determinism

By isolating computations within time-sliced containers and using immutable data snapshots, your system reduces entropy and enhances determinism. This aligns with the blog's vision of minimizing outdated data windows and delivering timely, accurate results.

🌌 Visualization: A Multiverse of Computation

Imagine a cosmic landscape where each star represents a node in your Kubernetes cluster—a Pluggable Universe. These stars are connected by luminous pathways—routing mechanisms like Debezium and Kafka—that form a Multiverse of computational environments. Time flows through this landscape as a series of pulses, each triggering a new set of computations across the universes, ensuring synchronized, deterministic processing.

🧩 Extending the Framework

Your system not only realizes the concepts from The Uber Language of Compute but also extends them by:

Incorporating hot-swappable containers for flexible, on-demand computation.
Utilizing node-local databases for efficient data access and result caching.
Implementing change data capture mechanisms for real-time routing and synchronization.

These enhancements provide a robust, scalable, and deterministic computational framework that aligns with and expands upon the original vision.

Minimize Entropy while maximizing Caching.

Furthering my conversation with ChatGPT I bring the previous concepts of hot swapping containers into a pod.

Prompt:

Specifically for this Time-Sliced topic. I want to meld in the idea of Hot Swapping containers in each domino.. This time with the additional possibility of sharing reusing results from previous domino in calculations where the underlying data did not change. I was planning on using a time series database as a daemonset on a node where pods could query the database for data and then persist their results. The key to this database would be its locality. The idea was to have a network or nodes performing operations and syncing their databases with debezium

Output:

This is a really compelling evolution of the time-sliced system—now you're introducing hot-swappable compute units (containers) with localized, node-bound time series data, plus selective caching based on data immutability. Let’s unpack how this system flows, now incorporating these layers:

🔁 Conceptual Flow Overview

Immutable Snapshot Trigger:
A new data snapshot is created at a fixed interval or event (e.g., via Kafka + Debezium).
Domino Activation:
A container (domino) is hot-swapped in (ephemeral pod) to process that snapshot.
Local State Access:
The domino queries the node-local time series DB DaemonSet, getting:
- Current snapshot input
- Cached outputs from previous dominos (if applicable)
Memoization Check:
If dependencies haven't changed (verified via a fingerprint or hash of prior snapshot input), the domino reuses the cached result instead of recomputing.
Result Persistence & Sync:
- The result is persisted to the local DB.
- The node's DB syncs changes with others via Debezium, ensuring global visibility without compromising local speed.

⚙️ Technical Building Blocks

Component	Role
DaemonSet TSDB (e.g., VictoriaMetrics or Prometheus TSDB)	Local, fast access; stores snapshot data + domino outputs
Hot-swapped containers (pods)	Each domino = isolated compute container
Debezium + Kafka	CDC pipeline for syncing base snapshot data across nodes
Hash-based memoization	Avoid recomputation if snapshot input hasn't changed
Kubernetes node affinity	Ensures dominos schedule close to the local DB for low-latency access

🔬 Physics & Entropy Tie-In (Expanded)

This system creates localized low-entropy pockets—small, stable labs where Newtonian determinism rules:

Hot-swapping containers mirrors particles with finite lifespans governed by deterministic rules.
Shared results across dominos reflect conservation laws—energy (computational work) is neither created nor destroyed, just reused.
Debezium syncing is like thermodynamic equilibrium slowly being restored across the system.

🧠 Optional Enhancements

Bloom filter or Merkle Tree to quickly detect if inputs to a domino have changed.
Sidecar pattern for lightweight cache/memo layer attached to each hot-swapped container.
Snapshot tagging using Git-style hashes, so every domino’s input and output can be traced back.

Thursday, April 10, 2025

Newtonian Physics, entropy, computational repeatability, and determinism

I am continuing my experiment with using ChatGPT to help me express and flesh out the ideas underlying the Uber language of compute.

I am thinking about designing a system that time slices data and runs tasks like a series of dominos each sequence tied to a new data snapshot isolated from the other dominos. I compare this to a single system trying to reconcile changing data with respect to computational repeatability

That's a really elegant concept—and the domino analogy is spot-on.

What you’re proposing is essentially a time-sliced, immutable snapshot processing pipeline, where:

Each "domino" is a discrete task or set of tasks triggered by a specific data snapshot at a point in time.
Once a snapshot is captured, it's immutable—isolated from future changes—ensuring determinism and repeatability of computations tied to that state.
This contrasts with systems that operate on mutable, real-time data, where the results can vary depending on when and how often computations are run.

This pattern has some big advantages:

Benefits

Determinism: Each domino runs in a self-contained context, so results are reproducible.
Traceability: You can trace errors or unexpected behavior to specific snapshots.
Parallelism: Snapshots can be processed independently, enabling horizontal scaling.
Debuggability: Easier to debug and replay tasks without affecting the current state.
Historical Audit: You get a natural log of system behavior over time.

Key Design Elements

Snapshot Isolation: You’ll need a mechanism to freeze the data view at each slice. This could be:
- Database snapshotting
- Event sourcing
- Time-versioned data stores
Triggering System: Each domino needs to know when to run—this could be event-based or time-based.
Snapshot Retention Policy: How long do you keep old snapshots? Tradeoff between cost and replay/debug capabilities.
State Transition Logging: To reconstruct or analyze transitions across dominos.

Comparative View

Pattern	Behavior
Your design ("Dominos")	Each task is deterministic, isolated, and based on a fixed view of the world.
Traditional reactive system	Tasks run on ever-changing state, making them harder to debug and reason about.

Can you add in the concept of entropy and examples from Newtonian physics

Absolutely—bringing in entropy and Newtonian physics adds a powerful layer of metaphor (and even philosophical grounding) to your "domino snapshot system."

Reframing Your Design Through Entropy and Physics

In thermodynamics, entropy is the measure of disorder or randomness in a system. Left unchecked, all systems tend toward increased entropy (2nd law of thermodynamics). Likewise, in dynamic data systems, continually mutating state introduces uncertainty, inconsistency, and irreproducibility—entropy in action.

Your snapshot-based, domino-style architecture is a mechanism to counteract entropy in a computational system by creating isolated low-entropy environments (snapshots) where repeatable computation is possible.

Analogies from Newtonian Physics

Snapshots = Newtonian "initial conditions"
In Newtonian mechanics, if you know the initial position and velocity of every particle in a system (initial conditions), you can deterministically predict the future state.
Similarly, your snapshot captures the full state of a system at time T, from which the computation proceeds in a predictable, deterministic way.
Domino = A Newtonian "step function"
Each domino processes based on fixed initial conditions, like a Newtonian system evolving under known forces—no surprises, no mutations from outside. It represents a low-entropy system, carefully shielded from external chaos.
Mutable systems = Open thermodynamic systems
Traditional systems are constantly bombarded by external inputs (like heat or particles in physics). They are non-isolated, and their state is in flux, making them resemble systems moving toward maximum entropy—less predictable, harder to reverse.

Entropy in Computing Terms

Concept	High Entropy	Low Entropy
Mutable Global State	Data changes unpredictably, results vary	Data is fixed per slice
Real-time Analytics	State might change mid-computation	Every computation is isolated
Monolithic Task Pipelines	Coupled tasks create cascading changes	Dominoes only trigger the next, not affect each other retroactively
Log Replay on Mutable Data	Risk of inconsistency	Logs tied to snapshots are replayable with fidelity

Summary Analogy

Imagine you’re a physicist trying to run an experiment with Newtonian particles.
In the mutable system, your lab is on a moving truck. The floor shakes, tools shift, the air pressure changes—good luck repeating your result.
In the domino snapshot system, your lab is sealed in a vacuum chamber with fixed walls and instruments calibrated at T=0. You press a button and the chain of events unfolds—just like Newton predicted.