Anomaly types
TL;DR: the Tipos de anomalia tab, inside Processar → Regras, administers the classification screening uses. The level states the severity of an outcome; the types nested under it are each context's nominal taxonomy. The list the model sees is assembled from here — editing on this screen changes screening results, with no deployment.
Where it lives
Processar → Regras, Tipos de anomalia tab. Read permission shows the classification; changing it requires the same permission as editing rules.
Level and type — the distinction that matters
A level is severity. The platform ships with four, matching the verdict screening writes into the report:
| Level | Means | Colour |
|---|---|---|
| Sem contexto | Not enough data in the case file to evaluate the rule | neutral |
| Conforme | The case complies with the rule | green |
| Anomalia | The rule was breached | amber |
| Anomalia crítica | Serious breach, compromising the validity of the act | red |
These four carry the padrão badge and cannot be deleted — the report, the workflow engine and verdict consolidation read exactly these classifications, and removing them would make screening stop recognising its own result. Renaming, recolouring and deactivating remain available, and custom levels can be created.
A type is the nature of the anomaly — Retrocesso de Rito, Prazo Vencido, Incompetência. Each type belongs to one level and applies to one context, because one domain's taxonomy does not describe another's. When creating a type you pick the context; moving a type between levels replaces the previous link rather than adding a second one.
What screening does with it
The list of active types for the context is offered to the model at analysis time, as the options it may pick when describing an anomaly. Two practical consequences:
- A context with no registered types leaves the field free: the model describes the anomaly in its own words, which was the previous behaviour of every domain except civil procedure.
- Deactivating a type removes it from the options without erasing history — older reports citing it remain readable.
Declaring the outcome on the rule
Each rule declares which level each result produces, under Resultado da regra, in both the create and the edit form:
| Outcome | Default |
|---|---|
| When the rule is met | Conforme |
| When the case file lacks data | Sem contexto |
| When the rule is breached | Anomalia |
This is how a critical rule comes to produce Anomalia crítica without depending on the model to choose severity. Rules created before this screen keep the defaults above, with no migration needed.
Everything the screen does is also available through the API — the endpoints live in the API reference section. Every change emits an audit event and shows up in the System Log.
Anti-patterns
- Deleting a level to "tidy up" the list: deactivate it instead, otherwise rules declaring it start pointing at a classification that no longer exists.
- Creating the same type across contexts under slightly different names — the report becomes incomparable between domains.
- Treating the level as a thematic category. Severity is severity; the nature of the anomaly is the type.