You mean the guaranteed-to-fail-but-spreads-blame method that I mentioned is common and closely related to your proposed method which shares those traits? Because that's neither “my way” nor something I recommend as an alternative.

> The problem with your method is that two separate companies have deliverables that must be correct,

No, only the final delivery company’s one must be correct. The preceding one influences the likelihood of that, of course, just like the extra domain-expert contractor brought in to validate the requirements in your proposal. (Who, if the agency for which work is being done is bringing them is as a requirement “validation” expert because it assessed that it can't do that, is effectively defining the actual requirements, even if nominally they are just validating the other firms work on behalf of the customer.

> It's fundamentally impossible (absolutely, 100%) to write specs for a complex product before the product work begins.

Yes, you seem to understand a key part of the basic problem, but then describe a rearranging-deck-chairs-on-the-Titanic solution that does nothing to address it.

> And my way removes the back-and-forth which is a huge source of errors.

No, it just changed to nominal role (but not really the functional role) of one of the three (customer, requirements crafter/validator, developer) parties to the back and forth.

My way is to recognize that if you are going to build and operate a complex IT-dependent business function, a prerequisite step to success is to own the IT capacity to govern the necessary system components, including their incremental development and adaptation to evolving business needs. And closely related to that is arrange the work into increments that (among other criteria) can be plausibly specced in advance but also where the setback isn't intolerable when an increment’s main output is information about where your understanding going into it was wrong.