Document Upload and Ingestion

Digitizing a collection is easy; making it searchable is another story. With DATTA's Upload page, you drag your PDFs (judgments, appellate decisions, rulings, orders, appeals), choose the target context and follow, file by file, the entities the platform identifies in real time. Processing runs in the background: you can leave, come back, and the tracking is restored — no babysitting a progress bar.

The Upload page is the main path to bring outside documents into DATTA's knowledge graph and search indices. It has three tabs — Documentos (Documents), URL and Arquivos (Files) — which share the same context selector at the top. This guide covers PDF uploads (the default tab); the URL tab is detailed in the URL and legislation ingestion guide. The full list of accepted formats (PDF, DOCX, XLSX, PPTX, HTML, text/data and ZIP/TAR/GZ packages), the per-format limits and the rejection rules are in the supported formats guide.

To get there, use the Processar›Upload path — every link in the navigation trail at the top is clickable, and navigation happens without reloading the page.

1. The target context is mandatory

Before any upload you choose where the content will be stored. The Target Context block lists the available contexts (e.g. Processos, CPC, CPP); clicking one marks it as the Active context (green indicator), and legislation contexts get the Legislação badge.

This requirement protects your data: the document is written to the selected context's database, and the platform applies the extraction rules and the entity-identification model configured for that context. Without this guard, a case could end up written to a legislation base (or vice versa).

The protection exists on both sides:

• On the screen: if you drag PDFs without an active context, the upload is blocked on the spot with the message "Selecione o contexto de destino (ex: Processos) antes de enviar. Clique no contexto desejado acima." — no file is sent.
• On the server: any submission without a context, by PDF or by URL, is refused with the message "Selecione um contexto de destino antes de enviar o documento." The context is never guessed.

Loading and empty states

• Loading: while the contexts are being fetched, the block shows an indicator with "Carregando contextos..." — never a blank area.
• Empty: if no context is configured, the guidance "Nenhum contexto configurado. Acesse Sistema para criar contextos antes de fazer upload." appears with the suggested action.

2. Uploading PDFs

On the Documentos tab, drag the files into the drop area ("Arraste PDFs aqui ou clique para selecionar") or click to pick them with the system selector. You can send several PDFs at once, and you can start new batches even while a batch is still running — they join a FIFO queue and start automatically when the previous one finishes (you do not need to upload again).

Each PDF goes through the platform's ingestion pipeline:

1. Text extraction from the PDF;
2. Splitting into passages (chunks);
3. Embedding generation (semantic vectors) for search;
4. Writing to the context's graph;
5. Entity extraction using the context's model;
6. Completion — the summary reports how many passages and how many entities were generated.

Processing is asynchronous and resilient: the platform returns a batch identifier right away and keeps working in the background, even if you close the tab.

3. "Upload NN" batches and the remove button

Each submission (one upload operation, with one or several PDFs) becomes an expandable group on the screen, labeled Upload 01, Upload 02, and so on. Each group's header shows:

• the label (Upload NN) and the file count;
• a status badge: Processando (blue), Na fila (gray), Concluído (green), Cancelado or Erro (red);
• an "x" button on the right.

Clicking the group expands or collapses it, revealing the status of each PDF inside it.

The "x" button (remove or cancel a batch)

The "x" acts according to the batch's state — the tooltip and the accessibility label follow along:

Important: for a batch that is already processing, the "x" only interrupts the tracking on the screen — processing continues and stays visible in Background Executions. This avoids the inconsistent behavior of "canceling" on the screen while the server keeps working.

There is also the Cancelar Todos button (visible when there are batches running or queued), which clears the whole list on the screen with the same semantics: whatever is already processing continues in the executions panel.

4. Real-time entity feed

As each PDF is processed, the expanded group shows, right below the file's row, the entities identified in that document, grouped by type. Each type appears as an uppercase label with the count in parentheses (e.g. PARTE (4), ÓRGÃO JULGADOR (1)), followed by the list of entities. For each entity the screen shows:

• the name (highlighted);
• the description, when the model provides one, as secondary text.

When a type has many entities, the list shows the first ones and indicates "+N mais". The feed reflects what the platform returns per file and is updated as the batch progresses — you do not need to wait for the whole batch to finish to see the entities of the already-completed files.

Aggregated batch summary (no repetition per type)

At the end, besides the per-file feed, the screen builds a summary of the whole batch ("Entidades extraídas do lote") that aggregates the entities of all successful files, eliminating duplicates within each type: if the same party appears in three PDFs of the batch, it is counted only once. This summary shows the total passages, the extraction origin ("NER do contexto") and the entities per type.

5. Progress tracking

While a batch runs, the corresponding group shows at the top:

• quick counters: OK (completed), in progress, and X (with errors);
• a progress bar with the percentage and a detail line ("Processando N/Total arquivos...").

Each file row has its own indicator: an icon while queued, an activity indicator during the upload and processing, a green check when it completes (with the passage count and the elapsed time), or a red "x" with the error message. Errors are always shown in Portuguese, inside the interface itself — never as an HTTP code or an exception trace.

6. Resuming after a page reload

Tracking survives reloading the page or leaving and coming back. The screen stores the identifier of the batch in progress locally; when it mounts again, it checks the batch's real status once:

• if the batch is still processing, the screen rebuilds the file list from the persisted status (with markers for the ones not yet finished), recreates the corresponding "Upload NN" group and resumes tracking automatically;
• if the batch has already finished, it shows the final summary and discards the local remnant.

Recreating the group is what makes the batch reappear correctly after the reload: since the per-file status is rendered inside the group, without recreating it the asynchronous processing would vanish from the screen. With the recreation, you come back and find exactly that batch, with each PDF in its current state.

7. Integration with Background Executions

Every upload appears in the console's Background Executions panel (the pulse icon at the top), in the Ingestions and uploads section, with the title, the status, the progress and who started it — the submitting user (resolved from the authenticated session; when there is no identity, it falls back to "system"). See Background Executions for the full panel.

That is what makes the "x" during processing safe: when you stop tracking a batch on this screen, it does not disappear — it continues in the executions panel. From the panel you can still click "Abrir tela →" on an ingestion so the console navigates back to the Upload page and reconnects to the tracking of that task.

Behavior summary

See also

• URL / Legislation Ingestion — the URL tab of the same page.
• Supported formats — what the platform accepts, the per-format limits and the rejection rules.
• Background Executions — the unified panel of everything running in the background, including uploads.