/ca:appeal — a middle path between comply and override
Idea log from a full-repo review session — concept capture, not a spec.
Problem
When a gate blocks, the user's options are binary: comply, or reach for /ca:override (blunt, and rightly heavy — logged bypass with attribution). There is no sanctioned way to say "I think this block is wrong in this case — look again." That gap is where governance tools breed resentment: the friction either gets swallowed or routed around.
Concept
/ca:appeal after a block: arbiter re-examines the blocked action with full context — the gate-events entry that just fired (H-code, originating hook, message are all in gate-events.log), the governing rule, and the repo's own decision history. Two outcomes, both on-brand:
- Upheld — the block stands, and arbiter explains why, citing the rule and (where the precedent engine exists) the user's own prior rulings. A better answer than "BLOCKED", and it costs nothing.
- Granted — a scoped exception: this action, this time, with rationale, appended to the audit trail (the
overrides.log line format — [ISO] | BY: <email> | GATE: … | REASON: … — is the precedent, possibly a distinct APPEAL-GRANTED kind so appeals and raw overrides stay distinguishable in retrospectives).
Why it matters
- Converts gate friction — the biggest UX complaint vector for any governance tool — into structured jurisprudence data instead of silent workarounds.
- Feeds the precedent engine: repeated upheld appeals against the same gate are a signal the rule needs review; repeated grants are a de facto exception pattern worth codifying.
- Perfectly on-metaphor. The court that never hears appeals isn't a court.
Design cautions
- Appeal must NOT become a soft bypass of the hard floors: mechanical guards (H-01/02/05, security ceiling, append-only logs) stay appeal-proof — those get "upheld, and here's why" only. Appealable surface = the advisory/ceremony layer and judgment-call blocks.
- Rate/shape: an appeal is a deliberation, not a retry loop — one appeal per block, ruling is final for the session.
- Attribution identical to
/ca:override (git user.email), so the audit story stays whole.
Related
/ca:appeal — a middle path between comply and override
Idea log from a full-repo review session — concept capture, not a spec.
Problem
When a gate blocks, the user's options are binary: comply, or reach for
/ca:override(blunt, and rightly heavy — logged bypass with attribution). There is no sanctioned way to say "I think this block is wrong in this case — look again." That gap is where governance tools breed resentment: the friction either gets swallowed or routed around.Concept
/ca:appealafter a block: arbiter re-examines the blocked action with full context — the gate-events entry that just fired (H-code, originating hook, message are all ingate-events.log), the governing rule, and the repo's own decision history. Two outcomes, both on-brand:overrides.logline format —[ISO] | BY: <email> | GATE: … | REASON: …— is the precedent, possibly a distinctAPPEAL-GRANTEDkind so appeals and raw overrides stay distinguishable in retrospectives).Why it matters
Design cautions
/ca:override(gituser.email), so the audit story stays whole.Related