Every compliance program has a shelf of documents: policies, control descriptions, procedures, each describing how the organization intends to behave. The documents are necessary. They are also not where compliance actually succeeds or fails.
The policy-reality gap
The access-control policy says least privilege. The encryption policy says data in transit is protected. The retention policy says personal data is deleted after its purpose ends. These are true statements about intent.
Whether they are true statements about your system depends entirely on the code: the IAM policy that actually shipped, the TLS floor the service actually enforces, the deletion job that actually runs. The gap between the document and the deployment is exactly where audits find their findings, and it opens up one ordinary pull request at a time.
The diff is where the control changes state
A control does not silently degrade. Something changes it: a role is widened, an encryption setting is dropped, a retention bound is removed. Each of those is a diff, authored by someone, reviewed by someone, with a moment where it could have been caught.
If you want to govern a control, govern the moment it changes. The policy document cannot do that; it does not know the diff happened. The pull request is where the control's state actually moves, so the pull request is where it should be checked.
Evidence that matches reality
A side effect of checking controls at the diff is that your evidence stops being a story you assemble at audit time and starts being a record of what actually happened: this change touched this control, here is the clause, here is how it was resolved, in the PR thread, with timestamps.
heygrc cites the specific control on the change that touches it, so the trail is grounded in the code, not in a document describing what the code is supposed to do. heygrc is in early access.