A threshold is a human decision, not a law of nature, so its rationale should be visible and adjustable

What it is

A threshold is not a constant of nature but a human decision, and its rationale (an SLA contract, a historical quantile, a business target, a guess) must be visible in the interface and documentation, with a controlled adjustment channel. An invisible-rationale threshold is black-box authority: readers are bound by its red-green verdicts but cannot interrogate them, and when the threshold is wrong nobody can locate what to change.

Why it happens

Visibility makes the threshold auditable: the reader seeing "error rate above 0.5% is abnormal" should be able to go one step further — "0.5% comes from the SLA promised last year." The rationale turns the threshold from a number into an agreement, giving the red-green state normative force and giving disputes an arbiter ("the contract says 0.5%"). Adjustability keeps pace with the business: the threshold's greatest enemy is expiry, and the adjustment channel must be controlled (who may change it, who is notified, full audit trail) but must exist — without a legitimate channel, adjustment needs go underground (quietly editing queries, privately swapping dashboards), and governance loses control anyway. Visible rationale plus controlled adjustment together form the threshold's governance structure: why this line, and who changed it when and why — both answerable.

Where it stops holding

The adjustment channel's openness should be tiered by metric: SLA-class threshold changes are contractual acts (a change process), operational-class thresholds can be self-served by owners; tiering avoids both the rigidity of "everything through the process" and the chaos of "anyone can edit." The rationale's presentation has two layers: hover detail carries "rationale plus a link to the source document," and the alert message carries a one-line rationale summary — alerts forwarded into group chats must take the rationale along. Thresholds with no real rationale (nobody can say why this number) should be flagged "pending calibration" and enter a review queue rather than keep pretending to authority.

Applying it

• Register metadata for every threshold: value, rationale type, source document, owner, last modified — visible on hover.
• Route adjustments through tiered channels: SLA-class via change process, operational-class self-served by owners, all logged with subscriber notifications.
• Verification: sample three thresholds at random and answer "why this number, who set it, how long since review"; unanswerable means governance is missing — enter the registration backlog.

Related

• Same group: U7.04.1 Thresholds convert a continuous metric into two discrete states · U7.04.3 Single-point breaches and sustained breaches deserve different responses · U7.04.4 Too many alerts train users to ignore alerts · U7.04.5 Alerts must point to the executable next step, not just report the value
• Nearby: U6.10.2 After the underlying data updates, an old bookmark's conclusion may no longer hold · U7.05.5 The baseline period's statistical scope must match the current period's
• Search terms: threshold governance · alert metadata · SLO documentation