Multi-source case law — administrator guide

DataJud removed on 2026-09-03. The Datta Extract package, its daily schedule and the data it had loaded were removed: a fonte publica metadado processual, sem inteiro teor, e o vinculo pos-carga por artigo produzia aresta falsa (o Art. N do rotulo de assunto do CNJ se refere a Lei 8.213/91, nao ao CPC). As demais fontes seguem inalteradas.

DATTA loads case law from five national origins — DataJud, STJ Open Data, STF, TST and LexML — and the decisions end up linked to the statute articles they interpret, with the origin recorded on each ruling and without duplicating the same case when it arrives from two origins.

Since 8 August 2026 these loads no longer have a screen of their own: each source became a DATTA Extract package, just like any other integration on the platform. In practice you gained what the old screen never had — a preview of the data before writing, editable transformations, an execution calendar, per-run history and one-click re-runs.

This guide covers: where the five packages live, how to trigger a load, how to replace the DataJud key, how to schedule and follow up, how to carry over the schedules that existed on the old screen, and the Atualizar contexto button, which has not changed.

The full technical view (provenance, merge keys, divergent interpretation, triage weight) is in multi-source case law — architecture.

1. Where the loads live

Under DATTA Extract›Pacotes you will find the five packages, each named after its origin:

Each package writes to both places at once: the ruling as a record linkable to the article, and the summary vectorized, for meaning-based search and for triage.

If you were looking for the old Jurisprudência tab (which lived under Sistema›Contextos) or the Fontes de Jurisprudência section under Sistema›Conexões›Fluxo de Dados: both were retired. What replaced the old section is a direct shortcut to the packages — never an empty tab.

2. Triggering a load

In the package gallery, each card's menu offers:

Each package declares the values that change from one load to the next — the target context, the searched term, the court, the result ceiling. They ship with a default value written into the package itself, and that default is what the run uses, both for Executar agora and for the automatic trigger.

To load with different values, open the package in the ETL Designer and change the parameter's default before running. This is also how you change what the automatic load brings every day: the default value is what it uses.

The target context is never guessed. All five packages ask for the legal context (cpc, cdc, cpp, …) explicitly, and it is what defines where the rulings are stored and where the text is indexed. The context open on your screen has no influence on the load's destination.

What each package asks for

CARF history. The archive holds 582k decisions (measured 2026-09-10) across more than 430 session months (1990 to 2026). A run has a 6 h deadline and vectorisation is the dominant cost, so the history runs one month per execution. Since the package started indexing the full ementa (not the full text), each decision yields ~2 chunks of 200 words: measured on 2026-09-11 with vLLM on CPU, 200 decisions = 411 chunks in 6 minutes — the largest month (2020-06, 5,318 decisions) fits the deadline comfortably. The script scripts/carga-historico-carf.sh triggers the package month by month, newest first, with up to N runs in parallel, waits for each to finish and records the completed months so it can be stopped and resumed. It accepts the seed's two authentication modes: an admin JWT through the ingress (DATTA_API_URL + DATTA_JWT) or the S2S token from inside the cluster (PIPELINE_DESIGNER_URL + DATTA_INTERNAL_TOKEN). Count days, not hours: the whole archive is ~1.2 million chunks, and the bottleneck is the embedding service.

A release in the middle of the load. A rolling restart of the Datta Extract engine ends the in-flight run as FAILED ("no sign of life") and the script, polling the status during the rollout, gets a non-JSON body — since 2026-09-12 that becomes status ? and the next poll decides; before, the script died silently. The interrupted month is not recorded in the state file and is redone on the next call.

Per-run time ceiling. The engine ends a run that exceeds DATTA_PIPELINE_ENGINE_TIMEOUT_EXECUCAO_MS (72 h on-prem since 2026-09-13; it was 24 h since 2026-09-12, and the code default is 6 h). With CPU embeddings each run vectorizes ~40 chunks/min, and a recent CARF month with full text has 27 to 37 chunks per ruling (202604: 2,358 rulings, 63,661 chunks) — 25 to 30 h; the largest month in the archive (2020-06, 5,318 rulings) would pass 48 h. Month 202603 died at 360 min with the nodes written and the chunks half done; the script redoes an interrupted month on the next call. Since 2026-09-13 redoing is cheap: the embedding step looks the index up before vectorizing and reuses the vector of chunks already stored with the same text — a resumed month costs minutes, not the vectorization hours again.

Why only three packages ask for an article

Not every origin accepts being queried by article, and the platform treats each one for what it is:

The outcome is the same either way: the ruling ends up linked to the article, which is what makes case law weigh on triage. The difference shows only in timing — on collection loads the link appears at the end, not during.

3. Replacing the DataJud key

The DataJud load uses the CNJ Public API, authenticated with an APIKey. That key is public: the CNJ publishes it openly, with no registration, at <https://datajud-wiki.cnj.jus.br/api-publica/acesso>. It is not a private secret, and it may rotate from time to time.

It no longer lives under Sistema›Conexões›Fluxo de Dados. Today it belongs to the package itself:

1. Open Jurisprudência — CNJ DataJud (API Pública) under DATTA Extract›Pacotes and choose Abrir no ETL Designer.
2. Select the source node (the first in the flow, the one querying the CNJ API).
3. Replace the value of the Token / API Key field and save the flow.

The value is stored encrypted and comes back masked on read — whoever opens the flow later does not see the key. The replacement takes effect on the next run, with nothing to restart.

