Análise Forense

A Análise Forense é a verificação antifraude da Dynadok. Ela examina o arquivo de um documento — metadados, estrutura interna do PDF, pixels da imagem, leitura visual dos campos, tipografia e coerência entre os valores impressos — em busca de indícios de manipulação, e devolve um laudo com o resultado de cada verificação.

Ela não tem rota própria: roda dentro do processamento do documento, quando a regra FORENSIC_ANALYSIS está ligada para ele. O laudo volta no próprio documento, nos validationCheckpoints com origin: "FORENSIC_ANALYSIS" (ver O que são os checkpoints). Quando um achado da análise alcança o corte configurado, o documento vai para INTEGRITY_REVIEW e aguarda conferência humana.

O laudo não afirma fraude. Ele mede possibilidade: INTEGRITY_REVIEW quer dizer que uma pessoa precisa olhar o documento, não que ele seja falso.

Rotas

A análise acompanha as rotas de documento descritas em Documentos:

método e rota	papel na Análise Forense
`POST /v1/api/documents`	envia um documento avulso; a análise roda se o envio trouxer a regra no campo `rules`
`POST /v1/api/competencies/{competencyId}/participants/{participantId}/documents`	envia o documento de um participante; vale a regra configurada no documento solicitado pela competência
`GET /v1/api/documents/{_id}`	documento avulso, com o laudo
`GET /v1/api/participant-documents/{participantDocumentId}`	documento de participante, com o laudo

Todas exigem a x-api-key (ver Autenticação).

Antes do primeiro envio

A Análise Forense precisa estar habilitada para a sua empresa. Peça a habilitação ao seu contato na Dynadok. Sem ela, a regra não aparece na configuração de documentos da plataforma.

Há dois jeitos de usar:

Avulsa — você envia o arquivo por POST /v1/api/documents com a regra FORENSIC_ANALYSIS no campo rules. Documento avulso não tem configuração própria: sem a regra no envio, a análise não roda. Ver Enviar um documento avulso com a análise.
Por participante — a regra fica configurada, na plataforma, no documento solicitado pela competência. Todo envio daquele documento é analisado, venha ele do portal do participante, da equipe ou da API. Ver Análise de um participante.

A análise vale para documentos enviados como arquivo (PDF ou imagem). Campos de formulário — texto, número, data — não têm arquivo e não passam por ela. Ela roda depois da leitura e das validações de conteúdo: documento reprovado nessas etapas não chega a ser analisado.

A regra `FORENSIC_ANALYSIS`

A regra tem três propriedades. Pela API, cada uma é um item do array rules, todos com "type": "FORENSIC_ANALYSIS" (o formato do campo está em Aplicar regras de validação por requisição):

`inputName`	valores (`inputValue`)	padrão na plataforma	efeito
`FORENSIC_ANALYSIS_VALIDATE`	`["validate"]` ou `["ignore"]`	`ignore`	liga a análise. Só `validate` liga
`FORENSIC_ANALYSIS_MODE`	`["sync"]` ou `["async"]`	`async`	se o documento espera o laudo para concluir. Ver Síncrona ou assíncrona
`FORENSIC_ANALYSIS_MINIMUM_SCORE`	um inteiro de `0` a `100`, como texto (`["60"]`)	`60`	o corte: a partir dele um achado leva o documento a `INTEGRITY_REVIEW`. Ver O corte

Pela API, com validate, os três itens são obrigatórios: sem FORENSIC_ANALYSIS_MODE ou sem FORENSIC_ANALYSIS_MINIMUM_SCORE, a requisição volta 400 e o documento não é criado.

As opções de FORENSIC_ANALYSIS_VALIDATE e de FORENSIC_ANALYSIS_MODE são validadas e escritas em minúsculas. "VALIDATE", "true" ou um inputName com erro de digitação também respondem 400 (ver Erros típicos).

Corte inválido vale 60, sem erro

