link to Seigo: https://seigo.ai

Caveat: I've not used this for your particular problem, but there is a category of software tools that aims to solve this in general.

Requirements management systems. DOORS [0] is one I had extensive experience with at one point in my career. I'm not specifically endorsing it, there are more examples here [1], but I will write about it from my perspective having used DOORS. They particularly addressed this from your question:

> When something changes, there’s rarely a clean way to know what’s now invalidated, what needs re-review / re-test, and what’s actually ready at a program level

In our context it was being used for safety critical systems, I used it for the software side but they also used it for hardware. You created multiple documents (in our case requirements, spec, design, test procedures). Each one was really a table in a DB that could be pretty printed as nice looking PDFs. Each entry was something like (probably entirely wrong format, but this is the kind of information presented):

  R1234 Fire suppression system must automatically discharge after power failure. [Linked from: S123, ...]

  S0123 30 seconds after detecting a power failure [mechanism described elsewhere], the fire suppression system will automatically discharge. [Ref: R1234, Linked from: D0983, D1234, ...]

  D0983 Whatever text describes this part of the spec, maybe this is where detecting power failure is described [Ref: S0123, ...]

  T0013 Procedure which triggers power failure and observes correct behavior (for a passing test) [Ref: D0983, ...]

DOORS would fill in all the transitive references. So the test may not have to directly refer to the requirement, or perhaps it only refers to the requirement and not the design document. But you could query the system and see which entries link in some fashion to T0013. Now when someone comes in and edits S0123 to change it to a 60 second delay, everything linked from S0123 can be marked as needing review. That includes the requirement (which was written more generically in this case) and down to the test procedures meant to verify the requirement or spec or design entry. The test itself is actually many entries (each step was an entry the way we did it) and so that change might only invalidate 2-3 procedure steps so it helps narrow down what needs to be reviewed.

It also could be used to generate reports of what had or had not been connected to a lower level item. If you have that requirement above and it doesn't trace to a spec, design, and test entry then you have a problem. If it's implemented you forgot to describe that fact and demonstrate it, or it was never implemented and no test shows that it's happening one way or the other.

The downside to DOORS is that (at least when I was using it or the way we used it) it couldn't really encode logic beyond that linking. There are other systems like Event-B which can be used to help with formalizing a design and ensuring that the requirements are logically consistent. DOORS did not stop you from having two entries that gave contradictory specifications on its own.

[0] https://en.wikipedia.org/wiki/DOORS

[1] https://en.wikipedia.org/wiki/Requirements_engineering_tools...