The sign-off checklist a board owes you

What a sign-off checklist is for

A sign-off checklist is the list of things a delivered design owes its owner before the owner agrees the work is done. On a PCI Express board it is the difference between a board that was demonstrated and a board that was assumed: link status read back, widths and rates confirmed, power measured, errors counted. This page is about the list itself, not any one item on it.

The checklist exists because acceptance is a boundary. Before the boundary, problems belong to whoever built the thing; after it, they belong to whoever accepted it. The list is what makes the boundary real: it converts a delivery from a claim into a set of demonstrations, each of which either passed or did not. A sign-off without the list is a signature on confidence, and confidence is not a deliverable.

The pattern is older than hardware and identical elsewhere. The Serbian desk that publishes a website handover checklist teaches small businesses to accept a delivered site only after a defined list has been walked: ownership of the domain, access to the files, the quality pass before publication. A board sign-off is the same instrument pointed at copper: nothing is accepted on the strength of the invoice.

What does a board owe its owner?

Demonstrations, in a fixed order. The link comes up and reports its negotiated speed and width, readable through lspci or the platform's equivalent, and the reported values match the design intent rather than the silkscreen. The enumeration completes and every function expected appears in configuration space. The power drawn at idle and under load sits inside the slot's budget. The error counters stay quiet under the traffic the board was built for. And the paperwork arrives with the board: the schematic revision, the compliance evidence, the known issues.

Each item on that list is a page elsewhere on this desk. The status fields are described in enumeration and configuration space, the widths in what every lane carries, and the measured margins in reading a receiver eye. The checklist is the spine those pages hang on.

How is a checklist different from a test?

A test asks a question about the device; a checklist asks whether every question was asked. The two are complementary and easily confused. A board can pass every test on the list and still fail acceptance if the list was incomplete, and a board can fail one item and be correctly rejected even if every other figure was exemplary. The checklist is therefore a document about coverage, and its failure mode is silence: the item nobody wrote down is the defect nobody looked for.

Why do checklists fail?

Two ways, both old. The first is the checklist that was never walked: the document exists, the signature exists, and the items in between were assumed. The second is the checklist that cannot fail: every item so vague that any outcome satisfies it, which converts the instrument into ceremony. The checklist that works is specific enough to fail and short enough to finish, and the discipline of writing one is described plainly in the checklist literature, read on September 6, 2026: the list exists to catch the step that memory skips under pressure, which is why it is written before the pressure arrives.

The verification framing underneath it all is set out in the verification and validation article, read the same day: acceptance is not trust but demonstration, and the checklist is the demonstration made enumerable.

The sign-off checklist is the cheapest instrument on the bench and the one most often skipped, because it tests the process rather than the part. A board that cannot survive the list was never going to survive the field; the list just says so earlier.

A sign off checklist closes the work on the bench, yet the evidence behind each ticked box outlives the session. A compliance run produces its own record: ordered event traces, error counters, equalization results, and the captures taken at each rate the link negotiated. That record is what a later reader consults when a failure reappears or a revision changes the expected behaviour. The newer page on logs and captures covers how those artefacts are organised, dated, and read against the public specifications.