Camada tecnológica avançada
Três módulos opcionais que elevam o motor de decisão do ANBD-GENESIS além de uma simples resposta automática.
Cada decisão vem acompanhada de um raciocínio passo a passo: os scores avaliados, a margem entre resultados, o grau de novidade do padrão e a confiança final que levou à ação escolhida.
Por que importa: transforma uma decisão automatizada em algo auditável e explicável — essencial para justificar decisões perante reguladores, auditores ou clientes finais.
"reasoning_trace": [
{ "step": "1. Avaliação de scores", "description": "..." },
{ "step": "2. Novidade do padrão", "description": "..." },
{ "step": "3. Confiança final", "description": "..." }
]
O motor monitora continuamente a confiança média das decisões de cada cliente. Quando o padrão de dados muda e a confiança começa a cair de forma consistente, um alerta objetivo é emitido — antes que a qualidade da decisão caia na prática.
Por que importa: em produção, modelos degradam silenciosamente. Este módulo entrega visibilidade sem precisar de ferramentas externas de observabilidade.
O cliente define limites próprios que sobrepõem a decisão automática em casos específicos — por exemplo, forçar encaminhamento humano sempre que a confiança cair abaixo de um valor definido por ele.
Por que importa: dá controle direto sobre a política de decisão, sem precisar pedir mudança de código ou esperar um novo deploy.
Segunda onda — 09/09/2026
Adicionadas sobre o motor já validado em produção, sem alterar sua lógica interna.
O limiar de confiança exigido para executar uma decisão automaticamente deixa de ser fixo e passa a variar conforme o risco declarado da operação (risk_level: baixo, médio ou alto).
Por que importa: quanto maior o risco, maior a evidência exigida para automatizar — uma decisão de risco alto passa a precisar de bem mais confiança do que uma de risco baixo.
O motor monitora a taxa de ESCALAR/ABSTER de cada cliente numa janela recente de decisões. Se essa taxa disparar — sinal de comportamento anormal — o breaker abre e força ESCALAR em toda decisão nova por um período de resfriamento.
Por que importa: protege a operação automaticamente contra anomalias, sem esperar um humano perceber o problema.
Endpoint /v1/me/observability traz métricas agregadas das decisões recentes: distribuição por ação, confiança média, latência média, novidade média e o estado atual do circuit breaker.
Por que importa: o cliente deixa de apenas usar a API — passa a enxergar a inteligência funcionando, sem precisar de ferramentas externas.
Endpoints /v1/me/policy (GET e POST) permitem que cada cliente sobrescreva os limiares padrão do motor e force o escalonamento humano sempre que o risco for alto — sem precisar alterar código.
Por que importa: adapta o comportamento do ANBD-GENESIS à realidade de cada empresa, aumentando o potencial SaaS e Enterprise.
Acompanha, por tenant, a média do reward_feedback recebido nas últimas decisões — um indicador direto de quão bem o motor está decidindo, incluído na resposta de /v1/me/observability.
Por que importa: mede não apenas quanto o motor decide, mas quão bem ele está decidindo ao longo do tempo.
Campo simulate: true no /v1/decide processa a decisão normalmente e devolve o resultado, mas nenhum webhook é disparado — ideal para testar o motor sem gerar efeitos colaterais em produção.
Por que importa: reduz o risco na adoção, permitindo comparar a decisão do sistema com a decisão humana antes de automatizar de verdade.
Nota de transparência: Rust Acceleration e Event-Driven Architecture têm a interface de código pronta (adaptadores e flags de ativação), mas dependem de infraestrutura externa — um compilador Rust publicado como dependência e um message broker gerenciado, respectivamente — que ainda não foi contratada. Todas as demais oito camadas rodam nativamente em Python, sem dependência externa.
Terceira onda — 12/09/2026
Camada de orquestração de assinaturas construída sobre o Stripe já existente, sem substituir nem remover nada do fluxo original.
Cada assinatura passa a ter um estado explícito e auditável: ACTIVE, PAST_DUE, GRACE_PERIOD, SUSPENDED ou CANCELLED. As transições entre eles seguem uma Policy Engine própria de billing, com período de carência configurável antes de qualquer suspensão.
Por que importa: uma falha de pagamento não suspende o cliente na hora — ele tem uma janela de tolerância, do jeito que uma operação de assinatura madura deveria funcionar.
O Stripe pode reenviar o mesmo evento de cobrança mais de uma vez — comportamento padrão dele, não uma falha. O Billing Engine identifica e ignora eventos duplicados a nível de banco de dados, garantindo que nenhuma cobrança seja processada duas vezes.
Endpoints /v1/me/billing e /v1/me/billing/history dão ao cliente visibilidade sobre o estado atual da própria assinatura e o histórico de eventos de cobrança — sem precisar abrir chamado de suporte para saber "por que fui cobrado".