# Validade e regras por tipo documental

Objetivo:
estruturar como a plataforma deve tratar validade, vencimento, renovação e incerteza documental.

Ponto crítico:
nem todo documento ambiental “vence” da mesma forma.
Alguns têm validade explícita.
Outros dependem de condição, ato posterior, renovação, etapa processual ou obrigação periódica.

Portanto, a plataforma deve modelar:
- validade explícita
- validade presumida
- ausência de validade
- dependência de evento externo
- necessidade de revisão técnica

-----------------------------------
1. Modelo conceitual de validade

Cada documento deve ter os seguintes campos:
- tipo_documental
- subtipo_documental
- numero_documento
- processo_relacionado
- orgao_emissor
- data_emissao
- data_publicacao
- validade_tipo
- data_inicio_vigencia
- data_fim_vigencia
- regra_de_validade
- renovavel
- antecedencia_alerta_dias
- status_vigencia
- confidence_score
- necessita_revisao_tecnica
- fonte_origem
- texto_fonte

Tipos de validade possíveis:
- explicita_no_documento
- inferida_por_regra
- sem_prazo_identificado
- depende_de_evento
- depende_de_renovacao
- indeterminada

Status de vigência possíveis:
- vigente
- vencendo
- vencido
- substituido
- retificado
- suspenso
- cancelado
- em_analise
- nao_determinado

-----------------------------------
2. Regra de ouro

A plataforma nunca deve fingir certeza quando não houver certeza.

Se o documento não trouxer validade explícita, o sistema deve marcar algo como:
- validade inferida
- revisão necessária
- confirmação documental pendente

Isso é fundamental para evitar erro regulatório.

-----------------------------------
3. Tipos documentais já identificados no ecossistema pesquisado

A. Licença Ambiental
Exemplos:
- LP
- LI
- LO
- renovação de LO
- LPIO

Tratamento sugerido:
- procurar validade explícita no próprio documento
- se houver data final, usar data explícita
- se não houver, marcar revisão técnica obrigatória
- criar antecedência de alerta alta

Regras de negócio:
- licenças devem ter estado de vigência claro
- podem gerar obrigação de renovação
- podem ter condicionantes vinculadas
- nova licença pode substituir licença anterior

B. Autorização
Exemplos:
- autorização para supressão
- autorização para intervenção em APP
- autorização correlata ao licenciamento

Tratamento sugerido:
- geralmente tratar como ato com vigência delimitada ou vinculada ao objeto autorizado
- exigir revisão do prazo e escopo no documento
- marcar dependência de execução da intervenção

Risco:
- autorização pode vencer por prazo ou por exaurimento do objeto
- não assumir regra única para todos os casos

C. DAIL
Tratamento sugerido:
- modelar como documento específico com regra própria
- inicialmente exigir leitura documental ou parametrização técnica
- não presumir vencimento sem confirmação

D. CADRI
Tratamento sugerido:
- modelar separadamente
- capturar emissão, escopo e eventual prazo/condição
- vincular a operação/resíduo/fluxo correspondente

E. Alvarás e outros documentos emitidos
Tratamento sugerido:
- manter taxonomia separada de licenças
- verificar se têm vigência própria
- se não for claro, marcar como revisão técnica obrigatória

F. Documentos de processo
Exemplos:
- protocolo
- exigência técnica
- parecer
- comunicado
- recurso
- despacho

Tratamento sugerido:
- em geral não classificar como “documento vencível”
- classificar como evento processual
- pode gerar prazo de resposta ou pendência

G. Documentos normativos/orientativos
Exemplos:
- roteiro
- orientação geral
- manual
- instrução técnica

Tratamento sugerido:
- não têm vigência operacional de cliente como licença
- servem como base normativa, checklist e interpretação

-----------------------------------
4. Hierarquia de confiança para cálculo de validade

Nível 1 - confiança alta
- data de validade expressa no documento
- vigência expressa no documento
- ato de renovação claramente identificado

Nível 2 - confiança média
- regra parametrizada por tipo documental validada por especialistas
- referência legal clara aplicada ao tipo documental

Nível 3 - confiança baixa
- inferência por padrão histórico
- dedução a partir de textos incompletos
- ausência de documento integral

Regra:
tudo que ficar em confiança baixa deve aparecer como:
- “validade estimada”
- “confirmar com análise técnica”

-----------------------------------
5. Como o sistema deve tratar vencimento

Motor de alerta sugerido:
- 180 dias antes
- 120 dias antes
- 90 dias antes
- 60 dias antes
- 30 dias antes
- vencido

Mas o alerta precisa ser parametrizável por tipo documental.

Exemplo de lógica:
- licenças complexas -> alertas antecipados
- autorizações simples -> janela menor
- processos com pendência -> alerta por evento, não por vencimento

-----------------------------------
6. Regras de modelagem importantes

6.1 Documento não é a mesma coisa que processo
Um processo pode conter múltiplos documentos.

6.2 Documento não é a mesma coisa que obrigação
Uma licença pode gerar várias condicionantes.

6.3 Vencimento não é a mesma coisa que irregularidade
Às vezes há protocolo de renovação, retificação ou substituição em andamento.

6.4 Emissão não é a mesma coisa que publicação
Guardar as duas datas quando possível.

6.5 Renovação não é necessariamente novo cadastro sem vínculo
Deve existir relacionamento entre documento anterior e sucessor.

-----------------------------------
7. Taxonomia inicial recomendada

categoria_documental:
- licenca
- autorizacao
- cadastro
- alvara
- certidao
- parecer
- exigencia
- protocolo
- recurso
- despacho
- orientacao
- norma
- comprovante
- outros

atributo_de_vigencia:
- vencivel
- nao_vencivel
- evento_com_prazo
- depende_de_revisao

-----------------------------------
8. Regras de produto para o radar de mercado

Para leads externos, o sistema deve usar 3 classes:

Classe A - vencimento confirmado
Quando houver data final explícita confiável.

Classe B - renovação provável
Quando houver histórico/licença/documento que sugere necessidade próxima de renovação, mas sem data final plenamente confirmada.

Classe C - atividade regulatória relevante
Quando houver novo licenciamento, nova emissão, publicação, protocolo ou movimentação regulatória relevante sem inferência de vencimento.

Isso é ótimo comercialmente, porque evita depender apenas de “vai vencer”.

-----------------------------------
9. Recomendações para o robô

O robô deve extrair, sempre que possível:
- tipo documental
- empresa/interessado
- processo
- atividade
- município
- data de emissão
- data de publicação
- data de validade
- texto que fundamenta a validade
- documento anterior relacionado
- documento sucessor relacionado

E deve gerar automaticamente:
- validade_bruta_extraida
- validade_normalizada
- score_confianca
- status_de_revisao

-----------------------------------
10. Recomendação prática para o MVP

Não tentar resolver toda a jurisprudência/regra documental no início.

MVP do motor de validade:
- capturar data explícita quando existir
- permitir parametrização manual por tipo documental
- exigir revisão humana nos casos ambíguos
- gerar alertas confiáveis somente quando houver base suficiente

-----------------------------------
Conclusão

Sim, cada tipo documental pode ter validade, vigência, condição ou prazo associado.
Mas isso não deve ser tratado como um campo simplista “vence_em”.

O modelo correto é:
documento + regra de vigência + grau de certeza + contexto processual.

Essa arquitetura vai permitir que a plataforma seja confiável e escalável.
