What exactly is a Delivery Brick, and why not just measure in hours or lines of code?

A Delivery Brick is an atomic, objectively countable unit of engineering work — one CRUD operation, one API endpoint, one UI component, and so on, across 12 defined categories. It is never a unit of time or AI compute. Hours and AI-call volume both create a Goodhart's Law problem: if either becomes the basis of price, there's a direct incentive to inflate it. Counting objective engineering artifacts removes that incentive — the Brick count doesn't change based on how long something took or how many AI calls it required to produce.

If Brick price differs by category, how is a Delivery Unit's final price actually calculated?

A Delivery Unit's price is the sum of its component Bricks' prices across all applicable categories. Each of the 12 categories has its own Base Unit Rate, calibrated separately, because a Brick in the AI/CV/ML category and a Brick in the CRUD/Data category require different expertise and a different depth of verification — pricing them identically would either undervalue rarer expertise or overprice routine work. A Unit combining, say, 8 CRUD Bricks and 3 AI/CV Bricks is priced as (8 × CRUD rate) + (3 × AI/CV rate), not as 11 Bricks at one blended rate.

How does VDD handle a Customer changing requirements mid-project?

Through Re-Bricking. Any requirement change is recorded as a change to the project's Brick list; when the list lives in Git, it appears as a diff to the project's vdd-spec.yaml file, reviewed like any other code change. Before anyone approves it, both sides see the delta: the change in Bricks and Units, the recalculated P50/P85 dates, and the shift in Independent Verification Effort. A change request becomes a visible number both sides see at the same time, not a separate negotiation.

Why does VDD give a date range instead of a single delivery date?

Because a single date is a point estimate for what is really a probability distribution, and it is almost guaranteed to be wrong in one direction or the other. VDD records the team's weekly Brick throughput. P50 divides the remaining Bricks by the median weekly throughput; P85 divides them by the throughput the team reaches or exceeds in 85% of weeks, which leaves margin for sick days, underestimated Bricks and the blockers that reliably happen on real projects. Both dates are shown together, for example “P50: March 3, P85: March 17”.

What is the Customer Risk Multiplier, and does it affect the P50 date too?

It's an explicit, documented multiplier applied only to the P85 (guaranteed) date, derived from tracked historical metrics for that specific Customer - how often requirements changed after sign-off, how far actual delivery deviated from the promised P85 on past projects, and how quickly the Customer responded to requests. For a new Customer with no history, the multiplier is 1.0 (no adjustment); it's only introduced starting from a second project with the same Customer, never estimated on a gut feeling during negotiation. It is never applied to P50 — P50 stays a statistically honest measure of team throughput, uninfluenced by which Customer is asking.

How is the price of a single Brick actually determined, is it based on an engineer's hourly rate?

No. Base Unit Rate per category is calculated as: total historical revenue from completed, independently verified Units of that category, divided by the total Weighted Bricks delivered in that category over the same period. It answers "what does the market actually pay this organization for this type of verified result," not "what does an hour of a specific person's time cost." The same Brick closed by one engineer in 3 hours and by another in 8 hours is priced identically, because the verified result and the guarantee behind it are identical. Pricing by individual speed would mean the same outcome costs the Customer differently depending on who did the work, which directly contradicts the Manifesto: the Customer pays for the result, not the method used to reach it.

What happens to open-ended research work like evaluating which computer-vision approach to use or which AI models, datasets fit best for particular project? Did that can't be decomposed into Bricks upfront?

That work goes through a Research Spike instead of Brick estimation: a fixed, time-boxed allocation, the same mechanism Scrum already uses for exactly this situation. Pretending open research decomposes into atomic units before the research happens would be dishonest, not just imprecise — the units themselves are what's unknown until the spike concludes. Once a specific approach is chosen, its actual implementation (feature engineering, training pipeline, inference endpoint, validation) is decomposed into Bricks normally under Category 6 and related categories; only the "what will even work" phase sits outside the Brick method.

Does VDD only apply to AI-assisted development, or does it work for traditional coding too?

The methodology is agnostic to how the code was produced. Bricks count finished, verifiable engineering artifacts: a CRUD operation, an endpoint, a UI component regardless of whether a human typed every character or an AI generated most of it. What VDD is actually built to price is the verification and judgment layer around that artifact, which doesn't shrink just because code generation got faster. A team using no AI tools at all can apply VDD exactly the same way; the method doesn't reference or depend on AI usage anywhere in its counting rules.

How much historical data does an organization need before it can calibrate its own Base Unit Rate?

The Implementation Playbook sets a practical threshold: 15–20 completed projects with recorded user stories, 100+ stories total, and matching revenue/margin data per project. Below that, calibration is still possible but must be explicitly labeled as provisional, subject to revision after the first 5–8 independently verified Units delivered per category under the new rates and this is the same principle the Playbook applies to complexity modifiers generally, not a one-time exception.

Why is independent verification mandatory rather than optional, and who can perform it?

Because self-review has a structural blind spot: the person who built something cannot reliably see their own mistakes in it. The Independent Verification Gate requires someone who did not implement the Unit to review and confirm it from a fresh read before it counts as delivered — this applies whether the implementation came from a human engineer or an AI agent; a result generated by a single source, human or AI, is never considered final until an independent party confirms it. This is a direct descendant of Wideband Delphi's requirement for independent consensus rather than a single expert's unchecked judgment, applied to today's human+AI pairing instead of a panel of human experts.

Does VDD replace Scrum or an agentic delivery framework?

No. Those frameworks organize the team: roles, cadence, and ceremonies. VDD defines the unit of delivery, its price, its acceptance, and its forecast. You can apply VDD inside Scrum, Kanban, or an agentic SDLC; the counting and verification rules stay the same. VDD vs agentic delivery frameworks →

How is VDD different from Function Points?

Function Points measure functional size from the user's perspective, and VDD learns from that lineage. VDD counts engineering artifacts, including the test cases that verify them, prices each category based on the organization's delivery history, and requires independent verification before a Unit counts as delivered. VDD vs Function Points →

Can I use VDD commercially?

Yes, within your organization, including pricing and delivering software to your own Customers, free and without registration. Selling VDD itself (training, consulting, audits, certification, tools, or translations) requires a written agreement with Sofycod. See the Licensing & IP Policy.

Can I translate VDD?

For internal use only, yes. Publishing a translation needs Sofycod's prior written consent and the credit line from the license. We want VDD available in many languages, so write to us.