Observatório de sistemas
Recon produz dados; agentes precisam de evidência
No discovery do reconctx, o objetivo não é apenas acumular saídas de ferramentas, mas entregar um handoff em que cada afirmação continue ligada à evidência que a sustenta.
O problema não termina quando o recon acaba
Neste discovery, o reconctx parte de uma distinção operacional: uma coleção de saídas pode registrar o que as ferramentas devolveram, mas o handoff precisa manter cada fato ligado à sua origem e ao contexto em que foi produzido. O trabalho continua classificado como pesquisa pré-implementação, sem declarar um runner de produção pronto.[evidence-contract][discovery-status]
O contrato associa todo fato normalizado relevante à ferramenta e à versão usadas, à execução, ao timestamp, ao artefato bruto, à localização, à decisão de escopo e ao estado semântico. O identificador do contexto de autenticação permanece opaco e não carrega material de autenticação.[evidence-contract]
Proveniência antes de síntese
A ordem definida para a normalização valida e preserva o localizador do artefato bruto antes de avaliar escopo e criar registros de Evidence e Observation. Quando há lacunas, elas são emitidas de forma explícita em vez de desaparecerem durante a compactação.[normalization-contract]
Falha também precisa sobreviver ao handoff
- Execução parcial preserva a evidência válida e declara as lacunas.
- Formato não suportado, timeout, interrupção e sucesso com zero resultados mantêm estados distintos.
- Sem observações válidas, a execução não emite um handoff de sucesso enganoso.
Antes da entrega, o gate verifica schema, referências, localizadores, hashes, checksums, caminhos, material sensível e declaração de lacunas. O compilador também proíbe a promoção automática de dados de recon para finding ou severidade.[integrity-contract]
O que o fixture sanitizado mostrou
No benchmark registrado, o handoff compacto respondeu dez perguntas comuns sem drilldown, citou quinze Evidence IDs existentes e não confundiu histórico com observação atual nem promoveu uma vulnerabilidade a partir do recon.[handoff-benchmark]
Nesse mesmo registro, a condição compacta usou 7.064 bytes de fonte e duas chamadas, enquanto a condição raw usou 9.332 bytes únicos e oito chamadas. Os tempos registrados incluem overhead de agente e ferramentas, por isso são direcionais e não constituem um benchmark controlado de CPU.[handoff-benchmark]
A checagem executada em 2026-07-16 validou os checksums dos 29 arquivos listados no exemplo sanitizado. Isso confirma a integridade dos arquivos cobertos pela lista, não a correção universal do produto.[handoff-integrity]
Limitações
Onde esta conclusão termina.
- O benchmark usa um fixture sanitizado e não prova o mesmo resultado em recon externo ou em outros agentes.
- O identificador do modelo não estava disponível no registro do benchmark.
- As medições de runtime incluem overhead de agente e ferramentas e não constituem benchmark controlado de CPU.
- Alguns diagnósticos do handoff ainda não possuem Evidence ID próprio.
- O projeto permanece em discovery pré-implementação; este artigo não descreve um runner de produção pronto.
Proveniência
Fontes citadas.
- [evidence-contract]Contrato de evidência do reconctx
- [normalization-contract]Contrato de normalização e proveniência
- [failure-contract]Matriz de falhas do pipeline
- [integrity-contract]Gate de integridade do handoff
- [handoff-benchmark]Benchmark registrado do handoff compacto
- [handoff-integrity]Verificação atual do exemplo sanitizado
- [discovery-status]Estado declarado do discovery