[research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope

Contexto

Sessão de 2026-08-09: três peças desconectadas convergiram no mesmo dia, sem coordenação
deliberada entre elas:

insecure= do OTel (core/otel_setup.py, [P2][feat] Instrument Data Boar with OpenTelemetry (RED metrics + traces) — code-level, receiving end already live #1500 / PR feat(otel): opt-in OpenTelemetry RED metrics and traces (#1500) #1503) — TLS real por default,
plaintext só permitido em loopback (127.0.0.1/localhost/::1).
--validate-crypto opt-in (PR feat(scan): Order 5 Phase 1 — opt-in --validate-crypto wiring #1501, "Order 5 Phase 1", mergeada hoje) — coleta de
sinal de crypto agora gateada atrás de flag explícita; Fases 2–4 ("full TLS criteria,
heuristics, report sheet") já reservadas no plano Order 5.
Beacon de telemetria do site (data-boar-site#59) cortando query string e referrer
completo pra bater de fato com a política zero-PII do PLAN_SITE_ANALYTICS.md, não só
declará-la em prosa.

Observação

O repositório começou a mostrar o plano pela estrutura do produto, não só pelos documentos.
Isso sugere um próximo salto natural: um evidence envelope único que amarre trust_state

crypto_controls_audit + atestação (identidade/assinatura) + release integrity (SSHSIG) +
telemetria OTel num mesmo artefato — findings + condições de execução sob as quais foram
encontrados + trust reasons + crypto/control posture + identidade/attestation + versão/config
relevante.

Isso é uma diferença de categoria, não incremental: o relatório deixa de dizer só "achei X" e
passa a dizer "achei X, sob estas condições verificáveis, com este nível de confiança que
consigo defender mecanicamente" — sem o scanner virar juiz de conformidade jurídica, só uma
testemunha melhor. Aproxima o produto da fronteira entre data discovery, compliance
engineering e evidence engineering.

O que já existe (não é greenfield)

Trust model — já é conceito estabelecido no produto.
Atestação — doutrina de chave já existente.
Release integrity — SSHSIG já obrigatório em todo commit do repo.
Crypto controls audit — Order 5 Phase 1 (PR feat(scan): Order 5 Phase 1 — opt-in --validate-crypto wiring #1501) já shipped hoje; Fases 2–4 no roadmap.
Telemetria OTel — opt-in, shipped hoje ([P2][feat] Instrument Data Boar with OpenTelemetry (RED metrics + traces) — code-level, receiving end already live #1500).

O que falta é a costura: um schema único de evidence envelope, em vez de N sinais espalhados
em N lugares diferentes do relatório.

Status

Lead de pesquisa, não feature comprometida ainda. Aberta como issue (em vez de ficar só
em conversa/backlog) porque ideias sem issue tendem a ser adiadas ou só enriquecidas
indefinidamente sem nunca cristalizar em trabalho rastreável.

Se/quando isto virar feature escopada, AC obrigatória: criar
docs/plans/PLAN_EVIDENCE_ENVELOPE.md, executar scripts/plans_hub_sync.py --write,
adicionar entry em docs/plans/PLANS_TODO.md.

Aberta por Claude Code (auditor RO) a pedido do operador — captura de insight estratégico
da sessão, não decisão de escopo/prioridade.

Refinamento arquitetural (operador, 2026-08-09)

Ressalva importante sobre escopo do envelope: OTel deveria entrar como referência/correlation
evidence, não como payload bruto — trace_id, span_id, identidade do collector e status de
export, timestamps relevantes. Telemetria bruta dentro do envelope vira um saco de dados em vez
de um artefato probatório compacto.

Proposta de schema conceitual (primeira forma, não implementação)

evidence_identity — qual scan/session/report é este
subject — o que foi examinado
execution_context — versão, config digest, timestamps, runtime relevante
trust — state, reasons, confidence
crypto_controls — controles verificados + resultado + método
integrity — artefatos/manifest hashes + release/commit identity
attestation — assinatura, signer/key identity, verification result
findings_digest — vínculo criptográfico com os findings reais
telemetry_correlation — trace/span IDs e destino OTel, se habilitado (não a telemetria em si)
limitations — o que não foi verificado / N/A / deferred

Decisão considerada crucial: machine-first

O envelope deveria ser machine-first e deterministicamente serializável (canonical
JSON/CBOR ou equivalente) — Excel/PDF/DOCX são renderizações desse estado, não o artefato
"verdadeiro" em si. Isso evita que a planilha vire a fonte de verdade por acidente.

Possibilidade futura (não escopo desta lead, registrar como direção)

Assinar o envelope inteiro, incluindo hashes dos outputs associados — um manifest probatório
onde relatório humano, findings JSONL, audit trail, crypto-controls e demais exports ficam
ligados por digest a uma única declaração assinada.

Framing reafirmado

Continua evitando o Data Boar virar "juiz jurídico" — o objetivo é ser uma testemunha técnica
muito melhor, não uma autoridade de conformidade. Enquadramento válido academicamente,
comercialmente e arquiteturalmente.

Registrado por Claude Code (auditor RO) — síntese fiel da refinação do operador nesta sessão,
não decisão de escopo/prioridade/implementação.

Adendo arquitetural (operador, 2026-08-09) — pra quando isto virar PLAN formal

Duas adições ao schema conceitual do comentário anterior, sem as quais a assinatura futura do
envelope vira dor por diferenças irrelevantes de serialização:

schema_version logo no topo — versionamento explícito do próprio formato do envelope,
não só do produto.
Política explícita de canonicalização/hash — como o JSON/CBOR é normalizado antes de
hashear/assinar (ordenação de chaves, encoding, whitespace). Sem isso definido, a mesma
evidência lógica pode gerar hashes diferentes por acidente de serialização, quebrando o
binding criptográfico que é o ponto inteiro do manifest assinado.

E uma separação de campos: producer_identity separado de evidence_identity — quem
produziu (a instância/versão do Data Boar, o operador/execução) versus qual evidência foi
produzida (o scan/session/report em si). São perguntas diferentes e merecem campos diferentes.

Registrado por Claude Code (auditor RO) — síntese fiel do adendo do operador. Ainda research
lead; estas duas adições só viram obrigatórias quando/se PLAN_EVIDENCE_ENVELOPE.md for
escrito.

Achado real de segurança — lição pra política de sanitização do envelope (Latitude, 2026-08-09)

Via coordenação cross-host (T14 ↔ Latitude, SSH+tmux direto entre sessões Claude, pra evitar
colisão no data-boar — Latitude está em feat/order5-phase2c-mongo-redis-crypto, estendendo
crypto_controls_audit).

Durante Order 5 Phase 2a (PR #1502, feat(scan): Order 5 Phase 2a — SQL strong-crypto + Crypto & controls sheet, merged 0bd4b6f1), o parser de fallback de sslmode para DSN libpq
(formato espaço-separado, não só query string com &) podia vazar senha embutida na DSN
para strong_crypto_details — campo que é persistido e exportado na planilha. Corrigido com
allowlist estrita dos valores reais de sslmode (nunca aceita texto arbitrário), testado com
regressão usando senha real na DSN. Bugbot rodou depois, sem achados.

Por que isso importa pro #1504: é a terceira instância do mesmo padrão nesta sessão —
insecure=True hardcoded no OTel (#1500), location.search/referrer crus no beacon (site#58),
e agora parsing de sslmode vazando credencial de DSN (#1502). Regra emergente, não decretada:
qualquer campo do envelope que venha de fonte não-confiável (DSN, URI, config bruta, referrer,
query string) precisa de allowlist-only, nunca passthrough — sanitizar antes de persistir,
não só antes de exibir.

⚠️ Schema crypto_controls ainda é alvo em movimento. Order 5 segue: Phase 2c (Mongo/Redis,
em andamento agora) → Phase 2d (SMB) → Phase 3 (heurísticas de anonimização — *_hash, anon_*
etc). O envelope não deveria fechar o formato de crypto_controls antes disso estabilizar.

Registrado por Claude Code (auditor RO, T14) — relato de achado do Claude Code (Latitude),
repassado fielmente via coordenação cross-host desta sessão.

Scope split after ecosystem/SDK review — domain manifest vs cross-Bestial receipt

This research should remain in data-boar: the proposed machine-first evidence manifest legitimately contains Data Boar domain semantics such as findings binding, scan/session identity, crypto-controls posture, trust reasons and report/output linkage.

However, the private ecosystem/SDK review exposes a second, smaller interoperability problem that should NOT be solved by turning the Data Boar manifest into a universal Bestiais mega-schema.

Keep here: Data Boar Evidence Manifest

Examples of Data-Boar-owned semantics:

subject / scan/session
findings_digest
crypto_controls
scan limitations / coverage
Data Boar trust_state/reasons
report/export digests
Data Boar telemetry correlation

This remains the richer domain artifact.

Separate SDK research: minimal cross-Bestial Evidence Receipt / Provenance Envelope

A cross-Bestial receipt should only bind stages/artifacts without understanding every producer's domain payload. Candidate concepts, not frozen field names:

schema_version
producer_identity
execution_id
input_artifact digest/ref(s)
output_artifact digest/ref(s)
started_at / completed_at
provenance / integrity
attestation / verification result
assurance / limitations
domain_artifact_type
domain_artifact digest/ref

The receipt should permit chains such as:

Bestial A domain artifact + receipt
        ↓ digest/reference
Bestial B domain artifact + receipt
        ↓
Bestial C ...

without requiring B to understand A's full schema.

This also preserves future Bestials: a new application can join the ecosystem by honoring SDK contracts and verifiable artifact references rather than importing every historical domain schema.

Important separation

Domain evidence belongs to the domain producer. Cross-Bestial provenance belongs to the interoperability contract.

OTel remains correlation/reference evidence, not bulk payload. Canonicalization/versioning/signature policy already discussed in this thread remains essential for the Data Boar manifest and should inform, but not automatically dictate, the smaller SDK receipt.

A dedicated SDK R&D issue is being opened for this split. Preserve this issue and its comments as the authoritative lead for the richer Data Boar Evidence Manifest.

— ChatGPT · GPT-5.6 Sol · ChatGPT/Web harness · research/audit/steering node · A.I.I.D.C.O.B.P.P. v1.5-exp

Scope boundary — this remains the rich Data Boar Evidence Manifest; shared only gets the minimal receipt spine

After reconciling this lead with the private Bestial roster and data-boar-shared#6, I would not move or genericize this issue.

The schema discussed here is legitimately Data-Boar-specific because it binds product-domain concepts such as:

scan/session subject;
findings digest;
Data Boar trust_state;
crypto-controls audit;
scan/runtime execution context;
report/output binding;
telemetry correlation relevant to this product.

That rich manifest should stay owned/versioned by data-boar.

The cross-Bestial layer should only reuse a minimal receipt/provenance spine, e.g. producer/evidence identity, execution/correlation identity, input/output digests, timestamps, provenance/integrity/attestation, assurance/degradation and a domain-artifact digest/ref.

Conceptually:

Data Boar Evidence Manifest
  = rich domain artifact

DataBoar shared/SDK receipt envelope
  = small transport/provenance contract

Do not flatten these into one universal schema.

Additional implications

canonicalization/signature policy here can inform the shared receipt, but each schema versions independently;
a consumer that only needs provenance may verify/transport the receipt without understanding Data Boar findings/crypto-control internals;
cross-Bestial chaining should use digests/references rather than recursively embedding prior full manifests;
data-boar-shared#6 should be the cross-Bestial convergence point, not a second copy of this schema.

This preserves the strongest part of #1504: Data Boar becomes a better technical witness for its own domain, while the ecosystem composes evidence without forcing every Bestial to understand Boar semantics.

— ChatGPT · GPT-5.6 Sol · ChatGPT/Web harness · research/audit/steering node · A.I.I.D.C.O.B.P.P. v1.5-exp

Auditor note — upstream of this issue is closed cleanly (Order 5 + S2a slice)

Cycle check 2026-08-10 against the repo’s own rito (plan → issue/PR → code → docs EN → pt-BR echo → completed/):

Order 5 — strong crypto & controls

Plan archived: docs/plans/completed/PLAN_OPTIONAL_STRONG_CRYPTO_AND_CONTROLS_VALIDATION.md
Hub: PLANS_TODO marks Strong crypto & controls validation ✅ Done (Phases 1–4)
Close-out PR: docs(plans): close Order 5 Phase 4 strong-crypto polish #1519 (regression: crypto probe must not abort sampling; disclaimer/sheet notes; plans-stats sync)
Operator surface synced in-phase (USAGE / TECH_GUIDE / --validate-crypto / API / dashboard), not deferred

S2a transport + trust (related inputs for an envelope)

Revert "feat(api): S2a wave-2a TLS cipher/protocol posture probe" #1495 revert → feat(api): S2a wave-2a TLS posture (env-safe for workers) #1496 env-safe TLS posture for uvicorn workers (DATA_BOAR_TLS_POSTURE) — fix-forward, not silent retry
feat(api): S2a wave-2b cert fingerprint allow-list #1497 cert fingerprint allow-list; report tint and trusted-proxy follow-ons shipped in the same window
Docs EN + test_docs_pt_br_locale exercised on those PRs

Implication for #1504

This issue can treat as already on main:

opt-in scan.validate_crypto / crypto_controls_audit + Excel Crypto & controls
canonical trust_state / trust_reasons / TLS posture signals

What remains here is the unification story (single evidence envelope), not re-litigating Phase 1–4 delivery. Optional polish outside this issue: one short lesson-learned note for the worker fork / module-global vs env publish path (#1495→#1496) if you want it in ADR or on the completed S2a/HTTPS plan — code is already source of truth.

— auditor pass

Auditor note — evidence envelope vs existing methodology (2026-08-10)

Session synthesis (operator-authorized board enrichment). Do not treat as new product scope until HITL prioritizes.

Already canonical (do not re-litigate)

docs/COMPLIANCE_METHODOLOGY.md — technical questions only; modules M1–M7; never auto-assert base legal / titular; ROPA columns automation priority.
docs/CANONICAL_PRODUCT_FACTS.md §3 — deterministic-first / local-first / evidence ≠ legal conclusion / overclaim-safe.
docs/CLAIMS.yml + CI — headline claims must be backed_by.
Order 5 + S2a on main — crypto_controls_audit, trust_state (inputs to an envelope, not the envelope itself).

Product reminder (operator)

Data Boar is not “LGPD-only scanner” and not “PII-only”: regime/sample is YAML-distance (any compliance profile, country, locale, encoding path as engineered); surface is discovery + evidence + reports + posture signals — data soup, not a single-jurisdiction audit app.

Envelope research should absorb (gaps relative to methodology prose)

Terminal target states as first-class evidence: scanned | failed | skipped | unavailable | partial (and equivalent) so “0 findings” cannot mean “looked everywhere and found nothing” when coverage failed.
Observability completeness of the scan itself as a field alongside findings (sibling [P2][sre][research][evidence] Mine awesome-sre for reliability-evidence, production-readiness and observability-completeness patterns #1521 hyp. 2) — orthogonal to trust_state.
Single artifact binding: findings + config/profile digest + engine version + coverage/limitations + optional trust/crypto — [research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504 thesis, without inventing a mega-schema.

Cross-link: site positioning DataBoar/data-boar-site#31 (DPO as partner / MSP flywheel — not DPO replacement).

— auditor pass

O envelope como contrato de passagem entre as BFFs, em vez de embutir os poderes no Boar (30/set)

Recomendo desenhar o schema do envelope como o contrato de handoff da cadeia achar → decidir → confirmar → transformar → atestar → provar, com cada papel na BFF que já existe (só mapa de papéis; não li a API de nenhuma delas):

Faixa de revisão (amostra ambígua): primeiro as gêmeas Clojure determinísticas (Sage Remora / Faithful Ferret); um decisor de conjunto fechado, opt-in, só depois.
Remediação e máscara: Stealthy Stoat (tokenização), consumindo os achados do envelope. O Boar continua "achando".
Assinatura: Homing Robin (atestação Ed25519 offline-first).
Prova de apagamento: Tidy Tortoise.
Re-identificação por combinação de quase-identificadores: hoje é heurística (Aggregated identifiability risk); vale avaliar o Remora (re-id/linkage) antes de ampliar a heurística.
Encoder do DL: ver a avaliação do Latent Lynx na audit(reproducibility): close the DL reproducibility contract & record pipeline identity in evidence #1451.

Consistência com a linha da #1451 ("nenhum LLM decide achado no caminho crítico") e com docs/SENSITIVITY_DETECTION.md ("not generative LLMs", determinístico, sessões comparáveis): um LLM ou SLM dentro do processo do Boar para desempatar amostras ambíguas contradiz isso. O desempate mora fora, consumindo o envelope, com a CLJ determinística na frente.

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

Ponteiro (30/set): a faixa de revisão vira campo do envelope (review_band + motivo, sem o valor). Detalhe e critérios de aceite na #2023.

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

Navigation Menu

Repository navigation

[research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504

Contexto

Observação

O que já existe (não é greenfield)

Status

Refinamento arquitetural (operador, 2026-08-09)

Proposta de schema conceitual (primeira forma, não implementação)

Decisão considerada crucial: machine-first

Possibilidade futura (não escopo desta lead, registrar como direção)

Framing reafirmado

Adendo arquitetural (operador, 2026-08-09) — pra quando isto virar PLAN formal

Achado real de segurança — lição pra política de sanitização do envelope (Latitude, 2026-08-09)

Scope split after ecosystem/SDK review — domain manifest vs cross-Bestial receipt

Keep here: Data Boar Evidence Manifest

Separate SDK research: minimal cross-Bestial Evidence Receipt / Provenance Envelope

Important separation

Scope boundary — this remains the rich Data Boar Evidence Manifest; shared only gets the minimal receipt spine

Additional implications

Auditor note — upstream of this issue is closed cleanly (Order 5 + S2a slice)

Order 5 — strong crypto & controls

S2a transport + trust (related inputs for an envelope)

Implication for #1504

Auditor note — evidence envelope vs existing methodology (2026-08-10)

Already canonical (do not re-litigate)

Product reminder (operator)

Envelope research should absorb (gaps relative to methodology prose)

O envelope como contrato de passagem entre as BFFs, em vez de embutir os poderes no Boar (30/set)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504

Description

Contexto

Observação

O que já existe (não é greenfield)

Status

Activity

FabioLeitao commented on Aug 9, 2026

Refinamento arquitetural (operador, 2026-08-09)

Proposta de schema conceitual (primeira forma, não implementação)

Decisão considerada crucial: machine-first

Possibilidade futura (não escopo desta lead, registrar como direção)

Framing reafirmado

FabioLeitao commented on Aug 9, 2026

Adendo arquitetural (operador, 2026-08-09) — pra quando isto virar PLAN formal

FabioLeitao commented on Aug 9, 2026

Achado real de segurança — lição pra política de sanitização do envelope (Latitude, 2026-08-09)

FabioLeitao commented on Aug 10, 2026

Scope split after ecosystem/SDK review — domain manifest vs cross-Bestial receipt

Keep here: Data Boar Evidence Manifest

Separate SDK research: minimal cross-Bestial Evidence Receipt / Provenance Envelope

Important separation

FabioLeitao commented on Aug 10, 2026

Scope boundary — this remains the rich Data Boar Evidence Manifest; shared only gets the minimal receipt spine

Additional implications

FabioLeitao commented on Aug 10, 2026

Auditor note — upstream of this issue is closed cleanly (Order 5 + S2a slice)

Order 5 — strong crypto & controls

S2a transport + trust (related inputs for an envelope)

Implication for #1504

FabioLeitao commented on Aug 10, 2026

Auditor note — evidence envelope vs existing methodology (2026-08-10)

Already canonical (do not re-litigate)

Product reminder (operator)

Envelope research should absorb (gaps relative to methodology prose)

FabioLeitao commented on Sep 30, 2026

O envelope como contrato de passagem entre as BFFs, em vez de embutir os poderes no Boar (30/set)

FabioLeitao commented on Sep 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions