Decision Engine

O Decision Engine guarda as regras de negócio da sua empresa como tabelas de decisão em vez de código. Você descreve a política — "score acima de 700 e renda acima de 5 mil aprova até 20 mil" — como uma tabela com linhas e colunas, versiona essa tabela, publica a versão e chama uma API para obter a resposta.

Na prática isso muda quem manda na regra. Hoje, mudar um limite de crédito costuma significar abrir um chamado, esperar um desenvolvedor, esperar um code review e esperar a próxima janela de deploy. Com o Decision Engine, o analista de risco altera a tabela, cria a versão 1.4.0, publica, e a próxima requisição já usa a regra nova — sem que uma linha do seu aplicativo mude.

Está em produção desde março de 2026, é usado pelo Decision Platform como motor de avaliação e pelo Feature Flags para resolver pertencimento a segmentos.

O cenário. Uma financeira tem uma política de crédito. Essa política é um conjunto de faixas: score, renda, comprometimento, produto, canal. Ela muda o tempo todo — por decisão comercial, por pressão de inadimplência, por mudança de norma. E ela precisa ser explicável, porque alguém um dia vai perguntar por que aquele cliente foi negado.

O caminho que uma mudança de faixa percorre hoje, quando a política mora no código, é este:

flowchart LR
  subgraph Negocio["Quem entende a política"]
    A["Comitê de risco decide"]
  end
  subgraph Software["Quem controla o calendário"]
    B["Abre chamado"] --> C["Desenvolvedor traduz a regra em código"]
    C --> D["Code review"]
    D --> E["Fila de release"]
    E --> F["Janela de deploy"]
  end
  A --> B
  F --> G["A regra passa a valer"]

Nenhuma etapa entre a decisão e a janela de deploy tem a ver com risco de crédito. Todas elas são processo de software — e é o processo de software que define quando a política nova entra no ar.

O que trava hoje.

• A regra vive no código, então quem a muda é o desenvolvedor. O analista de risco, que é quem entende a política, não consegue nem ler o if aninhado que a implementa. A informação passa por tradução, e tradução perde coisa.
• Mudar a regra exige deploy. Um ajuste de faixa entra na fila de release junto com refatoração de banco e correção de bug. O tempo entre decidir e valer não é técnico, é de processo — e é medido em semanas.
• Não dá para dizer qual regra rodou. Seis meses depois, com dez deploys no meio, responder "qual era a política no dia 12 de março" significa arqueologia de Git. Se o cálculo mudou de lugar, nem isso resolve.
• Testar a política nova é caro. Sem separação entre a regra e o aplicativo, comparar a política nova contra a antiga exige subir dois ambientes.
• Adotar um BRMS comercial troca um problema por outro. Motores corporativos resolvem a governança, mas trazem licença por cotação, ciclo de implantação longo e um formato de regra que só roda dentro deles.

O custo de não resolver. O custo direto é a política que continua errada enquanto espera a fila de deploy — cada dia de atraso em apertar um critério de risco é carteira originada com a regra antiga. O custo indireto é a auditoria: sem log de qual versão avaliou qual proposta, a resposta ao regulador vira reconstrução manual. E há um custo regulatório concreto, porque o art. 20 da LGPD garante ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado, incluindo as que definem perfil de crédito — e revisar exige saber o que rodou.

A regra sai do código. Uma tabela de decisão tem entradas, saídas e linhas. Quem escreve política de crédito já pensa assim — a tabela é o formato natural, não uma tradução dele.

Publicar é o gatilho, não o deploy. Uma versão nasce DRAFT e não executa. Ela só passa a valer quando alguém com a permissão DECISION_VERSIONS_PUBLISH a publica. A separação entre escrever e valer é o controle que uma política de crédito exige.

São dois interruptores independentes, e a regra só responde quando os dois estão ligados:

flowchart LR
  W["Analista escreve a tabela DMN"] --> V["Versão nasce DRAFT"]
  V -->|"publish"| P["Versão PUBLISHED"]
  D["Decisão nasce DRAFT"] -->|"PATCH status ACTIVE"| DA["Decisão ACTIVE"]
  P --> X{"Os dois ligados?"}
  DA --> X
  X -->|"sim"| OK["A regra responde em produção"]
  X -->|"não"| ERR["HTTP 400"]

Toda execução deixa rastro. Cada chamada grava um ExecutionLog com a entrada, a saída, o tempo em milissegundos, quem executou e — o que mais importa — qual versão foi usada. Responder "por que este cliente foi negado" vira uma consulta.

O DMN inválido não entra. Ao criar uma versão, o serviço valida o XML contra o runner DMN antes de gravar. Você descobre o erro na hora de subir a regra, não na primeira proposta real.

O formato é aberto. DMN é um padrão da OMG, na versão 1.5 desde agosto de 2024. A tabela que você escreve aqui é um XML padronizado — ele sai daqui inteiro e roda em outro motor conforme. Isso não é detalhe técnico: é a diferença entre depender de um fornecedor e depender de um formato.

Panorama. O mercado de motores de regras se divide em três faixas. Na de cima estão as suítes corporativas — IBM ODM, FICO Blaze Advisor — que entregam governança completa, simulação e ferramenta de autoria para o analista, com preço por cotação e ciclo de implantação de projeto. No meio estão os motores open source operáveis — Camunda e Drools, este último hoje sob a Apache Software Foundation com licença Apache 2.0 — que resolvem a execução e transferem a operação, o versionamento e o multi-tenant para você. Embaixo estão as bibliotecas — json-rules-engine, GoRules — que embarcam no seu processo e não têm opinião sobre governança.

flowchart TD
  R["Como o mercado avalia regras hoje"] --> A["Faixa de cima: suítes corporativas"]
  R --> B["Faixa do meio: motores open source operáveis"]
  R --> C["Faixa de baixo: bibliotecas embarcáveis"]
  A --> A1["IBM ODM e FICO Blaze Advisor"]
  A1 --> A2["Governança, simulação e autoria completas — preço por cotação e implantação de projeto"]
  B --> B1["Camunda e Drools sob a Apache 2.0"]
  B1 --> B2["Resolvem a execução; operação, versionamento e multi-tenant ficam com você"]
  C --> C1["json-rules-engine e GoRules"]
  C1 --> C2["Embarcam no seu processo e não têm opinião sobre governança"]

O Decision Engine não tenta ser o motor mais rápido nem o modelador mais bonito. Ele pega um motor DMN maduro e coloca em volta dele o que falta para uso em produção regulada: versão, publicação, log por execução, isolamento por organização e autorização — tudo com o mesmo token dos outros 31 building blocks.

Nossos diferenciais

1. A governança vem junto, e não em volta. Versão, publicação, arquivamento e log de execução são endpoints do produto. Quem adota Camunda ou Drools recebe um avaliador de regras excelente e ainda precisa construir essas quatro coisas — que são justamente as que a auditoria pede.
2. O tenant é do token, não do modelo de dados. Toda rota exige organizationId no JWT e todo repositório filtra por ele. Num motor genérico, separar clientes é modelagem sua, e modelagem sua é onde vaza.
3. O formato é padrão, então a saída é barata. A regra é XML DMN da OMG, extraível por API. Isso é difícil de copiar não por ser tecnicamente complexo, mas porque o modelo de negócio da maioria dos concorrentes depende do custo de troca.
4. O motor é substituível por trás. O DmnProxyService fala com um runner DMN por HTTP através de uma interface de três operações — executar, validar e checar saúde. Trocar o runner não toca nenhuma rota, nenhum dado e nenhum cliente.

Quando escolher o concorrente.

flowchart TD
  Q1{"Seu analista precisa desenhar a tabela numa interface gráfica?"}
  Q1 -->|"sim, e o time não aceita modelar fora"| CAM["Camunda, a plataforma inteira"]
  Q1 -->|"não, ou aceita modelar no Modeler e subir o XML"| Q2
  Q2{"Precisa de simulação em lote, A/B de políticas e teste governado com aprovação formal?"}
  Q2 -->|"sim"| IBM["IBM ODM ou FICO Blaze Advisor"]
  Q2 -->|"não"| Q3
  Q3{"A regra é simples, cabe num serviço Node e dispensa versionamento e auditoria?"}
  Q3 -->|"sim"| JRE["json-rules-engine"]
  Q3 -->|"não"| Q4
  Q4{"Você já opera JVM e tem time para isso?"}
  Q4 -->|"sim"| DRO["Drools sob a Apache 2.0"]
  Q4 -->|"não"| CAT["Catalisa Decision Engine"]

Se o seu analista de negócio precisa desenhar a tabela numa interface gráfica, o Camunda Modeler é hoje a melhor ferramenta de autoria DMN do mercado e o Decision Engine não tem editor visual (§15) — o caminho honesto é modelar no Camunda Modeler e subir o XML aqui, mas se o seu time não aceita esse passo, use a plataforma deles inteira.

Se você precisa de simulação em lote, comparação A/B entre políticas e um ambiente de teste governado com aprovação formal, IBM ODM e FICO Blaze Advisor entregam isso há duas décadas e nós não entregamos.

Se a sua regra é simples, roda dentro de um único serviço Node e não precisa de versionamento nem auditoria, o json-rules-engine é gratuito, tem 17 kB e resolve em uma tarde — adotar um building block inteiro seria excesso. E se você já opera JVM e tem time para isso, o Drools sob a Apache 2.0 não custa licença nenhuma.

Unidade de cobrança. Precificação em definição. Quando definida, a unidade natural é a execução de decisão — é o que o cliente entende, é o que escala com o uso e é o que aparece no ExecutionLog.

O que dispara custo.

Comparação de custo. Cenário: operação com 500 mil execuções de decisão por mês e 20 decisões publicadas.

Comparação estruturada em 2026-08-16 a partir das páginas públicas dos fornecedores. Nenhum dos concorrentes comerciais publica preço — Camunda e IBM vendem por cotação. Não estimamos valores que não conseguimos verificar. Consulte cada fornecedor na data da sua análise.

ROI. A conta que fecha não é a de licença — o Drools é gratuito e vai ganhar de qualquer coisa nessa linha. O retorno está em dois lugares.

O primeiro é o que você não constrói: versionamento, publicação, log por execução e multi-tenant sobre um motor cru são um projeto de meses, e é um projeto que precisa ficar certo porque ele é o que a auditoria olha.

O segundo é o intervalo entre decidir e valer: numa carteira que origina 40 mil propostas por mês, cada semana de atraso em apertar um critério de risco é originação inteira com a regra que o comitê já decidiu abandonar. Esse número é seu e você sabe calculá-lo melhor que nós.

As camadas

O building block é um app Hono com basePath('/decision-engine'), uma camada de serviços em neverthrow e duas saídas: o PostgreSQL, por Prisma, e o runner DMN, por HTTP.

flowchart TD
  CLI["Cliente HTTP com Bearer JWT do IAM"] --> HONO

  subgraph HONO["Hono app — basePath /decision-engine"]
    MW["Toda rota: authMiddleware, requirePermission(P), requireOrganization"]
    R1["projectsRouter"]
    R2["decisionsRouter"]
    R3["versionsRouter"]
    R4["tagsRouter"]
    R5["executionLogsRouter"]
    R6["/health — sonda simples"]
  end

  HONO -->|"Zod parse, depois ResultAsync de T ou AppError"| SVC

  subgraph SVC["services/"]
    S1["ProjectService"]
    S2["DecisionService"]
    S3["VersionService"]
    S4["TagService"]
    S5["ExecutionLogService"]
    S6["DmnProxyService"]
  end

  SVC --> REPO["repositories/ com Prisma — PostgreSQL, schema decisions"]
  S6 -->|"HTTP"| RUNNER

  subgraph RUNNER["runner DMN em DMN_ENGINE_URL"]
    RU1["POST /api/v1/execute"]
    RU2["GET /health"]
    RU3["imagem decision-engine-runner — Camunda DMN, repositório à parte"]
  end

Os cinco routers e o que cada um monta:

E o que cada serviço faz:

O caminho de uma execução

Uma chamada a POST /decision-engine/api/v1/decisions/:decisionId/execute com { "input": { "age": 25 } } percorre seis etapas, e três delas podem interrompê-la:

sequenceDiagram
  autonumber
  actor C as Cliente
  participant H as Hono + middlewares
  participant DS as DecisionService
  participant DB as PostgreSQL
  participant PX as DmnProxyService
  participant RU as runner DMN
  participant EV as Barramento de eventos

  C->>H: POST /decisions/{id}/execute com input
  H->>DS: executeDecision após Zod parse
  DS->>DB: busca a Decision na organização do token
  alt Decision não existe
    DS-->>C: 404
  else Decision não está ACTIVE
    DS-->>C: 400 Decision is not active
  end
  DS->>DB: busca a DecisionVersion PUBLISHED mais recente
  alt Nenhuma versão publicada
    DS-->>C: 400 No published version available
  end
  DS->>PX: execute com o content da versão e o input
  PX->>RU: POST /api/v1/execute com dmnContent e data
  RU-->>PX: result, decisions e sucesso
  PX-->>DS: output, trace e executionTimeMs
  DS->>DB: grava ExecutionLog
  DS->>EV: publica decision-engine.decision.executed
  DS-->>C: 200 com output, trace, executionTimeMs e versionUsed

As mesmas seis etapas, com o que reprova cada uma:

A resposta de sucesso é 200 { output, trace, executionTimeMs, versionUsed }.

Decisão: o motor DMN é um processo separado, alcançado por HTTP

O DmnProxyService é a única porta de saída, com três operações: execute, validateDmn e healthCheck. O runner é a imagem decision-engine-runner, construída a partir de um repositório próprio (catalisaio/decision-engine-runner) e publicada no GHCR pelo workflow build-dmn-engine.yml. O motivo é isolamento de tecnologia: a avaliação DMN madura vive na JVM, o resto da plataforma é Bun e TypeScript, e essa fronteira mantém as duas coisas independentes. O custo aceito é uma chamada de rede por execução.

Decisão: o runner não conhece organização, e por isso não recebe nada persistido

Cada execução envia o XML DMN inteiro no corpo da requisição, junto com a entrada. O runner é stateless por construção — não há deploy de modelo, não há catálogo dentro dele, não há estado para vazar entre clientes. O custo é trafegar o XML a cada chamada; o ganho é que o isolamento entre tenants nunca depende do runner.

flowchart LR
  A["Catalisa guarda o XML em DecisionVersion.content"] -->|"envia XML + input a cada chamada"| B["runner DMN"]
  B -->|"result + trace"| A
  B --- C["Sem modelo implantado"]
  B --- D["Sem catálogo interno"]
  B --- E["Sem estado entre chamadas"]

Decisão: a validação do DMN acontece na criação da versão, não na execução

VersionService.createVersion chama validateDmn antes de gravar. Um XML quebrado falha para quem está subindo a regra, e não para o cliente final na primeira proposta. O trade-off é uma ida ao runner a cada versão criada, o que é irrelevante na frequência em que isso acontece.

Decisão: dois endpoints de execução, com propósitos diferentes

Executar uma decisão usa sempre a última versão publicada; executar uma versão usa aquela versão.

POST /versions/:id/execute é o caminho de teste: você escolhe a versão de propósito, inclusive uma que acabou de publicar, para comparar contra a anterior.

Decisão: só decisão ACTIVE executa

Uma Decision nasce DRAFT e precisa ser promovida a ACTIVE por PATCH. É um segundo interruptor, além da publicação da versão: escrever a tabela, publicar a versão e ligar a decisão são três atos deliberados. Isso irrita na primeira integração e evita o acidente na centésima.

Decisão: exclusão é lógica

Projetos, decisões, versões e tags usam deletedAt. O log de execução aponta para a versão, e a versão precisa sobreviver à remoção para que a auditoria continue reproduzível.

Monolito vs. standalone

Em monolito, o container TypeDI resolve os serviços por chamada direta. Em standalone — o modo usado em produção — o serviço sobe na porta 3005 com MODULE_SELF=decision-engine. Em qualquer um dos modos o runner DMN é sempre alcançado por HTTP: o DMN_ENGINE_URL é obrigatório nos dois.

Glossário

Modelo de dados — schema decisions no PostgreSQL.

Enumerações

Relacionamentos

