Velocity Engineering: Putting Numbers on Trust

If it runs on probability, govern it with numbers.

Velocity Engineering is the companion to Velocity Architecture. Velocity Architecture designs your people, process and technology for maximum velocity, maximum trust and minimal decay. Velocity Engineering turns its limits into numbers that engineers can design with, and what comes out of those numbers becomes the requirements, and much of the specification that agents need to build, controls you should implement and to secure the system being evaluated. The paper is coming soon. This preview explains the principles, with an example; the details are still being finished.

Velocity Architecture: Threat Modeling + Velocity Modeling

Velocity Architecture combines two kinds of modeling:

• Threat Modeling finds the trust boundaries: where trust changes, and what can go wrong there. Methods like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege) name the threats at each boundary.
• Velocity Modeling finds the trust limits: how fast the work can go before trust breaks.

The two feed each other. A boundary pulls a limit in, and isolating part of the work to move a limit draws a new boundary. Velocity Engineering puts numbers on both.

Max Velocity Is the Limit of Trust

The core principle: work can go only as fast as you can trust it. Velocity modeling asks three sets of questions, PACER, SPEC and PROBE:

• PACER Sets the Floor: the slowest the business can afford to go, given how fast partners, attackers, customers and rivals are moving.
• SPEC Tests Admissibility: the applicable non-negotiable safety, privacy, ethics, legal, regulatory, contractual, compliance and security requirements. Each specific requirement is tested independently as pass or fail.
• PROBE Sets the Ceiling: the fastest the work can safely go. PROBE measures trust as five limits (People, Reversibility, Output, Boundary and Expense), and the lowest of them is the ceiling.

SPEC is not a threat taxonomy and it is not one broad score. Each applicable obligation is stated precisely, assigned an owner, supported by evidence and tested independently. A failed requirement blocks the affected action until the design or process changes.

In principle:

Current potential velocity = the safe operating velocity permitted by the binding PROBE limit under today’s conditions.

A feasible operating range exists when current potential velocity meets or exceeds the PACER floor and all applicable SPEC requirements pass.

• The Lowest PROBE Limit Wins. No strength elsewhere makes up for it.
• SPEC Is Requirement-Level Pass or Fail. A failed applicable requirement blocks the affected action, regardless of its potential velocity or business value.
• Below the Floor, standing still isn’t an option. You redesign, invest, isolate or throttle until the ceiling clears it.

A Limit Is One Thing Made of Many Factors

The second principle: no limit is a single number someone hands you. Each is built from many factors, and what trust means differs from one business to the next. For example, the factors might come from:

• A Business Interview: how much a mistake costs, whether it can be undone, what customers will accept, and how much risk the business will take.
• The Engineers: independent checks, logging and rollback, and how far untrusted input can reach.
• A Technical Examination: which controls already exist, and what the missing ones would cost.
• Human Factors: what people actually understand (what HLRF measures), their engagement and purpose, and how much they can review.

The human factors are not satisfied by assigning someone to review AI output. The person must retain enough understanding and practice to recognize when the output is wrong, know when to intervene and remain capable of doing the work when needed. Air France Flight 447 is a tragic illustration of what can happen when automation changes the work faster than human practice is maintained. The lesson is not to avoid automation; it is to engineer the human capability that safe automation still depends on.

Two things make finding the lowest limit harder than finding the lowest score:

• Factors Are Shared. What reviewers understand affects both People and Output; an independent check affects both Output and Boundary. Improve one factor and two limits can rise, or a different limit becomes the lowest.
• Every Factor Has a Cost. Some controls are nearly in place; others need real investment. The goal is to identify the most valuable and affordable changes that move the binding limit toward the business target. The first assessment establishes current potential velocity; it is a baseline, not a permanent ceiling. As controls, infrastructure, people and models improve, potential velocity can move. Reassess it against the PACER floor and the business’s target rather than treating the first result as fixed and never changing. This is only your starting velocity.

