Batch Screening

Auditing thousands of cases for compliance by hand — opening each one, checking rule by rule, recording the finding — is weeks of work for an entire team. With DATTA's Batch Screening, you pick the context, click one button and the platform audits the whole collection while you watch the progress live, case by case. The outcome is not a dry pass/fail: every case gets a report where each decision comes with the rule evaluated, what was found in the case files and the reason for the verdict.

See also: creating screening rules with AI and the audit detail of each case.

What screening does

Batch Screening analyzes the cases of the selected case context and checks each one's compliance with the active screening rules. Which rules take part in the analysis — those of the CPC, the CPP, the CDC, or several of them together — is a setting of the context itself, made once under Sistema›Contextos and valid for every case in it. You do not choose it on each run, and the platform does not guess either: see which rules screening applies.

The screen lives at Processar›Triagem›Processar, with the navigation trail DATTA › Triagem › Processar, and the main card shows the "Triagem em Lote" label. Execution is asynchronous: when you start, the platform responds instantly with an execution identifier and processing continues in the background. You can close the page — screening keeps running and the live view resumes when you reopen it — or cancel at any time. The run also shows up in the background executions panel.

Naming. The label went through renames: "Execução em Lote" → "Triagem Processual em Lote" → "Triagem em Lote" (the current label). Some older documents and the background executions panel may still mention "Triagem Processual em Lote" — it is the same feature.

Choosing what to screen

Case context

In the Triagem em Lote card, chips list the registered case contexts (e.g. "Processos"), always with the configured label and never with the internal key. The selection is single: screening runs over one context — one graph database — at a time, and that is where the cases live. If you arrived from a workspace, its context comes pre-selected when it is a case context; otherwise, the first registered case context is used.

Why don't CPC/CPP/CDC show up here? Those are legal code contexts: they hold articles, clauses and case law — they are the source of the rules, not of the cases. They are chosen in the case context's registration, not on this screen. An old version of the screen offered those contexts as chips, but the choice had no effect: worse, the cases were located through the platform's active context, so with a legal code active (e.g. CPP) screening swept a base with no cases and "started nothing". Today the screen sends the context explicitly and the platform validates that it exists, refusing the unknown with an actionable message.

With no case context registered, the button is disabled and the screen guides you: "Cadastre um contexto do tipo 'Processo Judicial' em Sistema › Contextos."

Which rules screening applies

Screening evaluates the rules of the rule contexts declared in the case context — the "Contextos de regra aplicados na triagem" field of the context registration/edit form (see managing contexts). These are two different axes, and each answers one question:

With more than one rule context checked, the analysis uses the union of all their rules, without repeating a rule that belongs to more than one code. A civil collection with consumer relations, for instance, can declare CPC and CDC at the same time.

The setting is read on every run: changing the rule contexts and launching screening right after already uses the new value, with no restart and no wait.

If the context declares no rule context, screening refuses — it does not try to guess, and it does not spend AI analysis. Each case shows up in the feed in red with the reason: "O contexto '{nome}' não declara quais contextos de regra se aplicam a ele. Abra Sistema > Contextos > Gerenciar, edite o contexto e preencha 'Contextos de regra aplicados na triagem'; depois repita a triagem." Just check the rule contexts in the registration and run again.

Why refusing beats the previous behavior. Until 2026-08-08 the platform tried to discover the applicable code for each case from loose words in the case text. Measured in production: a civil enforcement case against the public treasury was sent to a code that does not exist on this platform — because the word "administrativo" appeared in summaries and grounds quoted in the file. The result was a "completed" report with zero rules evaluated, indistinguishable from a genuinely audited case. Refusing with the reason on screen trades a false result for a visible pending item.

Scope

Four mutually exclusive modes — three radio options and one checkbox:

Checking Apenas regras novas/atualizadas disables the radios (the modes are exclusive), and all controls stay locked while screening runs.

Each mode does exactly what its name says. "Triar novos documentos" covers only what has no screening yet — the case without a report and the document that arrived after the last one; errors of any kind are handled in "Reprocessar erros". Before the dedicated mode, a report with an AI error was invisible to every mode except "Reprocessar todos" — because it already had an audit and therefore counted as "already screened" — and the case stayed stuck with nobody seeing it.

Click Iniciar Triagem dos Processos. If no case fits the chosen mode, the card shows the amber "Nenhum processo para triar" state, with a diagnostic that names the context and the database queried and suggests the next step per mode — e.g.: "Nenhum processo pendente de triagem no contexto 'Processos' (base processotributario). Todos os processos desse contexto já foram triados com sucesso — use 'Reprocessar todos' para refazer a triagem." When there are reports whose automatic repair has already been exhausted (3 attempts), the message says so explicitly and points at the likely cause — the AI provider's quota is used up.

It is not an error, but it is not the green "Triagem concluída" check either: the two states are visually distinct precisely so that "zero cases" never passes as silent success. Nothing is deleted on this path — the cleanup of the "Reprocessar todos" mode only runs after the context is validated and there are cases to screen.

Schedule it instead of clicking

