To motivate some of the machinery, you know systemically it's kind of a no-brainer for how financing and oversight works I suppose; overseers want to see early results which you might get from a knowledge worker rehashing or tweaking an existing solution, and then integrators get to play 'pick up sticks'.
So you have the integrator is the "buyer" because they have opted to defer product expertise (disregarding whether there's even any real cost, i.e., a FOSS solution, etc. "buy" meaning "not build").
The buy side has popular tools like linters, static analyzers; this is pretty huge. If you look at the "cloud native" space, treating lots of the cloud software players as "integrators" of software that's intended to be distributed, public, always-on, and at a cost of 'ad-supported' the buy side has the "Security and Compliance" layer: https://landscape.cncf.io/ ... a lot of money is flowing there too, since it simplifies precisely what you mention there, so you're in good company. Granted, "integrator work" might be a bit less specialized than the sorts analyses these tools might perform, but it's the same problem applied instead of abstractly "domain expertise" to "domain expertise of deploying existing software solutions."
It might not be popular thinking, but doc tools like CodeViz, doxygen, any worthwhile IDE, and other tools in the space are probably somewhere between the next space:
OTOH managers are sort of 'friendly buyers' for the expertise of their employees, so you can look at the tools of requirements elicitation, definition, capture, scheduling, prioritizing, and lifecycle management too, thinking specifically of like stories, epics, kanban, and presumably legacy systems like DOORS, which I don't have any experience with. If you want to avoid too much philosophizing and want to defer to some pretty broad experience SWEBOK has a lot of words about this more 'pre-compiled' approach rather than 'just-in-time' approach that most agile-type firms will use for their usually simple value props.
The same sorts of things might apply though; identifying whether "coverage exists" for "domain-expert produced prototypes" -- specifying the form of those, in say what you mention, signal processing. Basically, TDD -- does the shipped code match the tests? Does the integrator know enough to write such tests?
Essentially using 3rd party machinery to establish acceptance criteria, and clear targets to ensure that the "buyer-builder" contract is fulfilled.