One way to combine factors, for example, is a weighted geometric mean, with the weights set by the business. A strong factor offsets a weak one only partly, and a factor near zero pulls the whole limit down:

Limit = x₁^w₁ × x₂^w₂ × … × xₙ^wₙ, where the weights add up to 1

The Functions: Putting Numbers on Correction

Each limit needs functions that turn its factors into speed. One of the most important is correction: how much work an AI can do between human reviews before trust falls below what the task needs.

Variable	What it is
Drift (λ)	The share of the AI’s work that goes wrong 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.
Minimum trust (τ)	The least reliability the task can accept. A draft blog post might accept 0.8; a payment needs far more.
Work time (s)	How long one unit of the AI’s work takes.
Review time (c)	How long one human review takes.

Trust Decays. Each unit of work loses the drift that correction misses, so trust falls exponentially, the same way component survival does in reliability engineering:

T(t) = e^(−λ(1−ρ)t)

The Horizon. How much work the AI can do before trust falls below the minimum:

H = −ln τ ÷ λ(1−ρ)

Velocity. Useful work per unit of time, including the time spent on human reviews:

V = 1 ÷ [ s + c·λ(1−ρ) ÷ (−ln τ) ]

Correction Is a Fleet. No single check catches everything. When checks fail independently, an error gets through only if every one of them misses it:

ρ = 1 − (1 − p₁)(1 − p₂) … (1 − pₙ), where p is what each check catches

The Machine Limit. No correction is perfect, so velocity never reaches the machine’s raw speed. People move further out, but never out of the loop:

V < V(machine)

None of these is a fixed number. Each is set by design decisions: which tool does the work, what checks it, and how well the reviewers understand it. Choose those, and the limits follow. That turns the equations from a description into a design tool.

What Comes Out: Requirements and Specifications

The output isn’t only a limit. Every threat, SPEC obligation, limit and decision becomes a traceable requirement. Each requirement can be written precisely enough to hand to developers and AI agents: the required control or behavior, the acceptance criteria and test that prove it works, and the operational signal that shows it continues to work. These requirements can produce infrastructure-as-code, identity and access configurations, policy-as-code, security controls, evaluation suites, CI/CD gates, monitoring rules, rollback mechanisms and training or competency programs.

The architecture also produces an investment and focus plan: which limits are binding, which interventions can move them, what those interventions cost, and which should happen first. Engineering turns that plan into measurable operating constraints and buildable specifications. Requirements should remain traceable from the originating threat, SPEC constraint or PROBE finding through implementation, testing and measuring the system continuously.

How the Two Fit Together

1. Velocity Architecture Establishes Direction: should we do it, what velocity is required, what is currently possible, and which constraints and investments matter most?
2. Velocity Engineering Calculates the Operating Envelope: how each limit is derived from its factors, what the current potential velocity is, and what changes would move it.
3. Engineering Produces the Assets: requirements and specifications become infrastructure, controls, policies, tests, monitoring, operational procedures and human capability programs. For people, this includes the HLRF plan: role-specific learning goals, demonstrated-judgment assessments, targeted practice, reinforcement and reassessment.
4. The System Is Reassessed: better models, improved controls, changed skills, new threats and new business conditions or regulations can raise or lower potential velocity. Measure again and set the next target. Measurement is best observed as a continuous process

Example: AI Invoicing

Illustrative: the company, costs, rates and scores are examples. This continues the Velocity Architecture example, which decided whether to do it and how fast.

The Story

A mid-sized company has the equivalent of two full-time people handling invoices: receiving them, matching them, paying them and chasing what customers owe. It costs about $100,000 a year. AI could do most of that work. Building the system would cost about $60,000, and running it about $20,000 a year.

It also opens new security risks. Invoices come from outside, so any of them can carry a fake bank account, or instructions hidden for the AI that reads it. Fraudsters already pose as vendors to redirect payments, and an AI that pays faster can be fooled faster. Two large vendors also want to send invoices straight from their own systems, one through its own AI agent. And the invoices, full of vendor and bank details, now pass through an AI provider.