O corte não é validado. Um valor que não seja inteiro de 0 a 100 ("60.5", "alto", "") é aceito e o documento é analisado com o padrão, 60.

Na plataforma, a regra aparece como Análise Forense, com três campos:

Tipo: "Ignorar análise" ou "Realizar análise";
Selecione o método: "Assíncrona — Processamento em segundo plano" ou "Síncrona — Resposta imediata";
Alertar quando o % do score de risco for maior que: o corte, com padrão 60. A comparação inclui o próprio valor: um achado com score igual ao corte já pede revisão.

Síncrona ou assíncrona

	`async`	`sync`
o documento conclui	sem esperar a análise	só depois do laudo
o laudo chega	depois do processamento (ver Webhook)	junto, no `*_PROCESSED`
se a análise não concluir	fica registrado no laudo; o documento segue	o documento é reprovado (`REJECTED`)

A análise costuma levar menos de um minuto por documento; arquivos com muitas páginas levam mais. No modo síncrono esse tempo se soma ao do processamento.

Use sync quando a sua decisão sobre o documento depende do laudo e você quer recebê-lo de uma vez, no *_PROCESSED — é o modo indicado para documento de participante. Use async quando o resultado das demais validações não pode esperar a análise.

O corte

Cada técnica avalia de 0 a 100 a possibilidade de manipulação do que encontrou. O documento vai para revisão quando um achado com peso para decidir alcança o corte. Nem toda técnica decide sozinha: algumas servem de apoio a outras e, sem confirmação, ficam só registradas no laudo, como INFO, com o motivo em details.

Corte menor manda mais documentos para revisão: pega mais casos, com mais revisões de documento legítimo.
Corte maior manda menos: menos revisão, com mais risco de deixar passar um documento adulterado.

O padrão é 60. O score não vem na API: o que você vê é o efeito dele, o status INTEGRITY_REVIEW e os achados em ALERT no laudo.

Enviar um documento avulso com a análise

Requisição multipart/form-data, como em Enviar um documento avulso, com os três itens da regra no campo rules — uma string JSON com o array inteiro, num único campo de formulário:

curl --request POST 'https://api.dynadok.com/v1/api/documents' \
  --header 'x-api-key: 550e8400-e29b-41d4-a716-446655440000.SUA_CHAVE' \
  --form 'files=@"/caminho/comprovante.pdf"' \
  --form 'type="COMPROVANTE_RESIDENCIA"' \
  --form 'rules="[{\"type\":\"FORENSIC_ANALYSIS\",\"inputName\":\"FORENSIC_ANALYSIS_VALIDATE\",\"inputValue\":[\"validate\"]},{\"type\":\"FORENSIC_ANALYSIS\",\"inputName\":\"FORENSIC_ANALYSIS_MODE\",\"inputValue\":[\"sync\"]},{\"type\":\"FORENSIC_ANALYSIS\",\"inputName\":\"FORENSIC_ANALYSIS_MINIMUM_SCORE\",\"inputValue\":[\"60\"]}]"'

Para combinar com outras regras, inclua todas no mesmo array — por exemplo, a Análise Forense junto com Data de validade. Um campo rules por regra, ou chaves como rules[0][type], são descartados sem erro, e o documento sai sem análise (ver a armadilha em Documentos).

A resposta vem na hora, com o documento em PROCESSING — igual a qualquer envio avulso. Guarde o _id.

No envio avulso, o arquivo é convertido para PDF antes do processamento, e a análise examina esse PDF, e não o arquivo enviado.

Acompanhar a análise

O que são os checkpoints

Todo documento processado traz em validationCheckpoints a lista das verificações por que passou: leitura do conteúdo, regras configuradas, conferência na fonte oficial, Análise Forense. Cada checkpoint é uma verificação com o seu resultado. Os steps dentro dele são as etapas dessa verificação, cada uma com o próprio resultado.

