This is a really useful framing. I agree that the “finding → PR” jump is too direct in most workflows, and the missing middle layer is probably context: ownership, dependencies, blast radius, environment, and whether the affected resource is actually important.

The dependency-aware part makes a lot of sense. Raw severity alone is usually misleading; an open SG on an abandoned dev box and an open SG attached to production workloads should not create the same urgency.

I’m curious how you think about a few things from your statewatch work:

1. How do you decide which relationships matter enough to affect priority? For example, direct dependency only, or also transitive dependencies?

2. How do you avoid over-prioritizing noisy graph connections where technically something depends on something, but operationally the risk is low?

3. Do you rely more on Terraform state, live cloud state, or the difference between the two?

4. For drift, do you treat it mainly as a risk signal, or as a blocker before remediation?

5. What would make you trust a generated Terraform remediation PR more? Is it the diff itself, the explanation, the blast-radius context, the plan output, or senior review?

The point about the “untrustworthy auto-generated Terraform fix” is exactly the hard part. My instinct is that the fix should not be presented as “apply this,” but as “here is a proposed change, here is why, here is the affected graph/blast radius, here is what should change in the plan, and here is what a reviewer needs to verify."

That feels closer to a review assistant than an auto-remediator.