Observability Platform  ·  View 22 of 25  ·  Operations

The Cardinality Loop

Seven steps from a bad label to a better pre-production check, closing on the estimate.

Editable source SVG draw.io All views
A deploy adds a label user_id on an error metric Gateway admission sees it before the store does Label dropped, series kept the aggregate survives Enforcement event written attribute named, team attached Owning team notified same day, not month end Fix, or an exception with an expiry never a permanent waiver Pre-production estimate updated caught at review next time Cardinality control admitted degraded recorded attributed decided learned next deploy The Cardinality Loop — Admitted, Attributed, Fixed Application we own Decision point Opportunity Risk / gap Person or role Security / platform The loop closes at the estimate: every incident that reaches admission is a question the pre-production check should have asked. v 1.0 · owner Reliability Architecture · date 2026-09

Decisions

  • Degrade before rejecting: the over-budget label is dropped and the series collapses into a lower-cardinality parent, so the measurement survives even when the detail does not.
  • Every enforcement action produces an attributed record with the offending attribute named, delivered to the owning team the same day rather than at month end.
  • An exception carries an expiry. A permanent exception is a repealed control.

Why it is a loop

  • Every incident that reaches admission is a question the pre-production estimate should have asked. The loop closes by feeding the estimate, which is the only step that reduces the rate of the next one.

Risks

  • Label-dropping is a silent change in meaning if the reader does not notice: the series is still there, it just no longer splits by the dimension they expected. The enforcement record is what makes that visible, and it must reach the dashboard, not just the team's inbox.