Verification : code does what the specs say Validation : Customer confirms it meets the intent of the ask

> where with formal verification, the specifications are lower-level, so validation is extra-important.

Specifications don't need to be lower-level. They also compose nicely. Ie you can figure out how to formally specify a 'this doesn't crash' requirement once, and then re-use it on all your projects.

There's, unfortunately, another meaning for "validation" that's used in the adjacent context. All those form fields are validated, the tool that validates them is called, unsurprisingly, "validator"... To generalize this notion: "validation" can also mean compliance with an arbitrary set of rules, not necessarily the rules imposed by the product design.

I.e. a field in a government form for residence permit might validate if the date entered is between the applicant's arrival date and three months later. And screw the applicant who wanted to apply for the permit before they landed in the country (this is a not invented example).

Also, since I worked in "software validation", I feel like it's important to note that the dictionary definition is different from practice. For the most part, the task of validation is the one that should culminate in the testers OK'ing the shipment of the product. Typically, testers, as well as the rest of the company involved in the shipping, are painfully aware that the product doesn't meet the customer's requirements (or any formal or informal requirements). It is simply declared "valid" because the potential damage is assessed to be manageable. I.e. a product may as well be declared "valid" while having a list of "known defects".