--- title: "Design Verification: Demonstrating Not That the Product Works, but Why It Works" description: "Design verification is the record chain linking a defined requirement to the method that tested it and to the revision the result was bound to. Reviewers look not for proof that the product works, but for proof that why it works can be shown without the designer in the room. Where that chain is absent, price adjusts through warranty provisions, indemnity scope, and earn-out structure." url: https://www.beirek.com/en/blog/design-verification-process-due-diligence canonical: https://www.beirek.com/en/blog/design-verification-process-due-diligence published: 2026-07-11 modified: 2026-07-11 category: "Technology & Engineering" category_url: https://www.beirek.com/en/blog/category/technology-engineering language: en-US reading_time_minutes: 8 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["design verification","technical due diligence","engineering documentation","valuation discount","quality of earnings","traceability matrix"] topics: ["Design verification and validation","Technical due diligence","Engineering governance and design authority"] alternate_language_url: https://www.beirek.com/tr/blog/design-verification-process-due-diligence --- # Design Verification: Demonstrating Not That the Product Works, but Why It Works > **In short:** Design verification is the record chain linking a defined requirement to the method that tested it and to the revision the result was bound to. Reviewers look not for proof that the product works, but for proof that why it works can be shown without the designer in the room. Where that chain is absent, price adjusts through warranty provisions, indemnity scope, and earn-out structure. *In a technical due diligence, design verification is examined not as evidence of field performance but as evidence that such performance can be reproduced institutionally. Where the verification record lives in an individual's judgment rather than in a traceable chain, the consequence reaches valuation through quality-of-earnings adjustments, representation and warranty scope, and earn-out architecture.* --- In a technical due diligence session, the question posed by the review team is rarely how the product works. More often it is a request to select, at random, one of the design changes released to serial production over the preceding twelve months, and to demonstrate which requirement that change was made to satisfy, by what method it was verified, and to which revision number the verification result was bound. Two categories of document typically surface in the room: drawings and test reports. The connective tissue between them — the customer specification or standard clause from which the requirement originated, whether the test was executed to satisfy that requirement or performed on some adjacent occasion, and the date and authority under which the result was accepted — is generally supplied verbally by the engineer at the table. The explanation is technically sound, frequently deeper than the reviewer's own understanding of the product; it is not, however, a record, and at the review table nothing that is not recorded is treated as verifiable. What makes this pattern worth examining is that it appears not only in companies with thin engineering benches, but equally in companies with low field failure rates, high customer retention, and settled technical reputations. In such companies the design quality is genuinely high; the source of that quality, however, is judgment accumulated over years by two or three individuals, and that judgment has never been externalized anywhere. The company presents field performance data as proof of design discipline. The reviewer reads the same data as proof of a past outcome, not as proof of future reproducibility. The distance between those two readings is the axis on which the entire valuation discussion will turn. The underlying mechanism is straightforward and should be understood as a cost preference rather than a defect. Design verification is, in essence, a closed loop: a requirement is defined, a design output is produced, that output is tested against the requirement by a method fixed in advance, the result is recorded, and the record is bound to a specific version of the design. While the team is small, the product family narrow, and the person carrying the requirement in their head the same person producing the design, the marginal benefit of committing this loop to writing is low; verification collapses into the designer's judgment at the moment they inspect their own output, and that collapse is, in the short run, both faster and cheaper. The shortcut is rational on its own terms. The difficulty arises when conditions change — variant count rises, a new market is entered, a critical supplier is swapped, the team grows — and the shortcut nonetheless persists unchanged. Persistence produces two characteristic deformations. The first is the erosion of the boundary between verification and validation: verification asks whether the design output satisfies the design input, while validation asks whether the product performs its intended function in intended use. Once the two are merged, the company begins testing the finished product and reasoning backward, leaving it unclear which individual requirements were actually exercised. The second is the silent change threshold. Design changes below some magnitude pass without a record being opened, yet where that magnitude lies is written nowhere; it lives in habit. Over time a quietly widening gap opens between the product being manufactured and the product described by the technical file, and that gap typically surfaces during a customer audit or the root cause analysis following a field failure. On the documentation dimension, what reviewers usually encounter is not an absence of documents but an absence of linkage. Test reports exist, yet reference no requirement identifier; approval signatures exist, yet the source of the signer's authority is undefined; which version is current is inferred from a date embedded in a filename. On the measurement dimension, most companies keep no indicators at all. First-pass verification rate, the count of design changes opened after release to serial production, verification cycle time, and the per-unit cost of defects escaping to the field are foundational engineering management metrics, yet they remain invisible where they are not separated from the quality department's product metrics. Regarding a process that is not measured, the only judgment a reviewer can reasonably form is that the process is being executed rather than managed. The first channel through which this gap reaches valuation is not the multiple but the quality-of-earnings analysis. When the review team isolates warranty provisions, rework and scrap cost, field intervention expense, and customer concessions from within cost of sales and normalizes them, the amplitude of variation in these items rises markedly in companies with weak verification discipline. That variation is priced not as an average but as a loss of predictability; what is actually under discussion in a quality-of-earnings debate is less the magnitude of the number than whether its recurrence in future periods can be demonstrated. A company with an established verification chain can answer that question with process. A company without one can answer only with a historical average, and a historical average is invariably read conservatively on the buy side. The second channel is contractual architecture. Where a business carries product liability and the verification records are thin, buy-side counsel tend to compensate not in price but in the protection layer: representation and warranty scope broadens under product conformity and certification headings, indemnity caps rise, escrow percentage and duration increase, and an independent technical file review appears among the conditions precedent to closing. The combined effect of these adjustments is to preserve the headline price while reducing the present value of cash actually reaching the seller. The same logic sharpens considerably in markets whose access depends on CE marking or product safety certification, since the verification record standing behind the technical file is a more critical asset than the certificate itself, and it is that record which determines the certificate's continuity at the moment of renewal or audit. The third channel opens where the ownership and continuity dimensions intersect, and it is usually the most expensive. Where the verification decision right is undefined, design authority has in practice concentrated in the founding engineer or a single senior individual, and in that configuration the reviewer stops asking about the quality of the existing product range and begins asking whether the next product can be produced to the same discipline. Absent an institutional answer, the transaction structure moves predictably toward binding that individual: earn-out triggers are tied to technical milestones, key-person commitments lengthen, non-compete periods widen. Value discussed through a revenue multiple thereby converts into a payment schedule indexed to one person's commitment to remain — a conversion the sell side frequently registers only after the valuation discussion has closed. The intervention that neutralizes this tendency is built through system design rather than individual attentiveness, and it separates in practice into five components. The first is a requirements register in which every requirement carries an identifier and a source, so that conditions arriving from customer specifications, standard clauses, or internal performance targets are all tracked in a single ledger. The second is a verification matrix binding requirement to method, method to evidence, and evidence to design revision — a living record under version control rather than a report. The third is written classification thresholds for change, with approval authority for each class defined by role rather than by name. The fourth is design review gates with entry and exit criteria fixed in advance. The fifth is an indicator set that measures verification itself: first-pass rate, post-release change count, verification cycle time, and the unit cost of escaping defects. BEIREK's intervention in this area is not the drafting of a quality manual but the placement of the verification record inside the engineering rhythm. In practice the design review gates are bound to the calendar, and at each gate the evidence of requirement satisfaction is read off the matrix rather than described; the verifying role is separated from the designing role at least at the signature level, and that separation is written into the approval authority table rather than the organization chart. Who may close a change entry at which threshold is committed to writing, and a pre-mortem session is run before any design freeze decision, with the output of that session taking the form of concrete test items added to the verification plan rather than a risk list. The test of the structure built is not internal audit; it is whether a third party can trace a randomly selected revision end to end. In a transaction preparation context, scope is deliberately narrowed. The review team does not sweep the entire catalogue; it samples from the products carrying the weighted portion of revenue and tests the chain through that sample. Retrospective reconstruction work is therefore concentrated in the product families generating the determinative share of revenue and in the variants subject to certification, while for the remainder of the range what is demonstrated is that forward-looking discipline has been established and dated. This distinction keeps preparation cost within a defensible band and renders the surface most heavily interrogated at the review table capable of withstanding scrutiny. What is ultimately at issue in a technical review is not whether the product is good; that is usually evident from the field already. What is at issue is whether the reason it is good can be demonstrated with the person who designed it absent from the room — and the answer to whether a company's engineering value rests on institutional capacity or on individual talent is contained in the presence or absence of the verification record. ## Key Points - Verification is measured not by how well the product performs in the field, but by whether the traceable link between requirement and evidence has been committed to a record. - A designer verifying their own output is a rational cost-reducing shortcut in a small team; the difficulty arises when that shortcut persists as variant count, market scope, and headcount expand. - Change classification without written thresholds accumulates unrecorded revisions and lets the technical file drift behind the product actually being manufactured. - A verification gap enters valuation before it touches the multiple, arriving through warranty provisions, rework cost normalization, and escrow sizing. - The continuity question reduces to a single sentence: can the next product be verified to the same discipline without the current design authority present. ## Questions ### What is the difference between design verification and design validation? Verification asks whether the design output satisfies the defined design input; its measure is the specification. Validation asks whether the product performs its function under intended conditions of use; its measure is user need. Where the two are merged, the company tests only the finished product and reasons backward, leaving it unclear which individual requirements were actually evidenced. At the review table, that ambiguity is read as the absence of a verification system altogether. ### What exactly does an investor examine regarding design verification in technical due diligence? The typical method is sampling: a recent design change on a product carrying the weighted share of revenue is selected, and the chain is traced end to end. The reviewer looks for the requirement's source, the verification method, the evidence document, the approval authority, and the revision to which the result was bound. Where any link is closed by verbal explanation, the process is treated as absent; the volume of documents is not determinative, the linkage between them is. ### How does weak design verification reduce a company's valuation? The effect generally enters through three channels before touching the multiple. In quality-of-earnings analysis, warranty provisions, rework, and field intervention expense are normalized, and variation is priced as a loss of predictability. On the contractual side, product conformity representations broaden and escrow percentage and duration rise. Third, where design authority sits with one individual, earn-out triggers and key-person commitments engage; the headline price may hold while the present value of cash received declines. ### Does a small engineering team need to build a heavy verification system? What is required is traceability rather than weight. In a small team, collapsing verification into the designer's judgment is a defensible preference to the extent it reduces cost; the difficulty is that preference remaining fixed as variant count rises, a new market is entered, or a critical supplier changes. The workable minimum is a requirements register, a requirement-method-evidence-revision matrix, and written change thresholds — three elements sustainable at the scale of a handful of engineers. --- Source: https://www.beirek.com/en/blog/design-verification-process-due-diligence Publisher: BEIREK LLC — https://www.beirek.com