Lesson 0.5 began the course with a claim: verification gives confidence, not proof. Fourteen parts later the claim becomes a decision. DCRouter's testbench catches all 24 planted bugs, its control logic is proved for every input, its coverage holes are named and its plan has evidence against almost every feature. None of that proves it has no bugs. Someone must still say: this is good enough to commit to silicon.
What does sign-off mean?
The obvious meaning is "verification is complete; the design is correct". No method in this course can establish that: simulation samples, coverage measures exercise, formal proves only stated properties, and planted bugs are the ones someone thought of. A sign-off that claims correctness is either dishonest or uninformed. A sign-off that states residual risk is useful.
Sign-off is | Sign-off is not |
|---|---|
A decision that remaining risk is acceptable | A proof of correctness |
Based on evidence against an agreed plan and criteria (lesson 14.2) | Based on one metric reaching 100% |
Made by named people who own the consequences | A tool report or a dashboard turning green |
Explicit about what is not verified (lesson 14.4) | Silent about gaps |
Weighed against the cost of waiting and the cost of an escape (lesson 12.1) | Free of commercial context |
Evidence per feature against the plan: checks, coverage, proofs and their results (lesson 9.8).
Trends: the bug discovery curve, coverage closure, failure rates, with effort beside them (Part 12).
Open items: open bugs by triaged severity, coverage holes by cause, waivers (lesson 14.3).
Independent views: reviews by people who did not build the testbench.
Consequences: what an escape would cost for this product, and what a week's delay costs.
Role | Signs that |
|---|---|
Verification lead | The evidence is as stated, and the gaps listed are all the gaps known |
Design lead | Design intent matches the verified behaviour; known design risks are listed |
Architecture or system owner | The specification verified is the one the product needs |
Software lead | Hardware-software contracts were exercised (lesson 8.6) |
Project or programme owner | The residual risk is accepted on behalf of the business |
Practice | Purpose |
|---|---|
Sign-off criteria agreed at planning, not at the end | Evidence gathered against known targets |
A formal review with recorded decisions (lesson 14.5) | Accountability and memory |
Residual risk written down and carried to silicon validation | Post-silicon effort aimed at the known gaps (lesson 11.2) |
A team (illustrative) signed off with a dashboard: all regressions passing, coverage at 100% after exclusions, no open critical bugs. Nobody signed for what the exclusions contained, and nobody listed the features without evidence. An excluded bin covered a low-power mode a major customer used; the first silicon bug report came from that customer. A sign-off that named its gaps would have sent that mode to silicon validation's first week.
The Bug Zoo is 24 bugs someone thought of; it says nothing about features without planted bugs, which only the plan and its evidence show.
That the evidence is as stated and the listed gaps are all the gaps known; not that the design is correct.
Sign-off is a decision that residual risk is acceptable, not a proof of correctness.
It rests on evidence against the plan, trends, open items, reviews and consequences.
Named people sign, and the sign-off states what was not verified.