erDiagram
  DecisionProject ||--o{ Decision : agrupa
  Decision ||--o{ DecisionVersion : versiona
  Decision ||--o{ DecisionTagLink : rotula
  DecisionTag ||--o{ DecisionTagLink : usada_em
  Decision ||--o{ ExecutionLog : registra
  DecisionVersion ||--o{ ExecutionLog : avaliou

  DecisionProject {
    uuid id PK
    uuid organization_id
    string key "único por organização"
    uuid owner_id
    datetime deleted_at
  }
  Decision {
    uuid id PK
    uuid organization_id
    uuid project_id FK
    string key "único por organização"
    enum status "DRAFT ACTIVE ARCHIVED"
    datetime deleted_at
  }
  DecisionVersion {
    uuid id PK
    uuid decision_id FK
    string version "semver, único por decisão"
    text content "o XML DMN"
    enum status "DRAFT PUBLISHED ARCHIVED"
    datetime published_at
  }
  DecisionTag {
    uuid id PK
    uuid organization_id
    string name "único por organização"
    string color "hex RRGGBB"
  }
  DecisionTagLink {
    uuid decision_id PK
    uuid tag_id PK
  }
  ExecutionLog {
    uuid id PK
    uuid decision_id FK
    uuid version_id FK
    json input
    json output
    int execution_time_ms
    uuid executed_by
  }

Repare que DecisionVersion e ExecutionLog não têm organization_id — o isolamento delas é por junção com a decisão dona. É um detalhe que reaparece em §14.

Ciclo de vida de uma decisão

A Decision é o interruptor de negócio: ela nasce em rascunho e alguém precisa ligá-la.

stateDiagram-v2
  [*] --> DRAFT: POST /decisions
  DRAFT --> ACTIVE: PATCH status ACTIVE
  ACTIVE --> ARCHIVED: PATCH status ARCHIVED
  ACTIVE --> ACTIVE: executa
  note right of ACTIVE
    Só decisão ACTIVE responde por
    execute da decisão
  end note

Ciclo de vida de uma versão

A DecisionVersion é o interruptor de conteúdo: ela guarda o XML e só vale depois de publicada.

stateDiagram-v2
  [*] --> DRAFT: POST versions
  DRAFT --> PUBLISHED: POST publish
  DRAFT --> ARCHIVED: POST archive
  PUBLISHED --> ARCHIVED: POST archive
  ARCHIVED --> [*]
  note left of DRAFT
    Não executa
  end note
  note right of PUBLISHED
    A mais recente publicada é a que
    responde por execute da decisão
  end note
  note right of ARCHIVED
    Não executa mais, e publicar de
    novo devolve 400
  end note

Juntando os dois interruptores:

flowchart LR
  A{"Decision.status == ACTIVE?"}
  A -->|"não"| E400A["400"]
  A -->|"sim"| B{"Existe DecisionVersion PUBLISHED?"}
  B -->|"não"| E400B["400"]
  B -->|"sim"| OK["Executa com a versão publicada mais recente"]

Publicar não despublica a anterior: várias versões podem estar PUBLISHED ao mesmo tempo, e o motor usa a mais recente. Para tirar uma do ar, arquive-a.

Prefixo: /decision-engine. Em staging, a base é https://decision-engine.bb.stg.catalisa.app.

Todas as rotas abaixo exigem: authMiddleware (Bearer JWT do IAM), o requirePermission indicado na coluna, e requireOrganization — token sem organizationId recebe 403 antes de a regra de negócio rodar.

Os corpos aceitam duas formas: JSON:API ({"data":{"attributes":{...}}}) ou o objeto direto ({...}). O código faz body.data?.attributes ?? body.

Os 25 endpoints se organizam em cinco grupos, e a única fronteira que confunde é a das duas rotas de execução:

flowchart LR
  API["/decision-engine/api/v1"] --> P["projects — 5 rotas"]
  API --> D["decisions — 6 rotas"]
  API --> V["versions — 6 rotas"]
  API --> T["tags — 5 rotas"]
  API --> L["execution-logs — 3 rotas"]
  D --> DE["POST /decisions/:decisionId/execute — produção"]
  V --> VE["POST /versions/:versionId/execute — teste"]

Projetos — /decision-engine/api/v1/projects

Decisões — /decision-engine/api/v1/decisions

As permissões desta tabela estão transcritas do código, não normalizadas. Repare que criar e atualizar decisão exigem DECISION_VERSIONS_CREATE e que excluir exige DECISION_PROJECTS_DELETE — não há permissão dedicada a decisões. Conceda os papéis com base nesta tabela, não no nome que a permissão sugere.

Filtros de GET /decisions: filter[projectId] (UUID), filter[status] (DRAFT, ACTIVE, ARCHIVED), filter[tagId] (UUID).

Versões — /decision-engine/api/v1

Filtro de listagem: filter[status] (DRAFT, PUBLISHED, ARCHIVED).

Tags — /decision-engine/api/v1/tags

Não há permissão de leitura separada para tags: ler exige a mesma DECISION_TAGS_MANAGE que escrever.

Logs de execução

Filtros: filter[decisionId], filter[versionId] (UUID), filter[from] e filter[to] (data ISO-8601).

O executionLogsRouter está montado em dois pontos (/api/v1/execution-logs e /api/v1), o que faz caminhos equivalentes responderem sob outros prefixos. Use apenas as três rotas da tabela — são as que a documentação sustenta.

Saúde

POST /decision-engine/api/v1/decisions/:decisionId/versions

Cria uma nova versão da decisão. O XML DMN é validado contra o runner antes de ser gravado.

Request

{
  "version": "1.0.0",
  "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><definitions ...>...</definitions>"
}

{
  "version": "1.0.0",
  "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><definitions ...>...</definitions>"
}

Resposta 201

{
  "data": {
    "type": "decision-versions",
    "id": "8f1c...",
    "links": { "self": "/api/v1/versions/8f1c..." },
    "attributes": {
      "decisionId": "3a2b...",
      "version": "1.0.0",
      "status": "DRAFT",
      "publishedAt": null
    }
  }
}

{
  "data": {
    "type": "decision-versions",
    "id": "8f1c...",
    "links": { "self": "/api/v1/versions/8f1c..." },
    "attributes": {
      "decisionId": "3a2b...",
      "version": "1.0.0",
      "status": "DRAFT",
      "publishedAt": null
    }
  }
}

Erros

POST /decision-engine/api/v1/decisions/:decisionId/execute

O endpoint de produção. Usa a versão publicada mais recente, sem que o chamador precise saber qual é.

Request

{ "input": { "age": 25, "score": 730, "renda": 5200 } }

{ "input": { "age": 25, "score": 730, "renda": 5200 } }

Resposta 200

{
  "output": { "result": "adult" },
  "trace": [
    {
      "decisionId": "age_check",
      "decisionName": "Age Check",
      "outcome": { "result": "adult" },
      "rulesEvaluated": [
        { "ruleId": "rule1", "triggered": true, "conditions": [">= 18"], "outcome": {} }
      ]
    }
  ],
  "executionTimeMs": 34,
  "versionUsed": "1.0.0"
}

{
  "output": { "result": "adult" },
  "trace": [
    {
      "decisionId": "age_check",
      "decisionName": "Age Check",
      "outcome": { "result": "adult" },
      "rulesEvaluated": [
        { "ruleId": "rule1", "triggered": true, "conditions": [">= 18"], "outcome": {} }
      ]
    }
  ],
  "executionTimeMs": 34,
  "versionUsed": "1.0.0"
}

O trace é a explicação da decisão: quais regras foram avaliadas e qual disparou. É o que responde "por que este cliente foi negado" — guarde-o.

Erros

Execução que falha não gera ExecutionLog. O registro só é gravado depois que o runner responde com sucesso. Para monitorar taxa de erro, use o log da aplicação e não a tabela — ver §15.

POST /decision-engine/api/v1/versions/:versionId/execute

O endpoint de teste. Executa a versão que você indicar, desde que ela esteja PUBLISHED. Mesmo corpo do anterior.

Resposta 200

{ "output": { "result": "adult" }, "executionTimeMs": 31 }

{ "output": { "result": "adult" }, "executionTimeMs": 31 }

Repare que esta rota não devolve trace nem versionUsed — você já sabe a versão, e a explicação não é retornada aqui. Se precisa do trace, use a rota da decisão.

Erros

Do zero à primeira decisão avaliada. Os comandos usam staging e a tabela DMN de exemplo é a mesma de scripts/test-dmn-staging.ts.

São sete passos, e o resultado do último é uma decisão avaliada com rastro gravado:

flowchart LR
  P1["1. Autenticar no IAM"] --> P2["2. Criar o projeto"]
  P2 --> P3["3. Criar a decisão"]
  P3 --> P4["4. Criar a versão com a tabela DMN"]
  P4 --> P5["5. Publicar a versão e ativar a decisão"]
  P5 --> P6["6. Executar"]
  P6 --> P7["7. Conferir o rastro"]

1. Autenticar no IAM

TOKEN=$(curl -s -X POST https://iam.bb.stg.catalisa.app/iam/api/v1/users/login \
  -H "Content-Type: application/json" \
  -d '{
    "email": "admin@test.com",
    "password": "password123",
    "organizationId": "b0000000-0000-0000-0000-000000000001"
  }' | jq -r .accessToken)

BASE=https://decision-engine.bb.stg.catalisa.app/decision-engine/api/v1

TOKEN=$(curl -s -X POST https://iam.bb.stg.catalisa.app/iam/api/v1/users/login \
  -H "Content-Type: application/json" \
  -d '{
    "email": "admin@test.com",
    "password": "password123",
    "organizationId": "b0000000-0000-0000-0000-000000000001"
  }' | jq -r .accessToken)

BASE=https://decision-engine.bb.stg.catalisa.app/decision-engine/api/v1

Confira que o token chegou antes de seguir — sem ele, todos os passos seguintes respondem 401:

echo "${TOKEN:0:12}..."
# eyJhbGciOiJI...

echo "${TOKEN:0:12}..."
# eyJhbGciOiJI...

2. Criar o projeto

PROJECT_ID=$(curl -s -X POST "$BASE/projects" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"Crédito","key":"credito","description":"Políticas de crédito"}' \
  | jq -r '.data.id')

PROJECT_ID=$(curl -s -X POST "$BASE/projects" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"Crédito","key":"credito","description":"Políticas de crédito"}' \
  | jq -r '.data.id')

Resposta esperada: o PROJECT_ID preenchido com o UUID do projeto recém-criado.

echo "$PROJECT_ID"
# 7c9e6679-7425-40de-944b-e07fc1f90ae7

echo "$PROJECT_ID"
# 7c9e6679-7425-40de-944b-e07fc1f90ae7

A key precisa casar com ^[a-z0-9-]+$ e é única na sua organização.

3. Criar a decisão

DECISION_ID=$(curl -s -X POST "$BASE/decisions" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d "{\"projectId\":\"$PROJECT_ID\",\"name\":\"Checagem de idade\",\"key\":\"checagem-idade\"}" \
  | jq -r '.data.id')

DECISION_ID=$(curl -s -X POST "$BASE/decisions" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d "{\"projectId\":\"$PROJECT_ID\",\"name\":\"Checagem de idade\",\"key\":\"checagem-idade\"}" \
  | jq -r '.data.id')

Resposta esperada: o DECISION_ID preenchido, e a decisão em rascunho.

curl -s "$BASE/decisions/$DECISION_ID" -H "Authorization: Bearer $TOKEN" \
  | jq -r '.data.attributes.status'
# "DRAFT"

curl -s "$BASE/decisions/$DECISION_ID" -H "Authorization: Bearer $TOKEN" \
  | jq -r '.data.attributes.status'
# "DRAFT"

Ela nasce DRAFT. Ainda não executa.

4. Criar a versão com a tabela DMN

Primeiro, escreva a tabela num arquivo. Esta é uma tabela mínima com duas regras e a hit policy FIRST:

cat > /tmp/age-check.dmn <<'DMN'
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
             id="definitions" name="Age Check"
             namespace="http://camunda.org/schema/1.0/dmn">
  <decision id="age_check" name="Age Check">
    <decisionTable id="decisionTable" hitPolicy="FIRST">
      <input id="input1" label="Age">
        <inputExpression id="inputExpression1" typeRef="integer"><text>age</text></inputExpression>
      </input>
      <output id="output1" label="Result" name="result" typeRef="string" />
      <rule id="rule1">
        <inputEntry id="ie1"><text>&gt;= 18</text></inputEntry>
        <outputEntry id="oe1"><text>"adult"</text></outputEntry>
      </rule>
      <rule id="rule2">
        <inputEntry id="ie2"><text>&lt; 18</text></inputEntry>
        <outputEntry id="oe2"><text>"minor"</text></outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>
DMN

cat > /tmp/age-check.dmn <<'DMN'
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
             id="definitions" name="Age Check"
             namespace="http://camunda.org/schema/1.0/dmn">
  <decision id="age_check" name="Age Check">
    <decisionTable id="decisionTable" hitPolicy="FIRST">
      <input id="input1" label="Age">
        <inputExpression id="inputExpression1" typeRef="integer"><text>age</text></inputExpression>
      </input>
      <output id="output1" label="Result" name="result" typeRef="string" />
      <rule id="rule1">
        <inputEntry id="ie1"><text>&gt;= 18</text></inputEntry>
        <outputEntry id="oe1"><text>"adult"</text></outputEntry>
      </rule>
      <rule id="rule2">
        <inputEntry id="ie2"><text>&lt; 18</text></inputEntry>
        <outputEntry id="oe2"><text>"minor"</text></outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>
DMN

Agora suba o arquivo como versão 1.0.0. O jq -Rs embrulha o XML inteiro como string JSON:

VERSION_ID=$(jq -Rs '{version:"1.0.0", content:.}' < /tmp/age-check.dmn \
  | curl -s -X POST "$BASE/decisions/$DECISION_ID/versions" \
      -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d @- \
  | jq -r '.data.id')

curl -s "$BASE/versions/$VERSION_ID" -H "Authorization: Bearer $TOKEN" \
  | jq -r '.data.attributes | "\(.version) \(.status)"'
# 1.0.0 DRAFT

VERSION_ID=$(jq -Rs '{version:"1.0.0", content:.}' < /tmp/age-check.dmn \
  | curl -s -X POST "$BASE/decisions/$DECISION_ID/versions" \
      -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d @- \
  | jq -r '.data.id')

curl -s "$BASE/versions/$VERSION_ID" -H "Authorization: Bearer $TOKEN" \
  | jq -r '.data.attributes | "\(.version) \(.status)"'
# 1.0.0 DRAFT

Se o XML estiver quebrado, você recebe 400 aqui — antes de qualquer proposta real chegar.

5. Publicar a versão e ativar a decisão

Ligue o primeiro interruptor, o da versão:

curl -s -X POST "$BASE/versions/$VERSION_ID/publish" \
  -H "Authorization: Bearer $TOKEN" | jq '.data.attributes.status'
# "PUBLISHED"

curl -s -X POST "$BASE/versions/$VERSION_ID/publish" \
  -H "Authorization: Bearer $TOKEN" | jq '.data.attributes.status'
# "PUBLISHED"

Depois o segundo, o da decisão:

curl -s -X PATCH "$BASE/decisions/$DECISION_ID" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"status":"ACTIVE"}' | jq '.data.attributes.status'
# "ACTIVE"

curl -s -X PATCH "$BASE/decisions/$DECISION_ID" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"status":"ACTIVE"}' | jq '.data.attributes.status'
# "ACTIVE"

São dois interruptores separados, e os dois precisam estar ligados.

6. Executar

curl -s -X POST "$BASE/decisions/$DECISION_ID/execute" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"input":{"age":25}}' | jq

curl -s -X POST "$BASE/decisions/$DECISION_ID/execute" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"input":{"age":25}}' | jq

{
  "output": { "result": "adult" },
  "trace": [ { "decisionId": "age_check", "decisionName": "Age Check", "...": "..." } ],
  "executionTimeMs": 34,
  "versionUsed": "1.0.0"
}

{
  "output": { "result": "adult" },
  "trace": [ { "decisionId": "age_check", "decisionName": "Age Check", "...": "..." } ],
  "executionTimeMs": 34,
  "versionUsed": "1.0.0"
}

7. Conferir o rastro

curl -s "$BASE/decisions/$DECISION_ID/execution-logs" \
  -H "Authorization: Bearer $TOKEN" | jq '.data[0].attributes | {versionId, input, executionTimeMs}'

curl -s "$BASE/decisions/$DECISION_ID/execution-logs" \
  -H "Authorization: Bearer $TOKEN" | jq '.data[0].attributes | {versionId, input, executionTimeMs}'

Resposta esperada — a execução do passo 6, com a versão que a avaliou:

{
  "versionId": "8f1c...",
  "input": { "age": 25 },
  "executionTimeMs": 34
}

{
  "versionId": "8f1c...",
  "input": { "age": 25 },
  "executionTimeMs": 34
}

Credenciais de staging, conforme AMBIENTES.md. Nunca use credencial de produção em documentação ou script de exemplo.

Trocar a política sem derrubar quem está integrado

O objetivo é substituir a regra vigente com verificação antes de ela valer.

flowchart LR
  A["1. Nova versão em DRAFT"] --> B["2. Publicar"]
  B --> C["3. Conferir com a versão fixada"]
  C -->|"passou"| D["Fim — a nova responde em produção"]
  C -->|"não passou"| E["4. Arquivar a nova"]
  E --> F["A anterior volta a ser a mais recente publicada"]

Passo 1. Crie a nova versão a partir do DMN revisado. Ela nasce DRAFT e não afeta produção:

VERSION_ID=$(jq -Rs '{version:"1.1.0", content:.}' < politica-revisada.dmn \
  | curl -s -X POST "$BASE/decisions/$DECISION_ID/versions" \
      -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d @- \
  | jq -r '.data.id')

VERSION_ID=$(jq -Rs '{version:"1.1.0", content:.}' < politica-revisada.dmn \
  | curl -s -X POST "$BASE/decisions/$DECISION_ID/versions" \
      -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d @- \
  | jq -r '.data.id')

Resposta esperada: um UUID em $VERSION_ID. Se vier vazio, o DMN foi recusado na validação.

Passo 2. Publique. A partir daqui ela é a mais recente publicada:

curl -s -X POST "$BASE/versions/$VERSION_ID/publish" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes.status'
# "PUBLISHED"

curl -s -X POST "$BASE/versions/$VERSION_ID/publish" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes.status'
# "PUBLISHED"

Passo 3. Confira contra um caso conhecido, agora com a versão fixada:

curl -s -X POST "$BASE/versions/$VERSION_ID/execute" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"input":{"age":25}}' | jq

curl -s -X POST "$BASE/versions/$VERSION_ID/execute" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"input":{"age":25}}' | jq