Next to the start button there is Agendar. It saves this very screening — the context and the mode you just picked — for a specific date or for a recurrence, and what fires it at the appointed time is the Datta Scheduler, the same clock that runs DATTA Extract loads.

It is the path for routines that should not depend on someone remembering: screening new documents every night, reprocessing errors on Sunday (when the AI quota has renewed), or firing a single pass on an agreed date.

The schedules appear right below the buttons, with the recurrence in plain language and the next run, and can be paused, edited and removed right there. Removing a schedule deletes no report.

The full walkthrough — the five recurrence types, what happens when the platform is down at the appointed time, and what happens when a screening is already running — is in Scheduled Batch Screening.

Following it live

As soon as screening starts, the card itself becomes a progress window that follows the batch case by case, in the same spirit as AI rule generation. There are five elements:

1. Phase icon and circular % bar — an indicator with the percentage in the center while running; a green check on completion; an amber "X" when canceled; a red error icon on general failure.
2. Title and message — "Triagem em andamento…", "Triagem concluída", "Triagem cancelada" or "Erro na triagem", with the detail of what happened.
3. current/total counter and a horizontal progress bar whose color reflects the phase: accent (running), green (completed), amber (canceled), red (error). The counter counts finished cases; the bar moves continuously because it also adds the fraction already evaluated of the case in progress (see item 6).
4. Summary badges — a row of colored counters:
   • ✓ N triados (green)
   • – N inconclusivas (gray) — a subset of "triados": the text was scanned and no rule could be classified.
   • – N sem texto (gray) — a subset of "triados": the case has no indexed text, so no rule was ever evaluated.
   • ↻ N já atualizados (gray — incremental mode only)
   • ✕ N erros (red)
   • ⚠️ N com erro de IA (rate limit/timeout) (amber)
   • ↳ <case> — the case being analyzed at this instant.
5. Colored feed — a scrollable list, in a monospaced font, with one line per finished case, in completion order, showing a symbol, the case number and the occurrence label:

The first three lines correspond to the screening statuses (Conforme, Anomalia, Anomalia Crítica). "Erro de IA" and "Já atualizado" are execution occurrences, not statuses: a case with an AI error is left without a verdict and is simply reprocessed in the next run. On error lines, the feed also shows the reason, right below.

"Triagem inconclusiva" and "Sem texto para avaliar" are statuses too, and the difference between them decides what you do:

• Triagem inconclusiva — the text existed, was scanned, and the data the rules need was not in it. This is a verdict about the case: you review it, you do not re-run it (which is why it stays out of "Reprocessar erros" — repeating would reach the same place while burning AI quota).
• Sem texto para avaliar — the case has no indexed text, so no rule was ever evaluated. This is not a verdict, it is a missing input: the action is to index or reprocess the documents and screen again, and the case enters "Reprocessar erros" automatically. Repeating is cheap — with no text, the report is produced without a single AI call.

The rule behind both: a rule that could not be evaluated does not stamp the status. A rule with no text is evidence of neither compliance nor anomaly, so it stays out of the count that decides the verdict. It is the same report the case panel shows, and both screens read it: until 2026-08-12 the feed labeled these reports "Conforme" while the panel said "Triagem inconclusiva" — the divergence between the screens was the visible symptom of a whole batch that evaluated no rule at all.

1. Progress inside the case being analyzed — a line with avaliando regras: k/N lotes and the estimated time remaining. It exists because a single case can require more than a hundred AI calls: without that detail the case counter sits still for several minutes and the triage looks stuck when it is in fact working. The estimate comes from the pace measured in this run and only appears after half a minute of progress.

Until the first result arrives, the feed shows "Aguardando os primeiros resultados…".

Why the progress never freezes

The live view is authenticated and arrives in real time, frame by frame, instead of depending on reloading the screen. Three safeguards keep it that way:

• The platform turns off intermediate buffering of the responses, so each result shows up as soon as it is ready, and sends a keep-alive signal every 15 s — important because the AI analysis of one case can take up to ~180 s.
• If the connection drops, the screen reconnects on its own with an increasing wait (from 1 s up to 30 s).
• In parallel, a safety check every 2 s queries the batch status (the same source as the executions panel), so the screen does not stay stuck on the last frame if the live feed is lost.

The case counter, even so, only advances when a whole case finishes — which can take minutes in contexts with many rules. That is what the avaliando regras: k/N lotes line solves: it shows progress inside the case, so "slow" is never mistaken for "stuck". If the triage still looks stopped, the runbook for triage that does not advance carries the arithmetic that estimates duration and the measurements that separate slowness from failure.

One triage per context

Starting a second triage in the same context while another runs speeds up nothing: both then share the same AI call ceiling and neither finishes. The platform therefore rejects the second one with a message explaining why — and the screen reconnects automatically to the triage already in progress, which is usually what the user wanted. Different contexts remain free to run in parallel.

Canceling also interrupts the cases being analyzed at that instant, freeing the AI ceiling immediately. Reports already written are preserved and the outcome is recorded in the background executions panel.

Every error with its reason

When a case fails, the window does not just show "error": it shows why. The reason is derived from the report, in this order — error type, explanation and finally compliance — and truncated to fit the line. Typical causes, always in Portuguese:

