Alerts and Actions

Preview — feature under development. Behavior, screens and contracts may change without notice between releases.

Triage already knows what is wrong in each case — which rule fired, with what urgency, with what evidence, and what to do about it. Previously, that knowledge stayed locked inside one case's report, stored as JSON in the analisesPorRegra property. To answer "what needs my attention today", you had to open report after report.

The Alerts and Actions screen (menu → Investigation → Alerts) publishes that same knowledge as a queryable queue.

What an alert is

An alert is one rule that flagged an irregularity in one case. It is not created by hand: it is derived from the report. There is no creation screen and no creation endpoint, and that is deliberate — a manual creation path would open a second source of truth that diverges from the first on the very next reprocessing.

Only analyses with an anomaly become alerts. "Compliant" and "no context" stay in the report and never enter the queue: if they did, every batch triage would dump thousands of records that need no action, and the list would stop meaning "this needs someone".

Severity

Derived from the urgency triage already assigned, not from a second scale:

Reusing the existing scale avoids the classic symptom of two scales for the same judgement: a "high" alert over a low-urgency analysis, with no way to say which one is right.

Life cycle

Discarding is the only transition that removes a finding from the queue without resolving it. That is why it is the only one requiring a justification: without it the queue becomes a silent bin and nobody can reconstruct why that alert disappeared. The button stays disabled while the field is empty, and the server refuses the transition even when the API is called directly.

Reprocessing does not undo your work

Triage is reprocessed often — via "Reprocess failed only", via an embedding model change, via a rule edit. Alert identity is (case, rule, rule version), and projection separates creation from update: it refreshes the fields derived from the report and never sends back to "New" an alert somebody already moved.

The rule version is part of the identity on purpose: an edited rule is a different rule from the finding's point of view. The old alert describes what the previous version found, and overwriting it would erase history.

The Actions tab

Every transition becomes its own record, with who moved it, when, from which state to which, and the justification.

This exists because storing only the current state answers "where is the alert", while the question auditing asks is a different one: "who moved it, when and why". Without the record, the justification required on discard lasted only until the next transition overwrote it — and the rule that makes it mandatory exists precisely so that it can be recovered later.

Alerts for cases triaged BEFORE

Projection runs on the triage write path, so it covers whatever is triaged from now on. Every earlier report still holds its findings locked as JSON.

An administrator reprojects the whole context through the Reprojetar alertas do contexto action, in the bar above the list. It only shows up for users who hold the backfill permission — those who do not have it never see the button.

The action asks for confirmation (it sweeps every finished screening of the context) and, once done, shows the numbers: how many alerts were projected, how many reports were read and how many could not be read. For automation, the same operation lives in the endpoint reference, under "Screening & Rules".

The operation reprojects, it does not recompute: no LLM and no embedding are involved, because the analysis was already done and is already stored. Recomputing would be expensive, slow and — worse — could produce a different verdict from the report the user already read.

It is idempotent: same key, same split between create and update, so running it twice neither duplicates nor reverts state. The response carries the counts (laudosLidos, alertasProjetados, laudosSemAnomalia, laudosIlegiveis, duracaoMs) — never just "ok". A backfill that answers success without a number is indistinguishable from a backfill that did nothing.

Permissions

VIEW is separate from MANAGE because seeing the queue is analyst work and moving the queue is a decision — whoever reads is not always whoever decides. And BACKFILL is separate from MANAGE because it sweeps every report in the context: it is platform maintenance, not queue operation.

ALERT_VIEW and ALERT_MANAGE belong to the default roles of whoever triggers triage. ALERT_BACKFILL is sensitive and stays with administrators only.

Where the data lives

Alerts live in the context's Neo4j database, next to the report that produced them — not in a system database. On the first projection for each context the service creates the identity constraint and the status and severidade indexes.

That is not only integrity: the key is composite, and without an index the MERGE scans the whole label for every rule of every case. In a batch triage the cost is quadratic — it works in the demo and kills the real load halfway through, hours in, without saying why.

Known limitation

The redesign prototype sketched, in the Actions tab, a form to create links between graph entities (RELATED_TO, SAME_AS, MEMBER_OF, DERIVED_FROM) and to request a document or forward for analysis.

That is not implemented. It requires two capabilities that do not exist today: entity search from the screen, and a relationship write path from the UI. The Actions tab delivers what the platform can genuinely record — state transitions, with author and justification — instead of a form that would save nothing.