Velocity Engineering: Putting Numbers on Trust
By Jay Titus — Left Hand Security
If it runs on probability, govern it with numbers.
Velocity Engineering is the companion to Velocity Architecture. Velocity Architecture shows leaders where trust limits their speed. Velocity Engineering turns those limits into numbers that engineers can design with. The paper is coming soon. This preview shows one part of it: the limits go in as variables, and what comes out are functions.
The Limits, as Variables
| Variable | What it is |
|---|---|
| Drift (λ) | Error or misalignment a step introduces when nobody is looking. An honest mistake or an attacker’s nudge; the math doesn’t care which. |
| Correction (ρ) | The share of drift caught and fixed before it matters. It can approach 1 but never reach it. |
| Trust floor (τ) | The minimum reliability the task needs. A draft blog post might accept 0.8; a payment needs far more. |
| Step time (s) | How long one step of the AI’s work takes. |
| Check-in cost (c) | How long one human review takes. |
What Comes Out
Trust Decays. Each step loses the drift we fail to catch, so trust falls off exponentially, exactly like a component’s survival in reliability engineering:
T(t) = e^(−λ(1−ρ)t)
The Horizon. How many steps the AI can run before trust reaches the floor. It’s your trust budget divided by your uncaught drift:
H = −ln τ ÷ λ(1−ρ)
Velocity. Useful work per unit of time, counting the human check-ins:
V = 1 ÷ [ s + c·λ(1−ρ) ÷ (−ln τ) ]
The Ceiling. Perfect correction would make the check-ins vanish and velocity equal raw machine speed. Perfect correction doesn’t exist, so for every real system the human moves further out, but never out of the picture:
V < V(machine)
Run It
A trust floor of 0.95, drift of 0.01 per step, one-minute steps and 30-minute reviews:
| Correction (ρ) | Horizon (steps) | Velocity (share of machine speed) |
|---|---|---|
| 0 | 5 | 15% |
| 0.5 | 10 | 25% |
| 0.9 | 51 | 63% |
| 0.99 | 513 | 94% |
The model’s own speed never changed. Velocity rose from 15% to 94% of machine speed purely by improving correction, and each extra “nine” multiplied the horizon by ten. That is the paper’s central prediction, not yet a measured result:
Once agents are fast, velocity is governed by correction, not by model speed.
The Variables Are Functions
In practice none of these is a fixed number. Each one is set by design decisions. Drift depends on which tool does the step (code, machine learning or generative AI) and how far its input can be trusted. Correction depends on what checks the work and how well the people reviewing it understand it. The floor depends on blast radius, reversibility and law. Check-in cost depends on who reviews and how the work is presented. Choose those, and the limit follows. That turns the equation from a description into a design tool.
Coming Soon
That’s one part of Velocity Engineering. The full paper also covers why correction has to be a fleet of independent checks, the security corollary (an attacker who can poison what a system learns from turns correction negative), where to invest, and how to place each step on code, machine learning or generative AI. Talk to us about putting numbers on your own processes.