The design loads and timing looks clean. Why can the inputs still be wrong?

Short Answer

"It loaded" and "timing looks clean" are both weaker claims than they sound — loading only proves the tool accepted the data syntactically, and clean timing only proves the paths that were analyzed passed. Neither proves the files represent the chip you actually intend to build, and neither proves every case that needs checking was actually checked. Missing coverage is the most common trap: a missing generated clock means whole downstream paths never receive the clock-based checks they need — they just silently don't show up as violations because they were never analyzed at all. Similarly, an inactive slow-corner scenario can hide the exact violation that scenario would have caught.

Technical Explanation

• "It loaded" and "timing looks clean" are both weaker claims than they sound — loading only proves the tool accepted the data syntactically, and clean timing only proves the paths that were analyzed passed. Neither proves the files represent the chip you actually intend to build, and neither proves every case that needs checking was actually checked.
• Missing coverage is the most common trap: a missing generated clock means whole downstream paths never receive the clock-based checks they need — they just silently don't show up as violations because they were never analyzed at all. Similarly, an inactive slow-corner scenario can hide the exact violation that scenario would have caught.
• Constraint mistakes look identical to "clean": an overly broad false path can quietly remove a genuinely difficult interface from analysis (see the case-analysis and false-path questions above), and case-analysis applied at the wrong hierarchy scope can fail to protect a shutdown boundary the way it was meant to.
• Data mistakes are just as dangerous and just as invisible in a summary report: a nominal-corner library accidentally substituted for the slow-corner model produces plausible-looking, optimistically-wrong timing; an old/stale macro abstract gives wrong pin geometry; a mismatched DEF leaves important objects unannotated (no location, so no accurate parasitics).
• The fix is never "trust the summary badge" — it's targeted verification: compare what you expected against what actually loaded (design counts, which clocks got created, which interfaces got constrained, which analysis types/corners are active, which library/model got selected, whether RC got assigned, whether macro geometry is current, whether power-intent checks passed), spot-check a handful of real critical paths to see the actual cells/edges/parasitics involved, and reconcile any unexplained change against the last known-good handoff before you start optimizing against these numbers.

Follow-up Question & Model Response

"What is the strongest readiness evidence?"

Candidate Model Response: A consistent package plus reproducible reports showing that the intended objects, conditions, and checks are present.