VDD Methodology Specification v 1.0
The normative rules of VDD: how work is counted in Delivery Bricks, how every Unit is verified, how a Brick is priced, how delivery dates are forecast, and how changes are re-priced. This page is an overview. The full Specification, with every definition, counting rule, formula, and example can be downloaded from our web site.
Author: Alexander Lipanov · Owner and steward: Sofycod Sp. z o.o. · License CC BY-NC-ND 4.0, with additional permissions
«Cite as»: Lipanov, A. (2026). Verification-Driven Delivery (VDD) Methodology (Version 1.0). Sofycod Sp. z o.o. https://doi.org/10.5281/zenodo.23415761
Four questions, one set of numbers
What
What will be built: a set of Delivery Bricks.
How much
Bricks × a Price per Brick calibrated on your own history.
When
A P50 and P85 range, recalculated from actual throughput.
Accepted how
Verification occurs through the Independent Verification Gate, either via peer verification or by a dedicated Verification Engineer. No one confirms their own work.
VDD replaces the units of estimation and price, not your delivery process: it is used alongside Scrum, Kanban or a phased process, and applies equally to code written by people and generated by AI.
VDD Manifesto
"We value verified units of work over billed hours."
A Delivery Unit is priced by what it is made of and how it was verified, not by how long someone sat typing.
"We value expert judgment and knowledge more than the speed of code generation."
Every Unit passes through an Independent Verification Gate: an engineer who did not write the code must confirm it before it counts as delivered.
"We value a price that reflects quality, complexity, and reliability over code volume or hours spent."
Delivery Bricks carry complexity modifiers tied to real architecture and business risks.
"We value a transparent, explainable basis for price over arbitrary estimates."
Pricing is calibrated directly from the organization's verified delivery history.
"We value decisions grounded in statistical data over subjective intuition."
Timelines are probability ranges, not promises: P50 and P85 forecasts are recalculated after every sprint using actual team throughput.
Glossary
Delivery Brick
Minimal, objectively countable unit of engineering work. Not a unit of time or AI compute. The count doesn't change based on how long something took.
Delivery Unit
A complete, fully working, independently verified user story. 1 Unit = the sum of its Bricks, from code to testing.
Independent Verification Gate
Mandatory step where someone who did not build a Unit confirms it from scratch before it counts as delivered.
Base Unit Rate
The monetary value of one Brick in a given category, calibrated from the organization's own historical revenue. Not a specialist's hourly wage.
Customer Risk Multiplier
Documented coefficient applied only to the guaranteed P85 date (never P50), reflecting history with a specific client.
Brick Categories
1 base + 1/JOIN + 1/complex clause
1 base + 1/downstream call + 1 idempotency
1 base + 1/state + 1 realtime + 1 custom design
1 per conditional branch / calc rule
1 base + 1/API call + 1 webhook
1 base + 1/guardrail + Data & Edge modifiers
1 per scenario / edge case
1 base + 1 examples + 1 multi-language
1 base + 1/source + 1 rollback + 1 validation
1 per infra action, once per project
1 base + 1/protocol state + 1 real-time
1 base + 1/manual alloc-dealloc + 1/raw pointer use + 1/platform optimization + 1 freestanding
Open research whose units of work are unknown in advance is not counted in Bricks. It is a time-boxed Research Spike.
How price and dates are set
Price per category
Each category has its own Base Unit Rate, calibrated on revenue from your verified deliveries and weighted by its Independent Verification Effort. Never an hourly rate.
P50 and P85
The median and the 85th-percentile throughput of completed sprints. Both dates are always reported and recalculated every sprint.
Re-Bricking
A requirement change recounts only what changed, so both sides see the delta in Bricks, price and dates before agreeing.
When an organization applies VDD
Work is counted in Delivery Bricks by the twelve categories, or documented internal extensions of them.
Every Delivery Unit passes the Independent Verification Gate.
Bricks are priced per category from rates calibrated on the organization's own history, or marked preliminary.
Delivery dates are reported as P50 and P85 and recalculated from actual throughput.
VDD can be applied entirely by hand, with spreadsheets. No tool is required.
The full Specification defines every term used in VDD and sets out the counting rules and complexity modifiers for all twelve Brick categories, including the Data & Edge modifiers for AI and computer-vision work. It specifies the Independent Verification Gate, the pricing model with the formulas for the Base Unit Rate, Independent Verification Effort, complexity coefficients, and the Price per Brick, and the forecasting model with P50, P85, and the Customer Risk Multiplier. It also gives the Re-Bricking procedure for requirement changes, the four requirements for applying VDD, worked examples, and the historical background of the methodology. The Specification is sent to your inbox together with the Implementation Playbook, the spreadsheet templates and the presentation.