# 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.