{ "output": { "result": "adult" }, "executionTimeMs": 31 }

{ "output": { "result": "adult" }, "executionTimeMs": 31 }

Passo 4. Deu errado? Arquive a nova. A anterior volta a ser a mais recente publicada:

curl -s -X POST "$BASE/versions/$VERSION_ID/archive" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes.status'
# "ARCHIVED"

curl -s -X POST "$BASE/versions/$VERSION_ID/archive" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes.status'
# "ARCHIVED"

Armadilhas.

• Publicar já muda produção. Não existe "publicar em homologação". A partir do passo 2 a versão nova está no ar, e a validação do passo 3 é depois. Para validar antes, mantenha uma decisão separada de ensaio ou valide numa organização de staging.
• Publicar não despublica a anterior. Várias versões podem estar PUBLISHED ao mesmo tempo. O motor usa a mais recente. O jeito de voltar atrás é arquivar a nova, não republicar a antiga — republicar retorna 409, porque ela já está publicada.
• Semver é obrigatório e imutável. 1.1 é rejeitado; precisa ser 1.1.0. E não há edição de versão: uma versão publicada nunca muda, o que é o ponto.

Descobrir por que uma proposta foi negada

O objetivo é sair de "esse cliente foi negado" até a tabela exata que o negou, em três consultas.

