AI-Powered Screening Rule Generation

DATTA proposes the screening rules for an entire legal code for you — anchored in the real text of each provision, enriched with the current case law and without recreating what already exists. Hand-writing those rules for a code with over a thousand articles, and keeping them aligned with the courts' understanding, is a months-long project. With Gerar Regras com IA, you describe what you want to validate (or ask for full coverage of the code) and watch the rules arrive in real time.

See also: how the procedural code enters the database and batch screening, which runs these rules.

Where it lives and the three modes

The panel is at Processar›Regras. When you click Gerar Regras com IA, you choose the legal context — the panel always displays the configured label (e.g. "Código de Processo Civil"), never the internal key — and fill in two fields: Quantidade de regras and Foco específico (free text). Their combination, plus the "Gerar todas as regras possíveis para o código" checkbox, selects one of three modes:

In every mode, the rules are proposed by the language model configured for the context, and the accepted rules are written to the context's own graph database. Generating rules requires the RULES_EDIT permission.

How generation behaves while it runs

In any mode the response is immediate: generation runs in the background and the dialog turns into a real-time progress screen — current phase, progress bar, counters for suggested/new/skipped and a feed of the accepted rules.

• You can close the dialog. Generation continues and tracking is resumed when you reopen the page.
• You can cancel at any moment.
• One generation per context at a time. Asking for another during an active generation simply attaches you to the progress of the one already running.

Integrations can trigger and follow generation through the same resources the screen uses — see the API reference.

Thematic mode — quantity under control

The Quantidade de regras field accepts 1 to 50 (default 5) and defines how many new rules to create. The Foco específico field goes into the instruction sent to the model as thematic guidance.

• It only creates genuinely new rules. This mode uses the same semantic deduplication as the comprehensive mode against every existing rule in the context. Since "all possible rules" is not a closed set (an article can always be sliced into more granular rules), asking for N rules after a full generation does not produce N near-duplicates: each suggestion is compared and discarded if a similar rule already exists.
• It fills the quota with rounds. If, after deduplication, fewer than N new rules remain, the platform runs additional rounds — excluding what already exists — to try to reach the requested quantity. It stops early if the code saturates (two consecutive rounds without any new rule) or when it reaches the round cap, and then reports how many it created and how many it skipped for similarity. If there truly is no distinct rule left to create, it creates zero and says so — it never invents a rule to fill the number.

Targeted mode — anchored in the real article

When Foco específico references a provision, generation stops being generic and becomes grounded in the article's real text. Example:

"Crie uma regra para validar se o código 1030 do CPC está sendo aplicado de forma correta."

What happens:

1. Citation recognition — the usual forms are detected: art 1030, artigo 1030, art. 1030-A, código 1030, 1030 do CPC/CPP/CDC/PAF.
2. Provision lookup — the article's real text is read from the context's graph database.
3. Case law — the decisions linked to the article are loaded.
4. Anchored generation — the instruction sent to the model includes the provision's real text and the case law; the resulting rule cites the provision (Art. N) in its own wording.
5. Exact-title deduplication against the context's existing rules.

If none of the cited articles exists in the database, generation falls back to the generic thematic mode — you are never left without a rule. The created rules receive the numbering IA-<contexto>-NNN.

Comprehensive mode — the entire code

By checking "Gerar todas as regras possíveis para o código", generation covers the complete code, anchored in the real articles:

1. The platform resolves the context's target database and loads the articles (number + text), up to the per-run article cap (the cut follows the article order and is recorded in the log).
2. The articles are processed in blocks (default 10 per block). Each block becomes an instruction with the real text of the provisions and each one's case law.
3. The blocks run in parallel (default 4 at a time), with flow control so as not to overload the model.
4. Semantic deduplication prevents recreating a similar rule — either an existing one or another generated in the same run.
5. A cap on rules created per run acts as a safeguard against an accidental runaway (it is not a product limit).

For a large code (the CPC has around 1,073 articles) the operation takes a few minutes — which is why it runs in the background with the progress screen: completed blocks and suggested/new/skipped rules in real time. At the end, the message reports how many rules were created and how many were skipped because a similar rule already exists.

Current case law in the rules

Cases are validated against the current case law — which is why the targeted and comprehensive modes take it into account whenever it exists in the database:

• For each article, the case law linked to it is loaded with a summarized headnote + court, up to 3 decisions per provision (to economize on the context sent to the model).
• When the article is marked with a divergent interpretation, the instruction signals that the rule must validate compliance according to the courts' consolidated interpretation, not just the provision's literal text.
• The instruction explicitly states that cases will be validated against the current case law.

Data prerequisite. Enrichment only happens if the context has case law ingested — the ingestion (DataJud, STJ Open Data, STF, TST) links the rulings to the article; see the case-law sources guide and the sources architecture. Without case law in the database, generation works normally, just without the enrichment.

No duplicates — semantic deduplication

To avoid recreating rules that already exist with different wording, each suggestion is compared against the base by similarity of meaning, not just of text:

• The platform generates each rule's vector (title + text) with the active embedding model — today Qwen3-Embedding-0.6B, with 1024 dimensions — in authenticated service calls.
• The context's existing rules are vectorized beforehand; each candidate is compared by cosine against the base and against those already accepted in the same run.
• Similarity at or above 0.85 (adjustable default) means "a similar one already exists" ⇒ the rule is not recreated.
• Vectors are L2-normalized before the comparison, which reduces the cosine to a dot product.
• Graceful degradation: if the vector service is unavailable, the candidate falls back to a lexical comparison (intersection/containment of the normalized title and text terms) — duplicate protection is never switched off.

