Caveman declarations in ntfy approval messages for HIGH/CRITICAL ops (Phase 3 — GATED) #41

Open
opened 2026-06-12 20:39:53 +00:00 by mathias · 0 comments
Owner

Context

Phase 3 of the ubiquitous-language system. The risk-tier approval middleware already sends ntfy messages for HIGH/CRITICAL operations. This change: the agent's caveman declaration becomes the headline of the approval message, so the human approves the declared intent, not a raw tool call. A declaration that fails the rubric is grounds for denial before reading the payload.

Motivating example: the 2026-04-27 ip rule flush incident. A rubric-valid declaration ("caveman: me restart kube-router, not touch Tailscale routes") would have surfaced the misdiagnosis at approval time.

GATED — do not start until: Phase 1 pilot (mathias/tapir#18) shows caveman declarations are meaningful in practice. Check with the human before picking this up.

Spec

  1. Approval middleware accepts an optional caveman field on HIGH/CRITICAL operation requests.
  2. ntfy message format: caveman line as title, tool + args summary as body. Missing caveman on HIGH/CRITICAL → message is prefixed [NO DECLARATION] (flag, do not block — blocking is a later decision pending evidence).
  3. LOW/MEDIUM tiers: untouched, no caveman expected (F3 bureaucracy guard).
  4. Log every (tier, caveman-present, approved/denied) tuple — this is the dataset for deciding whether to ever hard-require declarations.

Acceptance criteria

  • HIGH/CRITICAL ntfy messages lead with the caveman line when present
  • [NO DECLARATION] prefix on missing declarations, never a block
  • LOW/MEDIUM paths byte-identical to current behavior (regression test)
  • Decision log emitted (format: jsonl, location per existing middleware conventions)

Out of scope

Automated rubric validation (human judges validity at approval time for now), any change to tier classification itself.

## Context Phase 3 of the ubiquitous-language system. The risk-tier approval middleware already sends ntfy messages for HIGH/CRITICAL operations. This change: the agent's **caveman declaration** becomes the headline of the approval message, so the human approves the declared intent, not a raw tool call. A declaration that fails the rubric is grounds for denial before reading the payload. Motivating example: the 2026-04-27 `ip rule flush` incident. A rubric-valid declaration ("caveman: me restart kube-router, not touch Tailscale routes") would have surfaced the misdiagnosis at approval time. **GATED — do not start until:** Phase 1 pilot (mathias/tapir#18) shows caveman declarations are meaningful in practice. Check with the human before picking this up. ## Spec 1. Approval middleware accepts an optional `caveman` field on HIGH/CRITICAL operation requests. 2. ntfy message format: caveman line as title, tool + args summary as body. Missing caveman on HIGH/CRITICAL → message is prefixed `[NO DECLARATION]` (flag, do not block — blocking is a later decision pending evidence). 3. LOW/MEDIUM tiers: untouched, no caveman expected (F3 bureaucracy guard). 4. Log every (tier, caveman-present, approved/denied) tuple — this is the dataset for deciding whether to ever hard-require declarations. ## Acceptance criteria - [ ] HIGH/CRITICAL ntfy messages lead with the caveman line when present - [ ] `[NO DECLARATION]` prefix on missing declarations, never a block - [ ] LOW/MEDIUM paths byte-identical to current behavior (regression test) - [ ] Decision log emitted (format: jsonl, location per existing middleware conventions) ## Out of scope Automated rubric validation (human judges validity at approval time for now), any change to tier classification itself.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/hyperguild#41