flowchart LR
  A["Execuções da janela de tempo"] --> B["Entrada e saída daquela execução"]
  B --> C["XML DMN da versão que rodou"]

Passo 1. Ache a execução pelo intervalo de tempo:

curl -s "$BASE/decisions/$DECISION_ID/execution-logs?filter[from]=2026-08-01" \
  -H "Authorization: Bearer $TOKEN" | jq '.data[] | {id, versionId: .attributes.versionId}'

curl -s "$BASE/decisions/$DECISION_ID/execution-logs?filter[from]=2026-08-01" \
  -H "Authorization: Bearer $TOKEN" | jq '.data[] | {id, versionId: .attributes.versionId}'

{ "id": "1b2c...", "versionId": "8f1c..." }

{ "id": "1b2c...", "versionId": "8f1c..." }

Passo 2. Leia entrada e saída daquela execução:

curl -s "$BASE/execution-logs/$LOG_ID" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes | {input, output, executionTimeMs}'

curl -s "$BASE/execution-logs/$LOG_ID" -H "Authorization: Bearer $TOKEN" \
  | jq '.data.attributes | {input, output, executionTimeMs}'

Passo 3. Recupere a tabela que rodou naquele momento:

curl -s "$BASE/versions/$VERSION_ID" -H "Authorization: Bearer $TOKEN" | jq -r '.content'