The context name comes from configuration

The Screening Rules panel and Batch Screening always display the context's configured label, read from the platform settings (the context list returns the keys and their corresponding labels). The key remains the internal identifier — used for filtering, generation and sending to the server — but whoever reads the screen sees the human-readable name.

The context bar shows what actually has rules

The filter row at the top of the Screening Rules panel is built from two sources, queried at the same time:

• the contexts that have rules, derived from the registered rules themselves, each with its rule count;
• the registered contexts, which supply the display label and make a brand-new context show up with (0) so it can receive its first rule.

Every option shows the count in parentheses — FEBRABAN Conventions (15) — while All stays without a count. Hovering an option details how many rules are active and how many are inactive.

Previously the list came only from the context registry intersected with the visible-contexts list in settings. A context with rules that was missing from that list — or whose key was not a registered context — disappeared from the filter with no warning, taking its rules with it. The rule is now the opposite: a context that has rules always shows up. When one of them is not among the registered contexts the screen received, it says how many and which ones, right below the row, and points where to check — the context may not be registered, or may sit outside the visible list. The screen states the fact; it does not guess the cause.

Filtering and creating are different things: the filter lists everything that has rules, but picking the context of a new rule stays limited to the registered contexts. When editing an existing rule, the contexts it already carries show up ticked even if they fall outside that registry — so you can see them and take them off.

The counts follow every change: creating, editing, enabling/disabling or deleting rules updates the bar right away, with no page reload. Creating the first rule of a brand-new context makes it appear immediately.

When one of the two sources fails, the screen stays useful and explains what is missing: without the list of contexts that have rules it falls back to the registered ones and warns that counts are unavailable; without the registered list it shows the contexts that have rules by their own key. Only when neither answers does the error message appear, with a Try again button.

Generating and deleting require a chosen context

With the filter on All there is no target context, so Generate Rules with AI and the Delete ALL existing rules maintenance action ask you to pick a specific context in the filter bar. Previously both actions silently fell back to the first context in the list — including the destructive one, which deleted the rules of a context nobody had chosen.

After creating or editing rules — incremental screening

Created or changed a rule? There is no need to reprocess the entire caseload. In the Triagem Processual em Lote panel there is, besides "Triar apenas processos novos" and "Reprocessar todos", the option Apenas regras novas/atualizadas:

• The platform identifies the rules whose creation/update date is later than each case's last screening and re-evaluates only those rules, merging the result with the existing report (the case's other rules are not re-evaluated).
• Cases whose last screening already covers every current rule are marked as "já atualizados" (with their own counter in the panel) and are not reprocessed.
• It is faster and cheaper than "reprocess all" and keeps every case up to date with the rule that changed. It operates only on already screened cases — new cases stay in the "screen only new cases" mode.

Technical detail: incremental screening.

Maintenance — delete all rules (admin only)

The generation dialog contains no destructive actions. Bulk deletion lives in a separate place: next to + Nova Regra there is a maintenance gear, visible only to administrators, which opens the Manutenção de Regras dialog with the option Apagar TODAS as regras existentes — a destructive and irreversible operation that deletes every rule in the context and does not regenerate them.

• Explicit warning in the dialog before confirming.
• Mandatory reason (at least 10 characters): without a justification the button stays disabled.
• RULES_REPLACE_ALL permission, sensitive and exclusive to the administrator — RULES_DELETE and the other rule permissions do not enable this action. The server refuses non-admins regardless of what the interface shows.
• Fully audited: the act (how many rules, who deleted them and why) is recorded durably and atomically, in the same transaction as the deletion and in a system database — the trail is never lost, even if the central audit is down. It also generates a RULES.DELETE_ALL event visible in Sistema›Logs → Log do Sistema, under the AUDITORIA category (filterable), and sent to the platform's audit trail.

Worked example — cover the CPC, then refine

1. In Processar›Regras, select the "Código de Processo Civil" context and click Gerar Regras com IA.
2. Check "Gerar todas as regras possíveis para o código" and confirm. The progress screen shows the blocks advancing; close the dialog and come back later — generation keeps going.
3. At the end, the message summarizes the result: "128 regras criadas, 12 ignoradas por já existir regra parecida."
4. A week later, to reinforce a specific point, generate again with Foco específico = "prazos do agravo interno, art. 1021" and Quantidade de regras = 3. Only rules that do not yet exist get in.
5. Run batch screening in the Apenas regras novas/atualizadas mode to apply the new rules without reprocessing the caseload.

Operating parameters

All adjustable via environment variable, without a new build (prefix datta.rules.*):

Each context's target database is resolved dynamically from the platform configuration, with a fallback — contexts created by users resolve correctly, with no database name pinned in code. Every read respects the configuration cache.

Why the rules come out trustworthy

• The rule is anchored in the provision's real text, not in what the model "remembers".
• No context name is pinned in code — label and target database come from configuration.
• No duplicate rules, in every mode (including the thematic one), thanks to semantic deduplication with a lexical fallback.
• The AI does not fabricate rules to fill the requested quantity: if the code already has similar rules for everything, it creates fewer (or zero) and says so, instead of generating redundant variations.
• There is no artificial coverage limit — the entire code can be covered.
• Case law is taken into account, so validation reflects the courts' interpretation, not just the letter of the law.