campo do checkpoint	o que traz
`description`	o nome da verificação, em português
`status`	o resultado: `VALID` (passou), `ALERT` (achado que pode pedir revisão humana), `WARNING` (aviso, sem reprovar), `ISSUE` (reprovou o documento) ou `INFO` (informativo)
`origin`	qual verificação produziu o checkpoint (tabela abaixo)
`steps`	as etapas, cada uma com `status`, `description`, `details` (a explicação, pronta para exibir) e `timestamp`
`timestamp`	quando o checkpoint foi registrado

`origin`	verificação
`FORENSIC_ANALYSIS`	Análise Forense
`DOCUMENT_CONTENT`	leitura e validação do conteúdo do documento
`CLIENT_RULE`	regra configurada pela sua empresa (fórmula, validador customizado)
`OFFICIAL_SOURCE`	conferência na fonte oficial emissora
`FACE_VALIDATION`	detecção e validação do rosto, em documento com foto
`DOCUMENT_HOOK`	demais verificações automáticas do tipo de documento
`SYSTEM`	falha de processamento, não é qualidade do documento

Documento antigo pode trazer checkpoint com origin: null. O formato completo está na Referência.

Onde o resultado aparece

No status do documento. A análise leva para INTEGRITY_REVIEW um documento que seria aprovado (SENT) quando um achado alcança o corte. Documento reprovado por outra regra continua reprovado.
- Outras verificações, como a conferência na fonte oficial, também usam INTEGRITY_REVIEW. Para saber se foi a análise, procure checkpoints de origin: "FORENSIC_ANALYSIS" em ALERT.
- No documento avulso, a conferência é sua: a Dynadok não muda esse status depois.
- No documento de participante, a conferência é feita pela equipe na plataforma (ver Análise de um participante).
- Os demais status estão em Fluxo assíncrono.
No laudo, em validationCheckpoints. Os checkpoints da análise são os que têm origin: "FORENSIC_ANALYSIS" — um por técnica, com um step por verificação. Os demais checkpoints do documento (leitura do conteúdo, regras do cliente, fonte oficial) têm outras origens. Documento sem a regra ligada não tem nenhum checkpoint dessa origem.

Consultar

curl 'https://api.dynadok.com/v1/api/documents/6500a1b2c3d4e5f600000001' \
  --header 'x-api-key: 550e8400-e29b-41d4-a716-446655440000.SUA_CHAVE'

Exemplo de documento que a análise mandou para revisão (valores ilustrativos; os demais campos e checkpoints do documento foram omitidos):