curl -s "$BASE/versions/$VERSION_ID" -H "Authorization: Bearer $TOKEN" | jq -r '.content'

A saída é o XML DMN inteiro — a mesma tabela que avaliou a proposta, legível e anexável a um processo.

Armadilhas. O output gravado por /decisions/:id/execute tem a forma {"result": ..., "trace": [...]}, enquanto o gravado por /versions/:id/execute guarda a saída direta, sem envelope. Se você consome os logs programaticamente, trate as duas formas. E lembre que execução que falhou não tem log — a ausência de registro não significa que ninguém chamou.

Exportar todas as suas regras

Útil em auditoria, em backup e antes de qualquer conversa sobre migração. O laço abaixo percorre as decisões da organização, e dentro de cada uma as versões publicadas, gravando um .dmn por versão:

for D in $(curl -s "$BASE/decisions?page[size]=100" -H "Authorization: Bearer $TOKEN" \
             | jq -r '.data[].id'); do
  for V in $(curl -s "$BASE/decisions/$D/versions?filter[status]=PUBLISHED" \
               -H "Authorization: Bearer $TOKEN" | jq -r '.data[].id'); do
    curl -s "$BASE/versions/$V" -H "Authorization: Bearer $TOKEN" \
      | jq -r '.content' > "dmn/${D}_${V}.dmn"
  done
done

for D in $(curl -s "$BASE/decisions?page[size]=100" -H "Authorization: Bearer $TOKEN" \
             | jq -r '.data[].id'); do
  for V in $(curl -s "$BASE/decisions/$D/versions?filter[status]=PUBLISHED" \
               -H "Authorization: Bearer $TOKEN" | jq -r '.data[].id'); do
    curl -s "$BASE/versions/$V" -H "Authorization: Bearer $TOKEN" \
      | jq -r '.content' > "dmn/${D}_${V}.dmn"
  done
done

Ao final, o diretório dmn/ tem um arquivo por versão publicada, nomeado {decisionId}_{versionId}.dmn.

Armadilhas. O XML sai íntegro e é DMN padrão — ele abre no Camunda Modeler e roda em qualquer motor conforme. Paginação padrão é 20 itens; passe page[size] até 100.

Modelar a tabela numa interface visual

O Decision Engine não tem editor gráfico (§15). O caminho prático:

1. Modele a tabela no Camunda Modeler (gratuito para desenho) ou em qualquer editor DMN.
2. Exporte o .dmn.
3. Suba o arquivo pela rota de criação de versão, como no início rápido.

