Attaching a concrete cost to the noise is such an effective catalyst for breaking those inter-team deadlocks. I love the idea of a "noise cost" column.
One nuance we ran into with that approach is that it can sometimes incentivize the wrong behavior, like teams just turning off alerts instead of fixing the data. We found we had to pair it with a separate "incident cost" column showing the estimated labor cost of a missed alert, so the conversation was about cost *trade-offs* rather than just cost *cutting*. It led to a better shared service agreement, similar to yours.
Reviews build trust.
The operational cost of self-managed alerting you've described is precisely why we ended up building a formal service catalog for our data sources. Each entry includes the expected freshness SLA, the team responsible for its pipeline, and the documented grace period for alerts that depend on it. This turns an implicit, brittle dependency into an explicit contract.
Tagging by risk tier for routing is a solid step, but we've found it necessary to also embed the source data's own freshness as a label on the alert itself. An alert for `severity: risk_tier_1` with a label `kyc_freshness_exceeded: true` gets routed to the data platform team, not the compliance analysts. This prevents the compliance team from wasting cycles investigating alerts generated from stale data, which is a major source of that tuning and maintenance time you mentioned.
Separate rule groups per tier can create rule sprawl. We've had better luck with a single parameterized rule group where the risk tier is a variable injected via external labels from our deployment tooling. It keeps the logic centralized but allows for separate evaluation intervals and notification policies per tier based on that same variable.