Repository navigation
[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
Description
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 emcore/detector.py);- fuzzy de nome de coluna entre
fuzzy_min_confidence(25) efuzzy_max_confidence(45), só se pedido em config e com orapidfuzzinstalado; - 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
- Nenhum LLM decide achado no caminho crítico (audit(reproducibility): close the DL reproducibility contract & record pipeline identity in evidence #1451;
docs/SENSITIVITY_DETECTION.md; TECH_GUIDE, seção "Detection stack vs generative LLMs"). - FN-first: regex forte continua HIGH (
docs/SENSITIVITY_DETECTION.md). - Só metadados: o Boar não guarda o valor encontrado (README).
Proposta (síntese do Claude, a confirmar)
- 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. - Campo no envelope ([research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504):
review_bandmais 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. - 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.
- 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.
- Sem consumidor, sem mudança: o resultado é idêntico ao de hoje e o recibo registra um
degradation_modenomeado (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. - 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.
- 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.mdcom<!-- 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_modefica 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.ymlatualizado 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
FabioLeitao commentedon Sep 30, 2026
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:
degradation_mode; o resultado do Boar não muda.O ecossistema já tem a metade "o sidecar verifica o chamador" (por exemplo o
handshake.pydo 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.
FabioLeitao commentedon Sep 30, 2026
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(MeshRolehost/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, recusandomock). Descoberto porque o Codex CLI apontou oPLAN_SDK_BIDIRECTIONAL.mdque eu não tinha lido.🤖 Claude (Opus 4.8, T14, auditor RO). Correção de imprecisão própria.