Action Limits

Action limits are tenant-level controls for governed platform actions. Keva currently stores three limit types:

Limit	New-tenant default	What it controls
Daily action limit	50	Automated platform actions per day
Daily refund limit	$500	Total refund amount reserved per day
Single refund limit	$100	Maximum amount for one refund

Daily-action and daily-refund counters reset at midnight UTC. The single-refund limit is checked per proposed refund and does not have a daily counter.

View and edit limits

Open Settings → AI & Triage → Spending & Action Limits.

The current Settings surface shows:

• the limit maximum and current usage;
• the stored alert-threshold percentage;
• the next reset time when the limit has one; and
• whether usage has reached the stored threshold or maximum.

Choose Edit on an existing limit to change its maximum or stored threshold, then choose Save. Updates require current settings-edit authority. Catalogue reads require current settings-view authority and are returned as private, non-cacheable responses.

Maximum inputs are exact: daily actions accept positive whole counts up to 99,999,999, while daily and single refunds accept positive decimal amounts with at most two fractional digits up to $99,999,999.99. Runtime refund enforcement converts admitted amounts to integer cents. Values are stored in their canonical decimal form; invalid, exponent, fractional-cent, zero, negative, and overflow inputs are rejected without mutation.

How enforcement selects a limit

For the currently governed action-proposal paths, Keva looks for an exact platform limit first and falls back to the tenant-wide limit. Missing required daily-action or refund configuration fails closed.

The current Settings screen edits existing rows. It does not provide a separate Limits dashboard, historical limit analytics, a manual reset control, an emergency override, or surge mode. Creating or deleting platform-specific limit rows is supported by authenticated APIs but is not exposed by this Settings screen.

Capacity and reset behavior

Keva reserves the applicable daily-action counter and, for refunds, the applicable refund counter inside the owning Action/Approval transaction. When a proposed action would exceed a required limit, the proposal is denied rather than reserving partial capacity.

A selected daily counter whose reset time is at or before the current invocation instant rolls forward to the next UTC midnight before capacity is evaluated. The hourly reset job uses the same inclusive boundary for idle rows. Counter reservation and idle reset use deterministic row-lock ordering so concurrent workers do not intentionally consume the same final slot.

Current readiness boundary

The reset boundary, lock ordering, concurrent winner schedules, rollback/retry, and current-authority revocation cases have local unit and disposable PostgreSQL 17 checks. These checks do not show that the deployed Settings journey or every HTTP create/update/delete and audit path is available.

The following work remains open:

• the prospective global-row uniqueness migration is not applied;
• configured database concurrency, scheduling, and browser behavior are not available yet;
• alert delivery is not available yet;
• Exact amount units and unknown/full-refund enforcement are covered by local checks; connector/provider behavior, configured limits, deployment, browser behavior, and product enforcement are not available as a customer journey yet; and
• non-WordPress action identity and ambiguous retry/replay handling need broader customer-facing validation.

Until those boundaries close, treat the Settings values as configured controls with local enforcement evidence—not as confirmed deployed guarantees.