Credibilidade v2: Agora Voce Pode Limitar, e A Gente Te Explica de Volta

No nosso lancamento v1 dissemos uma coisa e a fizemos valer: nao pedimos que voce confie na magica, pedimos que voce inspecione. Lancamos cinco APIs, um painel lateral de decisao redesenhado, um numero de confianca por decisao, restricoes declarativas, experimentos em modo shadow e uma exportacao em streaming com trailer SHA-256. (Leia o post v1.)

Inspecionar foi o primeiro passo. Hoje estamos lancando o segundo.

v2 diz: agora voce tambem pode limitar, e a gente explica de volta na sua lingua.

Sete novas features ficam sobre a mesma fundacao audit-first. O canary Pro abre hoje. O GA publico e em 14 dias, com revisao pos-canary obrigatoria.

O que e novo

1. Confidence Evidence — o que o router sabia, em cada decisao

Cada decisao Feedback-Driven e Smart-Cost agora carrega um bloco evidence ao lado de confidence e confidence_reason. Cinco campos: samples, top2_score_gap, outcome_variance, recent_regressions, last_regression_at. Os mesmos numeros que alimentaram a formula, expostos para que um revisor possa auditar as entradas, nao apenas o veredito.

recent_regressions e bucketizado — Exact{n} para n < 10, AtLeast{10}, AtLeast{50}. Sinal suficiente para investigar, sem volumes precisos. last_regression_at e arredondado para multiplos de 5 minutos pelo mesmo motivo. A janela rolante de 7 dias e org-scoped ponta a ponta. Leia a Metodologia de Confianca completa.

2. Quatro novos portoes de constraint

O body de PUT /v1/constraints agora aceita nove campos, contra tres antes. Os quatro novos:

• min_samples_before_promotion — recusa deixar um candidato vencer abaixo de um piso de amostras.
• max_outcome_variance — recusa um candidato cujos resultados sao inconsistentes.
• max_cost_drop_without_validation — recusa um candidato bom-demais-para-ser-verdade sem um shadow aprovado primeiro.
• require_shadow_before_live — recusa qualquer promocao que nao tenha sido validada em shadow.

Cada portao emite um filtered[].reason tipado e esta documentado ponta a ponta na pagina de feature de Constraints.

3. UI de CRUD para Constraints

/routing/constraints no dashboard renderiza os nove campos em tres secoes (limites de qualidade, limites de custo, portoes de promocao), cada um etiquetado com seu FilteredReason, com botao de salvar que faz diff entre o estado anterior e o novo e linka para a entrada do log de auditoria. Constraints viviam apenas em codigo; agora vivem em codigo e em uma UI que seu revisor de seguranca consegue ler.

4. Otimizacao Verificada

Um novo endpoint, GET /v1/optimization/verification, responde uma pergunta estrita e estreita sobre o log de requisicoes do proprio cliente: temos evidencia suficiente para chamar esta rota de verificada, nos ultimos 7 dias? O veredito e um de verified, not_verified, insufficient_data, regression_detected, com os agregados subjacentes de baseline e Floopy retornados ao lado.

Os limiares estao fixados em codigo: SAMPLE_FLOOR = 100, QUALITY_TOLERANCE = 0.03. O endpoint tem cache Redis de 60 segundos e respeita um contrato HTTP Cache-Control: max-age=60. O card de Verification Status da pagina Baseline-vs-Floopy do dashboard le o mesmo endpoint. A metodologia esta na pagina Baseline-vs-Floopy.

5. Explicacao Legivel

Cada decisao agora carrega um paragrafo explanation.text renderizado na locale do Accept-Language da requisicao (caindo para en). O texto e composto a partir de uma taxonomia fechada de 15 templates e um pequeno conjunto de parametros tipados. E renderizado em tempo de leitura, nunca persistido em decision_trace, nunca referencia conteudo de prompt, limitado em 600 caracteres e bloqueado contra caracteres de controle. A locale resolvida e ecoada pelo cabecalho HTTP Content-Language. Suportadas atualmente: en e pt.

Duas razoes para renderizar em tempo de leitura. Primeira, seguranca e armazenamento: persistir prosa para sempre carregaria uma superficie de injecao de texto armazenado para sempre. Segunda, internacionalizacao: um cliente que le a mesma decisao em en hoje e em pt amanha recebe dois paragrafos diferentes a partir de uma unica decisao armazenada, sem passo de migracao. Leia a feature de Explicacao de Decisao para a taxonomia completa.

6. UI de Experimentos + Endpoint de Resultados

Experimentos de roteamento agora sao uma superficie de primeira classe no dashboard. /routing/experiments lanca uma listagem, um formulario de criacao, uma pagina de detalhe com paineis baseline-vs-candidato movidos a polling, e um dialogo de rollback em um clique. A cadencia de polling e 20 segundos nos primeiros 10 minutos, 60 segundos depois, e pausa completamente em aba oculta.

A pagina de detalhe le um novo endpoint, GET /v1/experiments/{id}/results, com cache Redis de 30 segundos e limitado ao tempo de vida started_at/ended_at do experimento. Gerenciar experimentos por curl continua funcionando, mas nao e mais o caminho principal — o dashboard e.

7. Setup de Shadow no Onboarding

O onboarding da Floopy agora oferece um passo de shadow setup em uma etapa entre “conectar um provedor” e “primeira chamada”. O passo usa o catalogo interno de modelos da Floopy para sugerir uma alternativa mais barata sensata para o modelo que voce acabou de conectar, cria um experimento shadow em um clique e faz polling dos resultados para que voce veja os numeros baseline-vs-candidato aparecerem sem sair do fluxo de onboarding. Em planos Free o passo renderiza um preview que faz zero chamadas fetch — credibilidade para o usuario Free, no dia zero.

A forma do v2

v1 foi sobre expor o que o router fez. v2 e sobre limitar o que ele tem permissao para fazer, e te explicar de volta na sua lingua.

Voce pode fixar nove portoes declarativos e o router se recusa a viola-los. Voce pode perguntar, no seu proprio trafego, se uma rota esta verificada — e receber um nao quando a evidencia nao esta la. Voce pode ler, em prosa simples, em en ou pt, por que uma decisao foi como foi, e a prosa e composta a partir de um conjunto fechado de templates sem substrings controladas pelo chamador. Voce pode rodar um experimento shadow pela UI em dois cliques. Voce pode fazer tudo isso no mesmo dia em que cria a conta.

O que nao fizemos

Nao adicionamos explicacoes geradas por LLM. O texto vem de um match fechado sobre (template_id, locale), nao de um modelo de linguagem. Nao adicionamos prompts ou respostas em formato bruto a nenhum endpoint ou exportacao — o contrato do v1 se mantem. Nao adicionamos uma janela de verificacao configuravel pelo cliente alem de 7 dias, nem formula de confianca configuravel, nem edicao em tabela de competidores, nem mudanca em pagina de pricing.

Nao quebramos nenhum formato de wire do v1. Cada novo campo e aditivo e opcional. Leitores v1 ignoram chaves desconhecidas; leitores v2 toleram linhas v1.

Como obter

O canary Pro abre hoje. Clientes do plano Pro podem optar mandando email para support@floopy.ai com o ID da organizacao. O GA publico e em 14 dias, com revisao pos-canary obrigatoria.

Se voce leu o v1 e a resposta foi “perto — continuem”, este e o continuem. Te dissemos o que o router estava fazendo. Agora voce pode dizer ao router o que ele tem permissao para fazer, e o router te diz de volta, na sua lingua, o que fez.

Essa e a forma do v2.