{
  "code": 200,
  "message": "OK",
  "timestamp": 1761148800000,
  "data": {
    "_id": "6500a1b2c3d4e5f600000001",
    "status": "INTEGRITY_REVIEW",
    "type": "COMPROVANTE_RESIDENCIA",
    "pagesCount": 1,
    "validationCheckpoints": [
      {
        "_id": "6500a1b2c3d4e5f600000101",
        "status": "VALID",
        "description": "Metadados do arquivo",
        "index": null,
        "origin": "FORENSIC_ANALYSIS",
        "timestamp": "2026-10-22T15:00:41.000Z",
        "steps": [
          {
            "status": "VALID",
            "description": "Software de criação/edição",
            "details": "Software de criação: nenhum editor de imagem identificado.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          },
          {
            "status": "VALID",
            "description": "Datas de criação e modificação",
            "details": "Datas: criação e modificação coincidem.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          }
        ]
      },
      {
        "_id": "6500a1b2c3d4e5f600000102",
        "status": "ALERT",
        "description": "Integridade dos campos, titular e conteúdo sintético",
        "index": null,
        "origin": "FORENSIC_ANALYSIS",
        "timestamp": "2026-10-22T15:00:41.000Z",
        "steps": [
          {
            "status": "VALID",
            "description": "Sinais de conteúdo sintético",
            "details": "Nenhum sinal de conteúdo gerado artificialmente na leitura visual.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          },
          {
            "status": "VALID",
            "description": "Texto regenerado por IA",
            "details": "Nenhum sinal confirmado de texto regenerado por IA de edição de imagem.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          },
          {
            "status": "ALERT",
            "description": "Integridade dos campos de dados",
            "details": "Divergência entre os valores dos campos, compatível com edição pontual: o valor total tem fonte e nitidez diferentes das demais linhas da conta.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          },
          {
            "status": "VALID",
            "description": "Coerência entre titular, pagador e canhoto",
            "details": "O titular ('MARIA EXEMPLO') confere com o cliente do canhoto.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          }
        ]
      },
      {
        "_id": "6500a1b2c3d4e5f600000103",
        "status": "VALID",
        "description": "Coerência dos valores do documento",
        "index": null,
        "origin": "FORENSIC_ANALYSIS",
        "timestamp": "2026-10-22T15:00:41.000Z",
        "steps": [
          {
            "status": "VALID",
            "description": "Valor da conta contra o código de barras de arrecadação",
            "details": "O valor impresso confere com o código de barras.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          }
        ]
      },
      {
        "_id": "6500a1b2c3d4e5f600000104",
        "status": "INFO",
        "description": "Análise visual — Nível de erro de compressão (ELA)",
        "index": null,
        "origin": "FORENSIC_ANALYSIS",
        "timestamp": "2026-10-22T15:00:41.000Z",
        "steps": [
          {
            "status": "INFO",
            "description": "Interpretação do mapa da técnica",
            "details": "O mapa de ELA reagiu em página 1. Página 1 (score 41): região do valor total com nível de compressão diferente do restante da página. Neste tipo de documento a análise de pixel sozinha não decide: o achado fica registrado como apoio.",
            "timestamp": "2026-10-22T15:00:41.000Z"
          }
        ]
      }
    ]
  }
}

Como ler o resultado

Cada checkpoint de origin: "FORENSIC_ANALYSIS" é uma técnica. O description dele identifica qual (tabela abaixo) e é estável: use-o para reconhecer a técnica, em vez de interpretar o texto dos details.
O laudo traz todas as técnicas. As que não se aplicam ao arquivo aparecem como um step INFO "Análise não executada", com o motivo em details.
O status do checkpoint é o mais relevante entre os dos seus steps, nesta ordem: ALERT, depois VALID, depois INFO. Um checkpoint com um step VALID e outro INFO fica VALID.
Cada step é uma verificação, com status, description (também estável) e details, a explicação em português pronta para exibir. Nas técnicas visuais, details traz a página e o score do achado.

status do step	significado
`VALID`	a verificação rodou e não encontrou indício
`ALERT`	achado: algo que merece conferência. Não reprova o documento
`INFO`	verificação não executada, sem dado suficiente para concluir, ou achado registrado só como apoio — o `details` diz qual

O laudo da análise só tem VALID, ALERT e INFO: um achado nunca reprova o documento. Só falha técnica reprova (ver Falha).

ALERT não é o mesmo que revisão

Um step em ALERT registra um achado. O documento só vai para INTEGRITY_REVIEW quando um achado com peso para decidir alcança o corte, e um achado abaixo do corte pode aparecer como ALERT num documento que segue aprovado. Para decidir o fluxo do seu lado, use o status do documento.

As técnicas (checkpoints)

`description` do checkpoint	o que examina
`Metadados do arquivo`	as informações gravadas no arquivo: software que o criou ou editou, datas, fontes, JavaScript, resolução, dados de câmera (EXIF, GPS) e credencial de conteúdo gerado por IA
`Estrutura interna do PDF`	como o PDF foi montado: remendos sobre o conteúdo, atualizações incrementais, fontes misturadas dentro de um valor
`Integridade dos campos, titular e conteúdo sintético`	leitura visual do documento: campo adulterado, pessoas diferentes entre titular, pagador e canhoto, conteúdo gerado por IA
`Consistência tipográfica`	trechos de texto com renderização, cor de tinta ou repetição que destoam do restante
`Coerência dos valores do documento`	valores que se contradizem: vencimento contra linha digitável, valor contra código de barras, dígitos do CPF, datas impossíveis
`Análise visual — Nível de erro de compressão (ELA)`	diferenças de compressão entre regiões da imagem
`Análise visual — Saturação/Matiz (HSV)`	diferenças de cor e saturação entre regiões da imagem
`Análise visual — Ruído multi-escala`	diferenças no padrão de ruído entre regiões da imagem

As verificações (steps)

checkpoint	`description` dos steps possíveis
Metadados do arquivo	`Software de criação/edição`, `Datas de criação e modificação`, `Completude dos metadados`, `Diversidade de fontes`, `JavaScript embutido`, `Resolução (DPI) da imagem`, `Dados EXIF`, `Câmera de origem`, `Coordenadas GPS`, `Credencial de conteúdo gerado por IA`
Estrutura interna do PDF	`Remendo sobre o conteúdo (whiteout / Form XObject)`, `Atualizações incrementais não explicadas`, `Fontes com subsets mistos`, `Fonte trocada dentro de um valor`
Integridade dos campos, titular e conteúdo sintético	`Sinais de conteúdo sintético`, `Texto regenerado por IA`, `Integridade dos campos de dados`, `Coerência entre titular, pagador e canhoto`
Consistência tipográfica	`Campo com renderização diferente do documento`, `Trecho do campo com cor de tinta diferente do restante`, `Trecho de texto duplicado na página`
Coerência dos valores do documento	`Valor que contradiz outra parte do documento`, `Vencimento do boleto contra a linha digitável`, `Valor da conta contra o código de barras de arrecadação`, `Dígitos verificadores do CPF`, `Datas que existem no calendário`
Análise visual (ELA, HSV, ruído)	`Interpretação do mapa da técnica`
qualquer técnica	`Análise não executada`

Nem todo step aparece sempre. Coerência entre titular, pagador e canhoto, por exemplo, só vem quando o documento nomeia mais de uma pessoa ou quando essa leitura não foi concluída. As verificações de coerência sem material para conferir saem INFO.

O que roda em cada arquivo

O laudo de um PDF gerado digitalmente é diferente do de uma foto. Cada técnica só roda onde há o que examinar — perícia de pixel não se aplica a um PDF de texto, e estrutura de PDF não se aplica a uma imagem pura. Por isso é normal um laudo com várias técnicas em INFO "Análise não executada". Os motivos possíveis:

`details` começa com	quando
`A natureza do arquivo enviado não permite esta análise`	a técnica não se aplica a esse tipo de arquivo
`O arquivo é uma captura de tela`	captura de tela: as técnicas de pixel não se aplicam
`Nenhuma página do arquivo é raster genuíno do emissor`	PDF de conteúdo vetorial: não há imagem original para periciar
`Os metadados já trouxeram prova direta de manipulação`	o escopo das demais técnicas foi reduzido, porque o metadado já bastou
`O arquivo não tem camada de texto`	imagem ou digitalização: não há valores declarados no arquivo para conferir
`O arquivo tem texto, mas não declara nenhum valor monetário`	nada a conferir entre si
`A leitura do documento não encontrou campo que esta análise confira entre si`	o documento não tem os campos que a coerência confere
`A leitura do documento por transcrição não foi concluída`	a coerência não pôde ser feita
`A análise foi disparada mas não retornou resultado utilizável`	a técnica falhou; as demais seguem valendo

Enquanto a análise roda

No modo assíncrono, enquanto o laudo não chega, o documento traz um checkpoint INFO de origin: "FORENSIC_ANALYSIS", sem steps: Análise Forense em andamento — o resultado é enviado ao final. O laudo o substitui quando chega.

No modo síncrono não há estado intermediário: o documento fica em PROCESSING até o laudo chegar.

Prefira o webhook ao polling. Se consultar, use um intervalo de dezenas de segundos.

Falha

A análise depende de serviços externos e pode não concluir. Nesse caso:

no modo assíncrono, o laudo traz o checkpoint INFO A Análise Forense não pôde ser concluída. e o documento segue com o resultado das demais validações;
no modo síncrono, o laudo traz o checkpoint ISSUE Houve um erro interno ao realizar a Análise Forense. e o documento é reprovado (REJECTED), com o erro em validationErrors (group: "DOCUMENT_HOOK_ERROR").

Documento reprovado por falha da análise não tem problema em si: envie de novo. Falha nunca leva a INTEGRITY_REVIEW — documento sem laudo não é tratado como suspeito.

Webhook

A Análise Forense não tem evento próprio: o laudo viaja nos eventos de documento, descritos em Webhooks.

situação	evento	o que traz
avulso, modo `sync`	`EXTERNAL_DOCUMENT_PROCESSED`	o documento já com o laudo
avulso, modo `async`	`EXTERNAL_DOCUMENT_PROCESSED` e `EXTERNAL_DOCUMENT_UPDATED`	o primeiro com o resultado das demais validações; o segundo com o laudo, `updateReason` e `message`
participante, modo `sync`	`PARTICIPANT_DOCUMENT_PROCESSED`	o documento já com o laudo

Para documento de participante, use o modo síncrono: o laudo chega no mesmo PARTICIPANT_DOCUMENT_PROCESSED.

O webhook só recebe os eventos em que está inscrito. Para o laudo do modo assíncrono, inscreva-o também em EXTERNAL_DOCUMENT_UPDATED. Cada evento traz o documento completo, no estado daquele momento.

O EXTERNAL_DOCUMENT_UPDATED da análise sai uma vez por análise, com o documento no mesmo formato de GET /v1/api/documents/{_id} e dois campos a mais:

{
  "event": "EXTERNAL_DOCUMENT_UPDATED",
  "data": {
    "_id": "6500a1b2c3d4e5f600000001",
    "status": "INTEGRITY_REVIEW",
    "validationCheckpoints": [
      {
        "status": "ALERT",
        "description": "Integridade dos campos, titular e conteúdo sintético",
        "origin": "FORENSIC_ANALYSIS",
        "steps": [
          {
            "status": "ALERT",
            "description": "Integridade dos campos de dados",
            "details": "Divergência entre os valores dos campos, compatível com edição pontual: o valor total tem fonte e nitidez diferentes das demais linhas da conta."
          }
        ]
      }
    ],
    "updateReason": "FORENSIC_ANALYSIS_COMPLETED",
    "message": "Análise Forense concluída: foram identificados indícios que apontam possibilidade de manipulação. Recomendamos conferência."
  }
}

updateReason hoje é sempre FORENSIC_ANALYSIS_COMPLETED. message é uma frase pronta para exibir, montada a partir do próprio laudo:

`message`	quando
`Análise Forense concluída sem indícios de manipulação.`	a análise não encontrou indício
`Análise Forense concluída: foram identificados indícios que apontam possibilidade de manipulação. Recomendamos conferência.`	a análise encontrou indício
`A Análise Forense não pôde ser concluída.`	a análise não concluiu

Para decidir o fluxo do seu lado, use o status do documento.

Documento avulso só chega em webhook da empresa toda

O documento avulso não pertence a projeto nenhum. Um webhook restrito a projetos nunca recebe EXTERNAL_DOCUMENT_PROCESSED nem EXTERNAL_DOCUMENT_UPDATED, sem erro nem aviso. Configure um webhook sem restrição de projeto.

Leia Webhooks antes de implementar o endpoint: uma resposta 4xx/5xx do seu lado não gera reenvio, e o laudo do modo assíncrono não chega por nenhum outro evento.

Análise de um participante

Quando o documento é de um participante de projeto, a regra fica no documento solicitado pela competência, configurada na plataforma (regra Análise Forense, ver A regra FORENSIC_ANALYSIS). É ali que a análise deve ser ligada: com Realizar análise, todo envio daquele documento é analisado, sem nada a mais na requisição:

curl --request POST 'https://api.dynadok.com/v1/api/competencies/6500a1b2c3d4e5f600000004/participants/6500a1b2c3d4e5f600000002/documents' \
  --header 'x-api-key: 550e8400-e29b-41d4-a716-446655440000.SUA_CHAVE' \
  --form 'files=@"/caminho/comprovante.jpg"' \
  --form 'competencyDocumentId="6500a1b2c3d4e5f60000000a"'

Nesse fluxo a análise examina o arquivo original enviado, e não a conversão para PDF. Num envio com vários arquivos, a perícia de imagem usa o primeiro (o PDF, se houver um); os demais passam só pela verificação de metadados.
O resultado sai em GET /v1/api/participant-documents/{participantDocumentId}, no mesmo formato de laudo descrito acima.
Em INTEGRITY_REVIEW, a revisão é interna: o participante continua vendo o documento como enviado, e a equipe confere o laudo na aba Integridade da plataforma. A decisão da equipe muda o status do documento e chega pelo PARTICIPANT_DOCUMENT_UPDATED.

Se a sua integração decide algo a partir do laudo, configure o documento em modo síncrono: o laudo chega junto no PARTICIPANT_DOCUMENT_PROCESSED.

Erros típicos

A análise não recusa um envio por causa do arquivo. Os erros de requisição dela vêm da validação da regra em rules: 400, no formato de Envelope e erros, com property: "rules" e uma destas mensagens:

mensagem	causa
`Valor "VALIDATE" inválido para a propriedade FORENSIC_ANALYSIS_VALIDATE da rule: "FORENSIC_ANALYSIS".`	valor fora das opções — maiúscula, `true`, `sim`. O mesmo vale para `FORENSIC_ANALYSIS_MODE`
`Propriedade FORENSIC_ANALYSIS_MODE é obrigatória quando as condições são satisfeitas.`	`validate` sem um dos outros dois itens. A mensagem traz o que faltou: `FORENSIC_ANALYSIS_MODE` ou `FORENSIC_ANALYSIS_MINIMUM_SCORE`
`Propriedade FORENSIC_ANALYSIS_VALIDAT não encontrada na regra do documento.`	`inputName` com erro de digitação
`Regra do tipo "FORENSIC_ANALYSYS" não encontrada`	`type` com erro de digitação

Os demais erros são os das rotas de documento (ver Documentos). O resto aparece como sintoma no documento:

sintoma	causa
documento sem nenhum checkpoint de `origin: "FORENSIC_ANALYSIS"`	regra ausente ou em `ignore`; `rules` enviado num formato que é descartado; documento reprovado antes da análise
avulso em modo assíncrono sem `EXTERNAL_DOCUMENT_UPDATED`	webhook não inscrito nesse evento ou restrito a projetos; endpoint que respondeu `4xx`/`5xx` à entrega; ou a análise ainda não terminou
documento reprovado com `Houve um erro interno ao realizar a Análise Forense.`	falha técnica da análise (ver Falha) — envie de novo
`400` com `property` em `rules[...]`	item de `rules` com formato inválido, por exemplo `inputValue` que não é array de strings

Análise Forense

Rotas​

Antes do primeiro envio​

A regra FORENSIC_ANALYSIS​

Síncrona ou assíncrona​

O corte​

Enviar um documento avulso com a análise​

Acompanhar a análise​

O que são os checkpoints​

Onde o resultado aparece​

Consultar​

Como ler o resultado​

As técnicas (checkpoints)​

As verificações (steps)​

O que roda em cada arquivo​

Enquanto a análise roda​

Falha​

Webhook​

Análise de um participante​

Erros típicos​