At install time the key is seeded automatically from the platform configuration. With the field empty the package is still registered and fails at run time with an authentication error — on purpose: one source without a key must not block the registration of the other four.

4. Scheduling

Each package ships with its own schedule, staggered through the early morning (Brasília time) so the five loads do not compete for vectorization:

Under DATTA Extract›Agenda de Cargas you see the full calendar — what has already run and what is scheduled — and you can adjust each package's frequency using the same vocabulary as the rest of the platform (hourly, daily, weekly, monthly, or a cron expression).

The automatic run uses the package's default values (§2). This matters mostly for the search term of the term-driven origins: changing the default term changes what the daily sweep brings. Keep it aligned with the collection the target context needs.

A pausado package does not fire automatically and remains available for manual runs.

5. Following up and diagnosing

• During the load: DATTA Extract›Job Monitor shows the runs in progress, with counts of rows read and written.
• Afterwards: Ver histórico on the package card lists start, end, final status and what each run wrote. It is what tells a load that failed halfway from one that never started.
• Failures show the origin's message, in Portuguese, inside the run itself — never as a bare technical error on screen.

Worth knowing when reading a result:

• A completed run does not mean "everything was vectorized". If the vectorization service answers no batch at all, the run fails with the reason written out. But if it fails only on part of the batches, the run finishes fine and the documents without vectors stay only in the service's technical log — they exist in the collection and are not found by meaning-based search. Re-running the load once the service is back fixes it.
• The subject filter (DataJud) and the type filter (TST) are applied after the read. The result ceiling counts what the origin returned, before the filter — if you asked for 100 and filtered by a rare type, you may get far fewer than 100 records written.

6. Carrying over the schedules from the old screen

If your installation already had schedules configured on the old Jurisprudência tab, they stop firing with this update: the loop that evaluated them went away together with the screen. They remain stored, with no error at all — and unnoticed, until the case law goes stale.

The transfer is a one-time task, performed by whoever operates the platform, with the scripts/migrar-agendamentos-jurisprudencia.sh utility. What it does:

• reads the active schedules and matches each origin with the corresponding package — an origin with no package is reported out loud, never silently skipped;
• writes into the package the frequency you had configured, plus the context, the article and the legislation as the parameters' default values;
• preserves the time: the screen's schedule was always in UTC, and the translation records the timezone explicitly, so the load does not start running three hours later;
• does not delete the old schedules — it leaves the cleanup to you, after you verify the result;
• can run in simulation mode, which prints the plan without writing anything, and can be repeated without duplicating anything.

After the migration, the schedule you configured wins over the package's default schedule (§4) — the utility says so in its output, because it is a behavior change that must be acknowledged.

The required access, the alternative of reading from an exported file and the final cleanup command are in the file's own header and in the technical guide.

7. Update context / Full

This flow has not changed. Each context's legislation and the curated case law that comes linked to the articles are still reviewed together. Under Sistema›Contextos›Gerenciar, each context has two buttons:

The operation runs in the background, with a real progress bar — you can leave the page and come back without losing track. On completion the platform shows the update report:

• Diff — how many articles, items, paragraphs and rulings were added, and how much each origin contributed. The count sees everything in the context, including what the §1 packages wrote.
• Divergent interpretation — articles whose heaviest case law has low similarity to the article's text: a sign that the court reads it differently from the letter. Each entry shows the article, the similarity, the reference ruling and the court.

Automatic update: besides the manual trigger, the platform runs "Update context" for all contexts once a week (default: Monday, 03:00 UTC). The frequency and the on/off switch live in the installation configuration and must be changed there and reapplied — never through an ad-hoc adjustment in the environment. The routine is best-effort: one context being down does not bring down the others.

8. Permissions

Without the right permission the action is denied with a message in Portuguese and the event is recorded in the audit trail.

9. Worked example — STJ rulings on limitation periods

1. Under DATTA Extract›Pacotes, open Jurisprudência — STJ Dados Abertos in the ETL Designer.
2. Adjust the default values: target context, judging body primeira-turma and competence 2024-01. Save.
3. Back in the gallery, choose Executar agora. Follow it in the Job Monitor.
4. Repeat with Jurisprudência — CNJ DataJud, court stj and term prescricao tributaria. Rulings that already came in through STJ Open Data and carried the CNJ unique number are recognized and enriched, not duplicated; the rest come in as DataJud records of their own — merging the two origins depends on both publishing the same number (§11).
5. Run Atualizar contexto on the matching context under Sistema›Contextos›Gerenciar to recompute Divergent interpretation against the new collection.

10. Quick verification

With read access to the graph (through MCP, for instance), these queries show coverage, origin merging and divergence:

// Provenance and coverage per origin/court in a context (e.g. cpc)
MATCH (j:Jurisprudencia)
RETURN j.fonte AS origin, j.tribunal AS court, count(*) AS n
ORDER BY n DESC;

// Rulings that arrived from more than one origin
MATCH (j:Jurisprudencia) WHERE size(coalesce(j.fontes,[])) > 1
RETURN count(*) AS multiOrigin;

// Rulings that already weigh on triage (linked to an article)
MATCH (a:Artigo)-[:ARTIGO_TEM_JURISPRUDENCIA]->(j:Jurisprudencia)
RETURN count(DISTINCT j) AS linked;

// Articles flagged as divergent
MATCH (a:Artigo {entendimentoDivergente:true})
RETURN a.numero, a.driftSimilaridade, a.driftTribunal
ORDER BY a.driftSimilaridade;

11. Troubleshooting