Armadilhas. Use o namespace do exemplo (https://www.omg.org/spec/DMN/20191111/MODEL/) — é o que o runner espera. Recursos DMN de nível de conformidade mais alto, como decisões encadeadas dentro do mesmo arquivo, dependem do runner e não estão cobertos por teste nosso: valide criando a versão, porque a validação acontece ali.

A fronteira que mais gera dúvida: Decision Engine ou Decision Platform?

Em uma frase: o Decision Engine é a regra; o Decision Platform é a esteira que leva os dados até ela. A Platform não substitui o Engine — ela o consome. Toda execução de esteira termina numa tabela DMN que vive aqui.

flowchart TD
  AN["Analista de risco"] -->|"escreve a tabela"| DE

  subgraph DE["Decision Engine — a REGRA"]
    P["Project"] --> D["Decision"] --> V["DecisionVersion com XML DMN em semver"]
    V --> PX["DmnProxyService"]
  end

  PX -->|"HTTP"| RU["runner DMN — Camunda DMN"]

  DP["Decision Platform — busca os dados e chama a regra"] -->|"consome como avaliador"| DE
  FF["Feature Flags"] -->|"avalia DMN de segmento pela facade"| DE

A seta que importa comercialmente é a primeira: quem escreve a regra é o analista de negócio, e não o desenvolvedor. É o mesmo XML em toda a cadeia.

Variáveis de ambiente

Dependências de infraestrutura

O Redis não é dependência deste building block.

Limites

Catálogo de erros

Observabilidade.

• GET /decision-engine/health responde com nome e versão do build. É uma sonda de vida do processo — ela não verifica o runner DMN nem o banco. Para saber se o runner está de pé, use o /health do próprio runner (DMN_ENGINE_URL).
• O DmnProxyService loga cada execução em nível debug com tempo e decisionId, e cada falha em error com a mensagem do runner. É por aí que se monitora latência do motor.
• A tabela decisions.execution_logs é a fonte de verdade para volume, latência (executionTimeMs) e distribuição de versões em uso. Ela só registra sucesso (§15).
• Eventos publicados: decision-engine.project.{created,updated,deleted}, decision-engine.decision.{created,updated,deleted,executed}, decision-engine.version.{created,published,archived}, decision-engine.tag.{created,updated,deleted}.

Os mesmos eventos, agrupados por recurso:

Isolamento entre tenants

Toda rota aplica o requireOrganization local, que devolve 403 quando o token não traz organizationId. O organizationId nunca é lido do corpo da requisição — ele vem do claim assinado.

flowchart TD
  T["Bearer JWT do IAM"] --> A["authMiddleware valida a assinatura"]
  A --> P["requirePermission verifica a permissão da rota"]
  P --> O{"O token traz organizationId?"}
  O -->|"não"| F403["403 Organization context required"]
  O -->|"sim"| S["Serviço recebe o organizationId do claim, nunca do corpo"]
  S --> R["Repositório filtra por organização"]

No acesso a dados, DecisionProject, Decision e DecisionTag carregam a coluna organization_id e os repositórios filtram por ela em toda consulta. Os modelos se dividem, então, em dois grupos:

DecisionVersion não tem a coluna: o isolamento dela vem da decisão dona. Fora do escopo, a resposta é 404, igual a um id inexistente — um 403 confirmaria a quem pergunta que o recurso existe.

Isolamento entre os clientes de um revendedor (subcontas)

Quem revende o motor como SaaS atende cada cliente como uma subconta dentro da própria organização. Aí o organizationId sozinho não separa mais nada, porque todos os clientes o compartilham: a fronteira passa a ser a subconta, resolvida pela chave de API presa a ela ou pelo header X-Subaccount-Id da chave da organização.

Linhas criadas antes das subcontas têm subaccount_id nulo, o que quer dizer "da organização" — exatamente quem era dono delas.

A catraca é tests/integration/decision-platform/subaccount-isolation.integration.test.ts, que cobre os dois building blocks: dois clientes montam a mesma coisa, com as mesmas chaves, num Postgres real, e cada um tenta todas as portas do outro.

O runner DMN não guarda nada

Cada execução envia o XML e a entrada no corpo da requisição. O runner é stateless: não há modelo implantado, não há catálogo e não há sessão. Isso significa que ele não é um ponto onde dados de um cliente possam vazar para outro — porque ele não retém dados de cliente nenhum.

Dados sensíveis no log de execução

O ExecutionLog grava a entrada completa da decisão em JSON. Numa esteira de crédito isso inclui, tipicamente, CPF, renda e score — dado pessoal sob a LGPD.

Trate o schema decisions como base que contém dado pessoal: controle de acesso ao banco, criptografia em repouso no volume e um processo de expurgo definido por você.

Explicabilidade da decisão automatizada

O art. 20 da LGPD assegura ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses — incluindo, expressamente, as que definem perfil de crédito. O ExecutionLog com versionId, entrada, saída e trace das regras avaliadas é a base factual para atender a esse pedido: ele diz qual tabela rodou, com que dados e qual linha disparou. A conformidade não é automática — o processo de revisão é seu —, mas o registro que ele exige existe.

Autenticação e permissões

Bearer JWT emitido pelo IAM. As permissões usadas são DECISION_PROJECTS_{CREATE,READ,UPDATE,DELETE}, DECISION_VERSIONS_{CREATE,READ,PUBLISH}, DECISION_TAGS_MANAGE, DECISION_LOGS_READ e DECISION_EXECUTE. Separe DECISION_VERSIONS_PUBLISH do resto ao desenhar papéis: publicar é o ato que muda a política em produção, e deve exigir mais gente do que escrever um rascunho.

Exclusão lógica

Projetos, decisões, versões e tags usam deletedAt. A linha permanece para que o log de execução continue apontando para uma versão existente. Atender a um pedido de eliminação sob a LGPD exige processo explícito de expurgo, hoje não automatizado.

Qual é a diferença entre o Decision Engine e o Decision Platform, em uma frase?

O Decision Engine é a regra; o Decision Platform é a esteira que busca os dados e leva até a regra. Se você já tem todos os dados de entrada, chame o Engine direto. Se alguém precisa consultar um bureau, ler um arquivo ou puxar de uma fila antes de decidir, é a Platform — e ela vai terminar chamando uma tabela que vive aqui de qualquer jeito.

flowchart LR
  Q{"Você já tem todos os dados de entrada em mãos?"}
  Q -->|"sim"| DE["Decision Engine — manda o input e recebe a resposta"]
  Q -->|"não, alguém precisa buscar antes"| DP["Decision Platform — a esteira"]
  DP -->|"termina chamando"| DE

Preciso saber DMN para usar?

Precisa entender o que é uma tabela de decisão, o que é fácil. Escrever o XML na mão é chato, e não é o caminho recomendado: modele no Camunda Modeler ou em outro editor DMN, exporte o .dmn e suba o arquivo. A recompensa de aprender o formato é que ele é padrão da OMG e a sua regra não fica presa a nenhum fornecedor, incluindo nós.

Se eu publicar uma versão errada, como volto atrás?

Arquivando a versão errada, com POST /versions/:versionId/archive. A anterior volta a ser a mais recente publicada automaticamente. Não tente republicar a antiga — ela já está PUBLISHED e o serviço responde 409.

Por que a minha decisão retorna 400 mesmo com a versão publicada?

Quase sempre porque a Decision está DRAFT. São dois interruptores independentes: a versão precisa estar PUBLISHED e a decisão precisa estar ACTIVE. Faça PATCH /decisions/:decisionId com {"status":"ACTIVE"}.

Como respondo a um pedido de revisão de decisão automatizada sob a LGPD?

Pelo ExecutionLog. Ele guarda a entrada exata, a saída, o trace das regras avaliadas e o versionId. Com o versionId, GET /versions/:versionId devolve o XML DMN que rodou — a tabela em si, legível, não uma reconstrução a partir de código. O registro existe; o processo de revisão humana é responsabilidade sua.

As minhas regras ficam presas na Catalisa?

Não. O que armazenamos em DecisionVersion.content é o XML DMN cru, e GET /versions/:versionId devolve ele inteiro. A receita de exportação em massa está em §11. Sair daqui custa o tempo de baixar os arquivos.

Qual motor DMN roda por trás?

Um runner baseado em Camunda DMN, empacotado como a imagem decision-engine-runner e mantido em repositório próprio. Ele é alcançado por HTTP através do DmnProxyService, com três operações. Isso torna o motor substituível sem impacto nas rotas — e é por isso que a documentação fala em "runner DMN" e não no nome de um fornecedor.

Quanto tempo demora uma execução?

Depende do tamanho da tabela e da latência até o runner, e o número que importa é o seu. Cada resposta traz executionTimeMs e cada ExecutionLog grava o valor, então medir o seu p95 é uma consulta ao banco. Não publicamos número de laboratório porque ele não sobrevive ao seu ambiente.

Dá para encadear decisões, com uma alimentando a outra?

Dentro de um mesmo arquivo DMN, isso depende do nível de conformidade do runner e não está coberto pelos nossos testes — valide criando a versão, já que a validação acontece ali. Entre decisões separadas, o building block não encadeia: quem orquestra sequência é o Decision Platform, e mesmo ele executa uma decisão por config.

Posso usar isto fora de crédito?

Pode, e faz sentido em qualquer lugar onde a regra muda mais rápido que o software: aceitação de seguro, elegibilidade em saúde, aprovação de desconto no varejo, roteamento de atendimento. O building block não sabe o que é crédito — ele avalia tabelas.

_{Padrão: PADRAO-DOCUMENTACAO.md · Índice: INDEX.md}