Skip to content

[P3][detection][seed] Faixa de revisão como conceito de primeira classe: handoff opt-in para decisor externo, sem persistir valor e sem LLM no caminho crítico #2023

Open

Description

@FabioLeitao

U: U3 — sem pressão de prazo.
G: G2 — o desenho errado (persistir ou fazer hash do excerto) vira vazamento de PII; por isso o entregável é o contrato, não código.
Depende de: #1504 (schema do envelope), #1451 (achado 4: identidade da pilha no recibo), #1452 (calibração: a faixa vem de dado, não de palpite).

Contexto

O Boar já tem uma zona "não sei", espalhada por vários detectores (verificado por gh api no origin em 30/set):

  • medium_confidence_threshold (padrão 40 em core/detector.py);
  • fuzzy de nome de coluna entre fuzzy_min_confidence (25) e fuzzy_max_confidence (45), só se pedido em config e com o rapidfuzz instalado;
  • hint de protótipo de embedding, que o próprio módulo descreve como "só na faixa borderline abaixo de MEDIUM" (core/embedding_prototype_hint.py);
  • ML-only HIGH limitado a MEDIUM em contexto de entretenimento, legenda e OCR (docs/SENSITIVITY_DETECTION.md, limite 70).

Cada hint marca "confirme manualmente". Falta: (a) um conceito nomeado de faixa de revisão; (b) um contrato para que um decisor externo e opt-in ajude nessa faixa; (c) prova de que, sem ele, nada muda.

Doutrina que o contrato não pode quebrar

Proposta (síntese do Claude, a confirmar)

  1. Nomear e medir a faixa: definição normativa, com os limiares reais citados (confirmar os nomes com git grep -n), derivada da calibração da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452 (taxa real de positivos por banda de score), não de números fixos.
  2. Campo no envelope ([research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504): review_band mais o motivo (quais detectores estão na faixa, com os scores por motor nomeados na audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452), sem o valor.
  3. Handoff em duas classes, ambas opt-in e default OFF:
    • Classe M (só metadados): nome de coluna normalizado, tipo, contagens, scores e padrões disparados. Serve a consumidores cegos a valor bruto. A v1 é só esta.
    • Classe R (excerto real): exige grant assinado e escopo por coluna; o excerto amostrado fica só em memória, vai por pipe local a um processo efêmero, sem persistência e sem rede. Fora da v1 (recomendação); exige decisão explícita do operador e revisão de segurança.
  4. Retorno é hint, nunca veredito: mesmo padrão dos hints existentes. Só pode elevar a confiança ou anotar, dentro da faixa, com o rótulo "confirme manualmente". Nunca rebaixa um achado (FN-first). Registra a identidade do consumidor e a versão do contrato.
  5. Sem consumidor, sem mudança: o resultado é idêntico ao de hoje e o recibo registra um degradation_mode nomeado (mesma linha da audit(reproducibility): close the DL reproducibility contract & record pipeline identity in evidence #1451 e da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452), nunca silencioso.
  6. Privacidade do registro: não gravar hash do excerto. Identificadores como CPF têm pouca entropia, e o hash é reversível por força bruta. Gravar só ids de amostra, contagens e o hash do envelope de decisão.
  7. O Boar não embute nenhum modelo. Implementações do decisor (regra determinística, NER, modelo pequeno) ficam fora e são escolha do operador.

Fora de escopo

Implementar o decisor; escolher modelo; mudar limiares.

Critérios de aceite

  • Criar docs/plans/PLAN_REVIEW_BAND_HANDOFF.md com <!-- plans-hub-summary: ... -->.
  • Executar python scripts/plans_hub_sync.py --write.
  • Adicionar entry em docs/plans/PLANS_TODO.md.
  • Definição normativa da faixa, com os limiares reais confirmados por git grep -n 'medium_confidence_threshold', ligada à calibração da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452.
  • Schema JSON versionado do handoff classe M (campos, sem valor bruto).
  • Teste: sem consumidor, a saída é idêntica à atual e o degradation_mode fica registrado.
  • Teste negativo: nenhum valor bruto nem hash de excerto aparece no recibo, no log nem no envelope.
  • Decisão do operador registrada sobre a classe R (recomendação: fora da v1).
  • docs/CLAIMS.yml atualizado se houver claim novo; README e TECH_GUIDE sem afirmar LLM.

Fila e PR

Uma issue; no máximo 1 PR (plano, schema e testes); nunca uma PR por item. Prioridade e milestone são sugestão; o sequenciamento é do operador.

Relacionado: #1504, #1451, #1452, #1169, #1104.

🤖 Registrado por Claude (Opus 4.8, T14, auditor RO), a pedido do operador em 30/set/2026. Verificado por gh api no origin; nada executado. Implementação: Cursor. Tom recomendatório.

Activity

  1. added this to the backlog milestone on Sep 30, 2026
  2. FabioLeitao commented on Sep 30, 2026

    @FabioLeitao
    CollaboratorAuthor

    Regra do operador para qualquer sidecar: licença própria e zero trust bidirecional (30/set)

    Vale para o handoff da faixa de revisão (em especial a classe R, com excerto real) e para qualquer sidecar que o Boar venha a chamar:

    • Licença própria: o sidecar carrega a sua licença/grant; sem ela, fica OFF, nunca "grátis".
    • Zero trust nos dois sentidos: (1) o sidecar só processa payload depois de validar um grant assinado do Boar (escopo por coluna, capacidade, expiração); (2) o Boar valida o sidecar antes de enviar o primeiro byte (produto, versão e, quando aplicável, identidade do modelo: nome, revisão, sha256), e recusa um sidecar que se identifique como mock. Nenhum lado confia no dado do outro: validação de forma e tamanho na entrada e na saída, sem log de payload.
    • Falha fechada: qualquer verificação que falhe encerra o handoff, e o recibo registra o degradation_mode; o resultado do Boar não muda.

    O ecossistema já tem a metade "o sidecar verifica o chamador" (por exemplo o handshake.py do Stoat: "no attestation, no transform"). A metade "o chamador verifica o sidecar" é nova e deve entrar no PLAN desta issue. Não li a verificação de assinatura do Stoat; é mapa de papéis.

    🤖 Claude (Opus 4.8, T14, auditor RO). Tom recomendatório; nada implementado.

  3. FabioLeitao commented on Sep 30, 2026

    @FabioLeitao
    CollaboratorAuthor

    Correção (30/set, erro meu): no comentário acima eu disse que "a metade 'o chamador verifica o sidecar' é nova". Está errado. O Boar já tem o SDK bidirecional de atestação mútua — #1116 (CLOSED), ADR-0087, core/sdk/mutual_attestation.py (MeshRole host/guest, trust_is_acceptable_for_guest, challenge/response Ed25519, Safe-Hold em peer adulterado; PLAN_SDK_BIDIRECTIONAL.md). A classe R reusa esse contrato; o específico daqui é só o Boar exigir, no handshake, a identidade do decisor (produto/licença, versão, e — se for modelo — nome/revisão/sha256, recusando mock). Descoberto porque o Codex CLI apontou o PLAN_SDK_BIDIRECTIONAL.md que eu não tinha lido.

    🤖 Claude (Opus 4.8, T14, auditor RO). Correção de imprecisão própria.

  4. self-assigned this
    on Oct 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P3Low — backlog / nice-to-haveenhancementNew feature or request

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions