Triage GitHub issues with calibrated labels

01 · Role in the system

What Jev does here

When an issue opens, secrets are redacted by regex, one guardrail call screens the text, and one system_one call asks eight questions in parallel: type and area as Choices, severity as a four-level Score that lands between levels, and five Nouls - missing repro info, actionable today, security-sensitive, good first issue, or recurring. Choice and Score answers collapse into a confidence of (n·p_max − 1)/(n − 1), and the policy is ordinary code on those numbers: labels write only at confidence ≥ 0.55, security fires at P ≥ 0.5 because false positives are cheap, softer flags at 0.70 and 0.75 - below that the label withholds and prints the top-two split for a human. A model never authorises its own writes: applying labels is off by default, budget-capped, and refuses any repository but the one named. Eval runs 78 frozen real issues plus 21 red-team fixtures offline in CI.

02 · Control boundary

Where Jev sits

Two Jev calls per issue (guardrail, then eight parallel questions); thresholds, withholding, and writes live in auditable Python that the numbers gate.

Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.

03 · Known limits

What this evidence does not prove

• Thresholds (0.55 for labels, 0.5 security, 0.70 and 0.75 for the softer flags) are the author's policy tuned on the frozen eval set, not a benchmark.
• The 78-issue eval set defaults to microsoft/vscode; behavior on other repositories is untested here.
• Latency and per-thousand-issues cost figures are author-reported; the write path is off by default and deliberately capped.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• KalyanM45 ↗Community · github · public · checked 2026-09-22