The architecture work answered the business question: do it, but not until the security controls are in place. Under the initial constraints, the example’s current potential supports a first operating phase around 60% of machine speed. After additional controls, independent checks and human reinforcement, reassessment supports a higher potential, with a business-selected operating ceiling of 90% so people retain sampling and review capacity. These figures are illustrative, not universal constants. The engineering question is how to calculate, implement and verify each step toward that potential.

The Threat Model

STRIDE	What it looks like here
Spoofing	A fraudster poses as a vendor, or changes a vendor’s bank details, including through a vendor’s integration
Tampering	An altered invoice, or instructions hidden in an invoice for the AI that reads it
Repudiation	No record of who, or what, approved a payment
Information disclosure	Vendor and bank details exposed through the AI provider or an agent’s tools
Denial of service	A flood of fake invoices that buries the reviewers
Elevation of privilege	An agent tricked into using payment authority it should never have had

The Velocity Model

• PACER: attackers can impersonate a vendor and change bank details in minutes, so they set the floor for how fast fraud must be caught.
• SPEC: the applicable authorization and record-retention requirements must be satisfied, each with its own evidence and pass/fail result.
• PROBE: Boundary is the lowest limit today, a stopping point until the controls exist. Invoices and vendors’ own AI are untrusted input, and the system that reads them would have the authority to pay. Reversibility is close behind: money sent to a fraudster is hard to get back.

How We Arrived at the Limit

The architecture work scored Boundary at 2. Here is where that number comes from. In this example, Boundary is made of three factors, weighted by the business:

Factor	Weight	Today	After phase 1
Protection from untrusted input: what reaches the AI that reads invoices, and in what form	0.5	2	6
Separation of authority: whether the AI that reads invoices can also pay	0.3	1	9
Independent check: what catches a bad invoice before money moves	0.2	4	7
Boundary		1.9, so 2	7.0

Boundary = 2^0.5 × 1^0.3 × 4^0.2 ≈ 1.9 today, and 6^0.5 × 9^0.3 × 7^0.2 ≈ 7.0 after phase 1

Separation of authority scores 1 today because the proposed design would let one AI read an invoice and pay it, so no strength elsewhere can lift Boundary far. That’s why Boundary is a stopping point, and why isolating the reader is the first investment. The other four limits are built the same way, from their own factors.

Plugging In the Numbers

With the limits moving, the correction math shows how far the AI can safely run. One unit of work is one invoice. The AI takes 2 minutes per invoice (s), a human review takes 15 minutes (c), about 2 in 100 invoices would go wrong with nobody watching (λ = 0.02), and payments need 99% trust (τ = 0.99). Reaching 60% of machine speed needs correction of about 0.955; reaching 90% needs about 0.993. The checks that get there:

Check	Catches	Phase
Validation after reading: totals, tax and required fields	60%	1
Three-way match: purchase order, receipt and invoice	70%	1
Duplicate and anomaly detection	65%	1
A second, independent model checks the extracted fields	60%	2
New payees and bank changes verified out of band	55%	2

	Phase 1	Phase 2
Correction (ρ)	0.958	0.992
Invoices between reviews (H)	12	66
Velocity	61% of machine speed	90% of machine speed
People’s share of the time	39%	10%
Capacity freed	About 1.2 of 2 roles (~$60,000 a year)	About 1.8 of 2 roles (~$90,000 a year)
Net of running costs	About $40,000 a year	About $70,000 a year

Phase 1 pays back the build in about 18 months; Phase 2 in under a year. And the checks are the business case: one fraudulent payment can wipe out years of savings.

Future: Some of the road for B2B is unpaved. Many invoices today come through email with no identity. Standards on signed documents with safe read areas. Identity for agents and other factors can increase this velocity further. We can only note this to watch the road ahead. It cant currently add to our calculations, but we do note them down. The potential for 100% automation exists, but that takes many more controls

Going Forward: Architecting What Falls Out