• Request limit / timeout / format — the AI analysis exceeded the per-minute quota, blew past the time limit, or returned an unexpected format.
• Internal failure — an exception during the audit, listed with the case number and the captured reason.

A report never counts halfway

A case's classification is done in batches of rules sent to the AI model, and screening is all-or-nothing:

• If all rule batches fail in the AI call, the report gets an AI error — counted as an error, not as success.
• If the case receives a verdict (compliant or anomaly) but some batches failed, the report is partial — the explanation warns that "rule batches failed" — and it also counts as an error. An incomplete report never goes in as "successfully audited".

That is why the screen separates "N triados" from "N com erro de IA", and the final message reads, for example: "Triagem concluída com avisos: 14 auditados (13 processos conformes e 1 com anomalia), 2 com erro de IA (limite de requisições/timeout/formato). Reexecute os processos afetados." Just run the batch again — the "Reprocessar erros" mode picks exactly those cases — or reprocess each case from its detail screen.

Where the result appears

Once screening finishes, the reports live in the audit panel (trail DATTA › Visualizar › Dashboards):

• Pagination of 50 cases per page, with the footer "N processos — Página X de Y" and the ← Anterior / Próxima → buttons. Filters by status, error type, case number, company, person and assignee; sorting by column (default: audit date, most recent first). With no results for the filter, the screen shows "Nenhum resultado encontrado".
• Searchable report: the full text of each report is indexed in excerpts of up to 200 words each — one index for the full text (datta_auditorias_documents) and another for the per-rule excerpts (datta_auditorias_chunks), each excerpt carrying the vector of the active embedding model. The fragmentation avoids payload errors with large reports and makes the report findable through textual and semantic search, per case.
• Expandable sections per case — Itens em Conformidade (green), Anomalia Detectada (red) and three neutral sections that separate situations which used to appear together. The separation exists because only one of them requires action from you:

None of the three counts as an anomaly or as compliance; they are listed for transparency. Empty sections show "Nenhum item.", and the no-context ones are omitted from the PDF export so they do not clutter the document.

When the case has no text at all, the screening issues the report immediately, with every rule under "Sem Texto Disponível" and with no AI consumption — previously the same case spent the entire analysis for the model to repeat "não há dados suficientes" rule by rule, and the resulting report was indistinguishable from a case that had actually been analysed.

• Final decision and appealability: in parallel with the rules analysis — in a best-effort way that never brings down the screening — the AI extracts two blocks stored on the case itself. Decisão Final appears in green with the summary of the most recent judgment or appellate decision, or in gray as "Sem Decisão Final" when there is none yet. Cabimento de Recurso appears in amber as "Cabe Recurso" (which appeal and the deadline) or in gray/green as "Sem Recurso Cabível" / "Transitado em julgado".

The Itens em Conformidade and Itens Não Conformes buttons open the text of the matching report items — previously, a compliant case only showed "Nenhuma anomalia detectada" and hid the compliant items. All of this is exportable to the report's PDF, with the same colors and icons. The full detail is in Case Audit Detail.

Hands-on example — auditing an entire collection

1. Your team has just loaded 1,200 tax cases into the "Processos" context. Open Processar›Triagem›Processar.
2. Confirm the "Processos" context chip and keep the Triar apenas processos novos mode.
3. Click Iniciar Triagem dos Processos. The progress window opens and the feed starts listing: 0001234-56… ✓ Conforme, 0007890-12… ⚠ Anomalia detectada…
4. Close the tab and go to lunch — screening continues in the background. When you reopen it, the progress resumes where it is.
5. At the end: "Triagem concluída: 1.198 auditados, 2 com erro de IA". Open the audit panel, filter by Anomalia and prioritize the cases with a critical anomaly — each one with the rule violated and the justification cited in the report.

Who can use it

Firing and scheduling are different permissions. Firing is an observed act, with someone in front of the screen to see the outcome and cancel; scheduling leaves the platform screening on its own indefinitely. The default analyst and advanced user roles get both — the split exists for an organisation that wants to keep manual screening and remove the automatic one.

The check happens on the platform, regardless of what the interface shows: anyone without the permission gets a clear refusal, in Portuguese. Whatever the interface hides or disables is only a visual hint — the security barrier stays on the server. Permissions are administered under Sistema›Segurança›Roles e Permissões and detailed in the roles and permissions guide.

Why the tracking is trustworthy

• The live status is authenticated, so it arrives in real time instead of depending on reloading the screen.
• The report is all-or-nothing: a failed rule batch becomes a visible error, never a false "success".
• Every error shows the reason (request limit, timeout, format or internal failure), not just a counter.
• No context name is fixed in the code: the label, the base and the rule contexts come from configuration — and a rule context that does not exist is refused when the registration is saved, not six months later as "no rule evaluated".
• A large report does not blow up the index: 200-word excerpts and a panel paginated at 50 per page.
• The decision and appeal extraction is best-effort and never brings down the screening.

Batch screening can also be triggered and tracked through an integration — see the API reference, useful for connecting external ingestion pipelines.