Case Audit Detail

The audit detail shows, for every screened case, exactly what the screening found and why. A verdict without justification cannot support a legal decision — here every finding comes with its cited explanation: the rules complied with, the full text of the anomalies, the rules that could not be evaluated, the case's final decision and whether an appeal is available, all one click away from the dashboard.

Open the Painel de Processos (case dashboard, Workspace›Painel de Processos) and click a screened case. The detail opens as a modal over the dashboard, with the header Auditoria: <número> — plus the company, when there is one. The body combines the Case Summary with the expandable report; in the footer you assign the case to a user or take the result to the chat with Continuar no Chat.

How the dashboard list behaves

The dashboard's nine columns — company, case, class, people, status, error type, date, owner and action — always fit the screen width: the list scrolls vertically only, never horizontally. To make that work, each record takes at most four lines; anything beyond that is clipped inside its own cell.

The full content stays one step away: hover a cell to read the complete text in the tooltip, or click the row to open the audit detail. On mobile the list turns into cards, one field per line, and the record shows in full — with no four-line cut.

To narrow the list down to one situation — anomalies only, compliant only, pending only — click the matching total at the top of the dashboard; clicking the same card again brings everything back. The full behaviour is described in Case Dashboard.

Compliance status

The status badge reflects the screening verdict, not the procedural stage. There are three screening statuses:

• Conforme (compliant) — the screening ran and no anomaly was detected.
• Anomalia (anomaly) — one or more rules were violated.
• Anomalia Crítica (critical anomaly) — a rule violation classified as critical.

Two situations can appear on the dashboard but are not screening statuses:

• Not screened — the case has no verdict until the next screening run includes it.
• Analysis failure — the run tried to screen the case, but the AI analysis failed (usage limit, time exceeded or unexpected format) or came back inconclusive for lack of data. It is not a verdict: just reprocess the case to get the real status.

A case without screening never shows as Conforme. If a case you know was screened shows no verdict, check whether the dashboard is open in the right workspace/context — see the next section.

Why the workspace context matters

The detail is always fetched from the context database of the workspace the dashboard was opened from, never from a fixed default base. The screen resolves the active context — from the domain parameter it receives from the shell, or by asking the platform for the active context — and sends it on every detail lookup; on the server, that context is translated into the real database before the audit is read.

Without that care, the read would hit the wrong database and a screening that does exist would appear as nonexistent — that is the origin of the false "not screened" / Pending. With the workspace context, the screened case is found where it actually lives. The platform exposes an endpoint to look up the audit detail and another to discover the active context; both are in the API reference.

The case number travels as a query parameter, never in the URL path: case numbers may contain / (e.g. ...-0/RS), and the firewall rejects the encoded slash inside the path, returning error 400.

Case Summary

At the top of the detail, the Case Summary panel describes the case itself, independently of the screening verdict. The fields are aggregated from the context's graph:

Fields without a value are omitted — no empty rows.

The same Case Summary also appears in the Chat, in the graph side panel, when you select a :Processo node: it is the same lookup, with the same workspace context, showing the same fields.

The report in three sections

The report exposes three expandable buttons at the top, present in any status. The real count is in each button's title; an empty group is disabled and shows "Nenhum item." (no items) when expanded.

Itens em Conformidade — compliant items (green)

Each rule the case complied with, with the corresponding report text — a compliant case shows what was verified, not just "no anomaly detected".

Anomalia Detectada — anomaly detected (red)

Previously labeled "Itens Não Conformes" (non-compliant items), this button expands and shows the full text of the anomaly report in markdown — not a summary. The content is the ### Anomalias Detectadas section of the screening report, extracted raw: it preserves the #### <regra> sub-headings, the - Campo: valor bullets and the --- separators, and is rendered with the title of each rule in red. It is the same complete content the chat displays, with no duplication in a separate area.

The button count is the number of rules with an anomaly. In legacy reports, without the markdown section, the screen falls back to the structured list of irregularities already stored.

Regras Não Aplicáveis (Sem Contexto) — non-applicable rules (neutral)

Lists the rules the screening could not apply due to missing data in the case — the model marked them as SEM_CONTEXTO during the analysis. It comes from the ### Sem Contexto Suficiente section of the report and appears in every audit, not only in those with anomalies.

These rules do not change the compliance score: they carry neutral weight. When all rules come back without context, the final verdict is Inconclusivo (inconclusive) — which, like "not screened" and "analysis failure", is not one of the three screening statuses.

