Docs

AI incidents

One queue instead of three, across security, performance and operations. Three sources feed it and each case says which it came from: a durable security finding from the session-signals detectors, a correlated production incident blamed to a change, and a runtime containment event when the gate holds a dangerous action. Each case carries a status, an owner, a deadline, and the attribution behind it (which session, which prompt, which person) with its confidence stated rather than implied.

Where to find it

  • Localhost: /agent-incidents.html for the queue; a row opens the case in a dialog over the queue, with the actions on each section. An older /incident-case.html?repo=&caseId= link opens the same dialog on the case's section page.
  • API: GET /api/ai-incidents (queue), /detail, /metrics and /lesson/draft, POST /api/ai-incidents/assign, /edge and /lesson
  • Navigation: Attribution in the sidebar, then AI incidents under All tools, in the Sessions, transcripts and traces group. A single case opens from the queue on Today or on a primary page.
  • Hosted: the approve and deny console and the cross-machine view live at /team/agent-incidents

What it does for you

The queue narrows instead of multiplying.Two different sources pointing at the same file in the same change (a security finding and a production incident, say) fold into one case rather than opening two. Two detections from the same source still open a case each. Cases open by deterministic, tunable rules: at or above the severity floor, at or past the recurrence threshold, or a runtime hold, which always opens one. Anything below the rules stays a finding or an incident, which is a real answer rather than a gap.
A production incident is not given a severity it does not have.Deriving one from an error message would sort the queue by whichever adjectives a vendor happened to use. Production incidents open on recurrence and read as unrated, and the filter offers that alongside the four real severities so the class is never invisible.
Prompt text never leaves the machine.A case stores the session and cycle key, not the prompt. The text is read locally on demand. Case titles are built from the rule and the place it fired, never from matched text.
A worked case can become a lesson.Draft a lesson from the case and it joins the guard set, so the next occurrence of the same shape can be caught earlier.

The case: seven sections, one record

A row on the queue opens the case in a dialog over the queue, the same dialog Today and every section page open. It has the same seven sections, in the same order and words, as the team page on repoops.ai: Overview, Evidence, Attribution, Security, Cost, Fix and Prevention. The words come from the one contract both apps read, so the two apps cannot drift. What differs is the actions, because this is the machine that holds the evidence.

  • Overview: the problem, the impact, the facts, the hypotheses and the confirmed cause, with the status and owner; move the status from here.
  • Evidence: the source records, the production record and the timeline; link another local record (a finding, a HOLD, a production incident) to the case.
  • Attribution: the chain as edges, each with the mechanism that found it and its own confidence; confirm, dispute or withdraw an edge, and answer a request for the linked session's transcript.
  • Security: the classification the brief recorded, the affected files, the HOLD if one exists; run a playbook, promote a verb, kill a run.
  • Cost: the scope and build cost as measured, the estimates in their own row, and everything nobody measured reading unknown rather than zero.
  • Fix: the brief, the build, the five checks with each one named and its state, the policy hold and its reason, the approval and the decision; scope, build, approve or reject with a reason.
  • Prevention: the lesson, the guard and what it caught, recurrence after resolution; write or retire a lesson, replay a guard.

A section with nothing behind it says not recorded, never a blank. A check the verdict does not carry says did not run, never pass. Nothing on the page runs on its own: every write is a button you press, and the prompt text is read locally only when you ask for it.

Built vs. planned

The queue, the fold, the case detail with its chain and timeline, assignment, the lifecycle actions and the lesson draft all ship today, LLM-free. Measured time to acknowledge and time to resolve are computed but refuse to report below a sample floor of eight resolved cases, so a small queue reads as not enough yet rather than a number built from two rows. On the hosted side, containment records the decision and requests revocation; the desktop daemon or broker performs it and fails closed, so nothing reports contained when a leg did not complete. An attested decision proves a human approved, not that the model obeyed.

Last updated