With the current potential, target and binding limits known, the outcomes become the design across people, process and technology. The first limit is not the finish line: each phase changes the constraints, so the system is measured again and a new potential velocity is established.

People

• The Two People Stay. In this example, PACER shows collections is the slowest function: customers pay weeks late and nobody has time to chase them. The two people move there, own the exception queue and the vendor relationships, and keep the 10% review time.
• Their Review Stays Worth Something. HLRF keeps their knowledge of vendors and fraud patterns current, so the 10% they review is still caught by people who understand it. Time is spent learning about fraud patterns, and learning about new techniques thus further reducing risk and enhancing the trust of your partners and customers.
• A Named Approver signs off on payments above the threshold, as the applicable SPEC authorization requirement requires.

Process

• New Payees and Bank Changes are verified out of band, using contact details already on file, with a second approver and a hold before the first payment.
• Three-Way Match happens before anything is paid.
• Thresholds and Throttles: daily and per-vendor payment caps, and anything above the threshold goes to the named approver.
• From 60% to 90%: the business moves to Phase 2 only when monitoring shows Phase 1’s catch rates holding.

Technology: Development

• The AI Reader Returns Fields Only. It has no tools, no network and no authority, so instructions hidden in an invoice have nothing to act on.
• Every Agent Has Its Own Identity and only the tools it needs, for example through MCP. Only the approval workflow can call the payment tool.
• Ordinary Code Checks Every Model’s Output: totals, tax and required fields, so an error stops where it starts.
• A Second, Independent Model checks the extracted fields in Phase 2.

Technology: Security

• Bank Details Can’t Change by Invoice or Email. The vendor record is read-only to every agent.
• The Database: agents write only to a staging area, posting to the ledger goes through approval, and an append-only audit log records who, or what, did each thing.
• Vendor Integrations each get their own identity and pass through the same checks as every other invoice.
• Data With the AI Provider: contract terms on training, retention and region, and only the fields the model needs are sent.

Technology: Infrastructure and Monitoring

• Seeded Test Invoices measure each check’s real catch rate, all the time.
• Alerts on bank-detail changes followed by payments, unusual amounts, and floods of new invoices.
• An Automatic Brake drops back to Phase 1, or to full human review, when a catch rate falls below target

Note: Insider is missing from this example, but would make it longer than this preview is already.

From Numbers to Specifications

Each of those becomes a requirement precise enough to hand to the agents that build, implement and secure the system. For example:

Requirement	New payees and bank-detail changes
Limits	Boundary, Reversibility
Threat	Spoofing: a fraudster poses as a vendor and changes the bank account
Control	Verify out of band using contact details already on file; a second approver; a hold of 5 business days before the first payment
Test	A bank-detail change that arrives by email can’t release a payment within 5 days
Monitor	Alert on any bank-detail change followed by a payment within 30 days

Measure, Move, Reassess

Velocity Engineering is not a one-time calculation that declares a permanent maximum. It establishes potential velocity under current conditions. The business sets the velocity it wants to achieve, informed by PACER and its objectives. Engineering identifies the gap and the interventions that can move the binding limit: better verification, more reversible actions, stronger isolation, improved infrastructure, role-specific training, better models or a redesigned workflow.

Once those changes are implemented, measure again. The road may now support more speed. The models may have improved, the controls may catch more drift, the people may have developed stronger judgment, or the threat environment may have changed. Each can alter potential velocity. The new assessment establishes the next operating envelope and the next set of investments. The goal is to keep moving the measured limit toward the velocity the business needs, without crossing the trust boundary.

Coming Soon

The full paper will develop these principles further: why correction needs several independent checks, the security corollary (an attacker who can poison what a system learns from turns correction against you), where to invest, and how to choose code, machine learning or generative AI for the work. Talk to us about putting numbers on your own processes.

Thanks for reading.

Jay Titus
Left Hand Security

© 2026 Left Hand Security · CC BY-ND 4.0 · lefthandsecurity.com/papers/velocity-architecture