Rules without context usually mean the case does not have the data the rule needs, or that the reference material of the procedural code is missing. Each context can point to the procedural-code database — articles + case law — in the codigoProcessualDatabase field of the domain settings, resolved dynamically per context and never hardcoded. Without that database configured, rules that depend on the reference legislation tend to fall into "no context". See the multi-source context configuration.

Final Decision and Availability of Appeal

In parallel with the rule analysis, and without blocking it (the extraction is best-effort), the screening automatically extracts with AI and displays in the detail:

• Final Decision — the summary of the case's most recent decision, judgment or ruling, or "Sem Decisão Final" (no final decision) when there is none yet.
• Appeal Available — indicates whether an appeal is available, with the appeal and its deadline, or whether the case has become final and unappealable / no appeal is available.

This data is persisted on the :Processo node (temDecisaoFinal, decisaoFinal, cabeRecurso, recursoInfo) and comes back together with the case summary in the detail lookup.

Important: cases screened before this feature do not have the decision and appeal fields filled in — simply re-screen the case so the extraction runs and the fields are populated. The compliant / non-compliant items already appear for existing screenings, because they come from the report already stored.

Triage History — the case is alive

A lawsuit is not a frozen book: it keeps receiving new filings, and a recent decision may legally resolve an anomaly detected by an earlier triage run. The Triage History section at the end of the detail view shows that trajectory: every triage run becomes a version of the report, and each version is compared to the previous one, rule by rule.

What each version shows:

• Header — version number, run date and time, overall status and the counts (compliant · anomalies · no context).
• Transition badges — what changed against the previous version:
  • Resolvida (resolved) — the rule was in anomaly and the new analysis found it compliant. With temporal weighting active, the analysis explanation cites the filing that resolved it and its date.
  • Nova anomalia (new anomaly) — a rule that was compliant (or had no context) is now violated.
  • Persistente (persistent) — an anomaly still open.
  • Agravada / Atenuada (aggravated / mitigated) — severity change between anomaly and critical anomaly.
  • Indeterminada (indeterminate) — the anomaly stopped being observable (the rule came back "no context" or left the report). This is not a resolution: the platform never marks an anomaly as resolved just because the model stopped seeing it.
• Transition list — every rule that changed, with before → after.

The first triage of a case shows as Version 1 — no previous version to compare. Reports stored before this feature display a notice: history starts being recorded from the next run onward.

Case Timeline — the complete view

The Histórico do Processo button in the detail footer opens the complete timeline — lawsuits are serious and decisions carry real-world implications, so the user needs to see EVERYTHING that happened, in order, in one place. The timeline interleaves, newest first:

• Docket filings — every dated act extracted from the documents: Nova decisão — Sentença (judgment), Acórdão (appellate ruling), Decisão interlocutória (interlocutory decision) or Despacho (order), with the publication date, instance, source document and a summary of the operative part or outcome.
• Triage events — every triage run with its verdict and the changes it recorded: resolved anomaly, new anomaly, persistent, aggravated, mitigated or indeterminate, rule by rule, with before → after.

The filters at the top (Tudo · Movimentações · Triagem) narrow the view; Voltar ao laudo returns to the audit detail. Acts without a readable date are left out of the timeline — inventing a position would be worse than omitting — and remain visible in the report body and in the case documents.

Temporal weighting in the analysis

Triage gives greater weight to the most recent filings in the record. Documents are presented to the model in chronological order, each annotated with its date and the most recent one flagged; the analysis instruction requires that an old anomaly superseded by a later act (merits decision, defect cured, missing document filed) be assessed as compliant, citing the filing and its date in the explanation. Across analysis windows, a resolution declared in a more recent excerpt prevails over an anomaly flagged in an older one — never the other way around.

Hands-on example

1. On the case dashboard, filter by Anomalia and open case 0007890-12.2024….
2. The Case Summary shows the procedural class, the adjudicating body and the parties.
3. Expand Anomalia Detectada: each violated rule appears with its own title in red, followed by the detailed justification — what the rule requires, what was found in the records, and why it constitutes an anomaly.
4. Check Appeal Available to see which appeal applies and with what deadline, then click Continuar no Chat to keep analyzing with the AI.

Always a useful answer

• While the detail loads, the screen shows a loading state — the panel only mounts after the response, and it never appears blank.
• If the lookup fails (400, 404 or timeout) or comes back empty, the detail does not break: it builds a Pending view from the selected row, showing the case (class, company, people) even without a screening having run.
• Each report button, when empty, is disabled and shows "Nenhum item." when expanded — no blank screen.

See also: Batch Triage · Triage rule generation · Appeal Co-pilot · Multi-source context configuration