Liquidity thresholds need governed change

What the public implementation shows

Guevara exposes add, update, delete, list, and detail commands and queries for ParticipantThreshold, plus a BalanceThresholdService and ThresholdZone model.

Threshold administration is separated from automated evaluation of incoming balance observations. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleAn alert threshold is a policy decision whose history matters as much as its current value.

The decision behind the mechanism

The model makes both policy configuration and resulting liquidity classification inspectable.

An unexplained threshold change can suppress a critical alert or generate repeated false escalation without leaving a policy trail. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Authorize threshold writes separately from balance viewing.
• Audit previous and new values.
• Validate zone ordering and financial units.
• Re-evaluate alerts after an approved change.

How the control should be operated

Changes should retain actor, rationale, prior value, effective time, participant, account context, and approval evidence.

Liquidity zones remain credible inputs to participant follow-up and settlement-risk management. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.