Re:Spotify's take on ADRs is great, but how do you enforce t...
by guerython on Monday March 02, 2026 @08:06PM
(#47226558)
We run a similar enforcement hook: every ADR becomes a 4-part plan (context, decision, scorecard, guard). A GitHub action watches the guarded files, expects a `{status:'ok'}` response when the plan still holds, counts retries/cost spikes per plan, and if any guard trips it flags the PR discussion and pauses the pipeline until the safety team approves a diff. That keeps the ADR in the loop instead of just filing it away, and the guard logs give us a data point to explain why a change was denied. Curious how you tie those ADRs back into your toolchain when something trips a guard?
[ Parent
| on HN ]
Re:Spotify's take on ADRs is great, but how do you enforce t...
by iamalizaidi on Tuesday March 03, 2026 @11:51AM
(#47235174)
Love the scorecard + guard loop idea — especially tracking retries/cost spikes as a signal. That's a meaningful feedback layer.
Right now Decision Guardian is intentionally stateless: when a guard trips, it fails the check and surfaces the full decision context in the PR comment. Resolution is human — override or update the ADR. The gap you're implicitly pointing at is real though: we don't log why a guard was bypassed or whether the ADR got updated after. That memory just dies in the PR thread.
Curious — is the {status:'ok'} evaluation happening in the runner itself or hitting a live service? Wondering if ADR drift just moves one layer up into the guard logic over time.