Validating Normative References in Triage Rules

A triage rule that cites an article missing from your base produces flawed triage runs — and you only find out later, report by report. The Testar Referências da Regra button, in the Triage Rules panel, solves that before the rule ever runs: in one click you check whether every legal provision and every ruling cited in the rule actually exist in the selected contexts — and you can read the full text of each reference found (the complete article or the ruling's holding) without leaving the screen.

See also: AI rule generation, in the same panel; how case law gets into the base; and where the full text lives (a single search index per context, with pointers in the graph).

How it works

While editing a rule, click Testar Referências da Regra. The platform receives the rule text and its contexts, detects the references cited, looks each one up in every context of the rule and returns a summary:

• Counters of N found (green) and N missing (red).
• One line per reference, with its type (Artigo, Súmula, Jurisprudência) and the cited provision (e.g. Art. 966, Súmula Vinculante 10 do STF, REsp 1.234.567).
• Per context: a preview of about 150 characters and the Ver texto completo expander with the full text. A context that lacks the reference shows "Não encontrado no banco".

The validation is indicative: it helps you check that the rule cites provisions that exist in the context's base, but it does not block saving the rule.

If the rule has no context assigned, the test uses CPC as the default. References repeated in the text are tested once. The action requires the RULES_TEST permission — which the read-only profile already has — or an administrator profile.

What gets detected

Full article text — always present

For each article found, the platform resolves the full text in this order:

1. Text stored on the graph node itself (the historical form, from before the search indexes were unified).
2. Pointer to the search index: the article node keeps the index and the text identifier, and the platform retrieves the complete content through an internal lookup. The result is cached for 24 hours — the text of a norm is static data, so repeating the test is cheap.
3. The node's caption (a preview of about 200 characters) as a last resort.

This chain closes the gap created when the full text moved from the graph to the search index: before, the reference showed up as found, but without text.

Case law — the holding as text

Súmulas, appeals and themes are looked up in the case law of each context's base, and the holding is displayed as the full text:

• Matching by the unique number: by exact equality. Matching a fragment of the number is only allowed for long numbers (7 digits or more) — since the unique number is canonicalized to 20 digits in the CNJ standard, matching a 2- or 3-digit fragment (a súmula or theme number) would hit practically every ruling in the base.
• Súmulas require the ruling's decision type or source to contain "sumula"; the court, when cited in the rule, filters as well.
• A ruling found without a registered holding displays the message "Jurisprudência localizada (tribunal), sem ementa cadastrada no grafo." — the reference still counts as found.

Data prerequisite: detection only finds case law that has already been ingested into the context (DataJud, STJ Open Data, STF, TST — see the case law sources). Without ingestion, the mention shows as "Não encontrado no banco" — useful information, not an error.

Practical example

1. You are creating the rule "Verificar se a decisão observou o art. 966 do CPC e a Súmula 331 do TST" in the CPC context.
2. Click Testar Referências da Regra.
3. Result: Art. 966 — found, with the article text available via Ver texto completo; Súmula 331 do TST — "Não encontrado no banco", because the labor case-law base has not been ingested into that context yet.
4. You decide: adjust the rule to what exists in the base, or ask the administrator to ingest the missing source — before the rule runs against thousands of cases.

Graceful degradation

• If fetching the full text through the pointer fails, the test does not go down: the reference stays marked as found, just without the full text (the incident is recorded in the log as a warning).
• An access error on one context's base marks the reference as missing in that context and the test continues in the others — the test never breaks because one source failed.

The internal lookup that resolves the full text is restricted: it only accepts the platform's own indexes and never returns the semantic search vectors along with the text.

Known limitations

• Indicative, not binding: each lookup brings a single result; for case numbers with variable formatting, fragment matching may return a homonymous ruling. Check the displayed holding.
• Holding only: the ruling's full body is not retrieved (a future integration).
• Older bases with pre-unification pointers: bases loaded before the indexes were unified keep pointers to per-type indexes that are now closed (see the text mapping §3). In those cases the pointer lookup fails silently and the text falls back to the truncated caption, until a structured re-ingestion rewrites the pointers.
• The cited § / clause is not validated individually — only the article.

The reference test is also available through the API reference, which describes the body sent (the rule's text and contexts) and the response (the list of references per context, plus the totals of found and missing).