1. Finalidade do catálogo
1.1. O Legal Center organiza documentos, estados, versões, idiomas, territórios, relações e histórico para facilitar avaliação por Clientes, parceiros, titulares e assessores.
1.2. O catálogo não substitui o Pedido, não concede capacidade de produto e não torna vigente documento marcado como minuta ou revisão.
1.3. Cada entrada deverá indicar título, propósito, público, estado, versão, idioma, relação com outros documentos e data de vigência quando existir.
1.4. O conteúdo deverá permitir distinguir obrigação contratual, aviso de transparência, política de uso, material operacional e referência territorial.
1.5. O Catálogo possui função de governança, integridade e prova e não será utilizado para incorporar, por referência circular ou indeterminada, documento que não tenha sido disponibilizado em versão identificável. Metadados, hash, estado e histórico deverão corresponder aos bytes efetivamente apresentados ao destinatário.
2. Fonte pública única
2.1. O Legal Center será a fonte pública controlada dos textos jurídicos da Aivyro quando aprovados.
2.2. Rotas equivalentes da landing, documentação ou aplicação deverão apontar ou redirecionar para a versão correspondente sem conservar cópia oficial divergente.
2.3. O repositório manterá fontes recebidas, redlines, candidatos, aprovações e arquivos históricos sem sobrescrever proveniência.
2.4. Cópia exportada ou anexa ao Pedido deverá ser identificável e corresponder ao conteúdo incorporado naquele aceite.
2.5. Atalho, redirecionamento, cache, CDN, tradução ou renderização não poderá servir conteúdo materialmente divergente sob o mesmo identificador. A fonte canônica deverá permitir recompor data, versão, hash, estado e relação com o Pedido sem depender exclusivamente da página atualmente publicada.
3. Estados documentais
3.1. Estados permitidos deverão distinguir rascunho interno, revisão jurídica, aprovado ainda não vigente, publicado, substituído, retirado e bloqueado.
3.2. Somente documento publicado, com data de vigência e aprovação correspondente, poderá participar de aceite vinculante.
3.3. Texto em revisão poderá ser exibido para colaboração apenas com aviso inequívoco de que não está vigente nem deve ser usado para aceite.
3.4. Estado de deploy técnico não altera estado jurídico; página acessível não significa documento aprovado.
3.5. Os estados mínimos deverão distinguir rascunho interno, revisão factual, revisão jurídica, aprovado para leitura, aprovado para aceite, substituído e retirado. A transição exigirá ator autorizado, evidência, data e objeto exato, e nenhum estado inferido de branch, commit ou ambiente será tratado isoladamente como aprovação profissional.
4. Versionamento e integridade
4.1. Cada versão deverá conservar texto integral, idioma, estado, data, hash ou cópia equivalente, documentos incorporados e changelog material.
4.2. Alterar conteúdo aprovado produz nova versão ou novo hash e exige revalidação antes de novos aceites.
4.3. Link mutável sem histórico não basta para demonstrar quais termos foram apresentados a determinado Cliente.
4.4. Correção editorial sem efeito jurídico será registrada separadamente de mudança material, preservando rastreabilidade.
4.5. Alteração material compreenderá, entre outros, objeto, preço, renovação, direito, responsabilidade, tratamento, fornecedor, território, foro, integração, IA, segurança ou término. A classificação será documentada e revisável; chamar mudança de editorial não reduzirá dever de novo aviso ou aceite quando o efeito real for jurídico.
5. Aprovação vinculada
5.1. O registro de aprovação identificará documento, versão, conteúdo exato, idioma controlador, traduções, revisor, escopo, ressalvas e data.
5.2. Nomear um revisor designado no fluxo interno não equivale a parecer, autoria ou aprovação do texto.
5.3. Aprovação profissional deverá estar ligada aos hashes finais e às evidências factuais que sustentam alegações de produto, operação e território.
5.4. Aprovação parcial não será extrapolada para documento, idioma, país, setor, capacidade ou alteração fora do escopo registrado.
5.5. O registro de aprovação identificará revisor, capacidade, escopo, ressalvas, evidências, versão e validade temporal, sem atribuir autoria ou concordância a pessoa que apenas participou de reunião ou forneceu material. Mudança posterior nos bytes, fatos ou anexos invalidará a aprovação no alcance afetado.
6. Idiomas e traduções
6.1. O Pedido identificará o idioma controlador quando permitido; português brasileiro não prevalecerá automaticamente sobre norma local obrigatória.
6.2. Inglês e espanhol deverão passar por revisão jurídica e linguística antes de serem apresentados como traduções completas.
6.3. Enquanto uma tradução estiver pendente, a interface deverá informar esse estado e não exibir texto antigo como versão correspondente.
6.4. Divergência de tradução será resolvida pela regra contratual válida e pela lei inderrogável, sem ampliar obrigação ou eliminar direito silenciosamente.
6.5. Tradução deverá preservar definições, remissões, numeração, modalidade deôntica, exceções e efeito jurídico, com glossário controlado para termos técnicos. Tradução automática poderá apoiar o trabalho, mas não será publicada como versão apta a aceite sem revisão humana qualificada e vínculo com o texto controlador.
7. Precedência
7.1. O Pedido governa condições comerciais específicas; os Termos regem a relação geral; o DPA disciplina tratamento por instrução; anexos específicos prevalecem somente no tema identificado.
7.2. Documento informativo não altera contrato, e política não poderá substituir compromisso expressamente negociado sem mecanismo válido de modificação.
7.3. Norma obrigatória prevalece sobre cláusula incompatível no alcance aplicável, sem invalidar automaticamente disposições separáveis.
7.4. Conflito conhecido entre documentos deverá ser resolvido antes do aceite, e não transferido ao Cliente por remissão circular ou vaga.
7.5. Regra de precedência será específica por tema e não permitirá que política unilateral substitua preço, responsabilidade, DPA ou compromisso negociado. Quando duas disposições puderem coexistir, serão interpretadas cumulativamente; prevalência operará somente no conflito efetivo e no alcance necessário.
8. Seleção pelo Pedido
8.1. O Pedido deverá selecionar documentos aplicáveis conforme entidade, território, setor, produto, dados, IA, gravação, comunicação, integração e cobrança.
8.2. Documento não incorporado poderá informar governança ou uso, mas não criará obrigação negociada que exija aceite específico.
8.3. Novo módulo ou mudança material reabrirá a seleção para evitar que anexo ausente seja presumido por acesso técnico.
8.4. O Cliente deverá receber acesso ao conjunto aplicável antes do aceite e conseguir conservar ou consultar a versão incorporada.
8.5. A seleção será determinística a partir de entidade, produto, plano, módulo, território, setor, dados, canais, integrações e termos negociados. Documento irrelevante não será imposto em bloco, e documento necessário não será omitido por falha de interface, devendo o sistema bloquear o aceite quando a composição estiver incompleta.
9. Oferta e publicidade
9.1. Roadmap e recurso claramente identificado como futuro não constitui compromisso de data não acordada.
9.2. Esta regra não afasta efeito vinculante de oferta ou publicidade suficientemente precisa, informação pré-contratual ou compromisso imposto pela lei.
9.3. Divergência entre pricing, proposta, demonstração, documentação, script comercial e contrato deverá ser esclarecida antes da contratação.
9.4. Disclaimer genérico não autoriza informação falsa, omissão essencial ou pedido para que o Cliente ignore promessa feita pela Aivyro.
9.5. Material comercial deverá apontar versão e condições quando fizer claim juridicamente relevante, e aprovação da oferta será reconciliada com pricing, Pedido, documentação e produto. Representante não autorizado não poderá ampliar obrigação, mas a Aivyro avaliará confiança legítima e dever de correção quando sua própria comunicação tiver induzido erro material.
10. Claims e evidência
10.1. Cada alegação sobre segurança, fornecedor, região, retenção, IA, precisão, integração, exportação, cobrança ou suporte deverá apontar fato, responsável, sistema, data e teste atuais.
10.2. Configuração, código, esquema, simulação ou intenção de planejamento futuro não será tratada isoladamente como prova de comportamento em produção.
10.3. Se a evidência expirar, mudar ou divergir da operação real, o documento retornará à revisão e a alegação será removida, corrigida ou marcada como indisponível.
10.4. Segredo comercial poderá limitar detalhe público, mas não justificará alegação impossível de verificar nem ocultação de informação legalmente necessária.
10.5. A matriz de claims deverá registrar proposição, fonte primária, responsável, ambiente, condição, data de teste, validade e linguagem permitida. Claim sem evidência, vencido ou dependente de roadmap será removido, condicionado ou reclassificado antes da publicação, inclusive quando tecnicamente plausível.
11. Mudanças materiais
11.1. Alteração de preço, renovação, tratamento, fornecedor, treinamento, responsabilidade, foro, território ou função contratada será avaliada quanto a aviso e novo aceite.
11.2. Mudança material não será aplicada retroativamente sem base, consentimento válido ou mecanismo contratual permitido.
11.3. Correção urgente de segurança ou lei poderá exigir medida imediata, com registro e comunicação no alcance possível.
11.4. Changelog deverá explicar efeito relevante em linguagem compreensível e não apenas indicar número de versão.
11.5. A avaliação de mudança definirá contratos afetados, aplicação prospectiva, aviso, prazo, novo aceite, direito de oposição ou término e necessidade de tradução. Alteração favorável ou exigida por segurança poderá seguir rito distinto, mas continuará registrada e não apagará a versão anterior.
12. Arquivo e prova de aceite
12.1. O sistema de aceite deverá preservar versão, conteúdo, entidade, Pedido, organização, representante, poderes, autenticação, idioma e momento relevante.
12.2. IP ou evidência técnica equivalente será tratado conforme necessidade, privacidade e lei e não será considerado prova única universal.
12.3. Versões anteriores permanecerão arquivadas e vinculadas aos contratos que as incorporaram, sem serem alteradas pelo documento atual.
12.4. Cliente deverá conseguir obter cópia ou referência estável do conjunto aceito por período compatível com a relação e obrigações legais.
12.5. A prova deverá correlacionar identidade, poderes, autenticação, organização, Pedido, documentos, versões, hashes, idioma, horário e evento de confirmação, protegendo minimização e integridade. Falha de um elemento não será automaticamente suprida por IP, log isolado ou presunção de acesso.
13. Revisão por evento
13.1. Nova jurisdição, canal, dado sensível, modelo, fornecedor, transferência, aquisição, incidente, cobrança, retenção ou módulo reabrirá os documentos afetados.
13.2. Mudança legislativa, orientação de autoridade, decisão judicial relevante ou alteração de prática também poderá exigir revisão.
13.3. O responsável registrará fato, impacto, documentos, decisão, evidência e prazo sem converter automaticamente novidade jurídica em obrigação já vigente.
13.4. Revisão periódica complementa, mas não substitui, revisão por evento material.
13.5. Cada evento abrirá registro de impacto, responsável, prazo, documentos, clientes e medidas transitórias, encerrado somente com decisão e evidência. Ausência de alteração textual também será registrada quando a análise concluir, justificadamente, que o corpus permanece adequado.
14. Publicação rollback e segurança
14.1. A condição técnica de publicação verificará estado, data, aprovação, conteúdo e integridade antes de liberar documento como superfície de aceite.
14.2. Falta, divergência ou expiração relevante bloqueará novos aceites sem impedir publicação independente de documentação técnica não contratual.
14.3. Rollback retirará ou substituirá versão pública sem apagar histórico e preservará avisos e contratos já formados no alcance aplicável.
14.4. Incidente no Legal Center será tratado como risco de integridade e poderá exigir bloqueio, comunicação, reconstrução e nova aprovação.
14.5. O rollback técnico apontará a versão juridicamente correta para novos acessos sem alterar contratos já formados. Se conteúdo não aprovado tiver sido apresentado para aceite, o incidente será quantificado por organização, momento e versão, com avaliação de ratificação, correção, comunicação e remédio apropriados.
15. Limites e vigência
15.1. Este catálogo não afirma que todos os módulos, programas, países, fornecedores, certificações, controles ou canais estejam disponíveis.
15.2. Os documentos do corpus público são publicados individualmente com versão e vigência. Tradução ausente, condição operacional ou instrumento dependente do Pedido deverá ser indicado no documento pertinente e não altera silenciosamente o estado dos demais.
15.3. A publicação torna disponível a versão empresarial indicada, mas não substitui o preenchimento de preço, módulo, território, dado autorizado, SLA ou outra condição que o próprio documento reserve ao Pedido ou a anexo específico.
15.4. Este documento vigora na data indicada e disciplina a governança do corpus publicado. Divergência material identificada exigirá correção versionada e, quando afetar formação contratual ou direito, comunicação e tratamento compatíveis.
15.5. O Catálogo não substitui inventário de produto, dados, fornecedores, preços ou territórios; ele os referencia e bloqueia divergências materiais. Seu funcionamento será verificado por teste de composição, integridade, tradução, arquivo, recuperação e rollback antes de servir como infraestrutura de contratação.