Alerta de enchente hoje é binário e tardio: o operador olha o nível cruzar um número (estágio de ação/menor/moderado/maior) publicado pelo NWS. O TUBE retém a série de nível com bound de erro garantido e transforma "quantas leituras passaram do estágio X?" numa consulta que se prova — e a mesma surpresa de compressão que detecta um rolamento gasto ou uma tempestade geomagnética detecta a subida de um rio, antes do número oficial ser cruzado. Dado real: USGS 03451500 — French Broad River em Asheville, NC, nível (gage height, 00065) a cada 15 min, cobrindo a enchente recorde da furacão Helene (set/2024).
Os quatro brackets foram verificados contra o dado original: a verdade (contagem exata nos 1.344 valores crus) cai dentro de cada intervalo, e a classificação por índice bate 100% com o full-scan decodificado — consistência índice=full-scan ✓ nas quatro consultas. A poda toca cada vez menos do arquivo comprimido conforme o estágio sobe: 25,0% dos blocos para "acima de ação" até 7,1% para "acima de maior" — a pergunta mais rara é a mais barata de responder.
A surpresa cresce continuamente a partir de ~25/09 16h (nível ainda em 2,22 pés, calmo) e passa a ficar sustentada acima de 50% às 25/09 18h — quase 6 horas antes de o rio sequer estar perto do estágio de ação. O detector operacional (abaixo) formaliza esse gatilho.
7h45 de antecedência, medida no dado real — não estimada. O mesmo pipeline que retém o nível por 37,6× menos bytes já está emitindo o alarme de graça, antes de o número que o boletim oficial usa sequer se mexer perto do limiar.
37,6× menor que o bruto f64 (286 B vs 10,5 KB), 8,6× menor que o gzip. Deadband 74,7% — quase 3 em 4 leituras não-keyframe não precisaram ser transmitidas porque o rio estava dentro do bound do que já foi visto. Bound nunca violado (maxerr/ε = 1,00).
1. ε escolhido por política, não por spec do sensor exato. Não existe um "datasheet" único do transdutor deste posto — usamos a política do USGS Office of Surface Water (memorandos SW93.07 e SW96.05): exatidão de leitura de nível = max(0,01 pé; 0,2% do valor de estágio). No topo da escala deste evento (estágio 18–24,8 pés) isso dá ≈0,04–0,05 pé; escolhemos um único ε=0,05 pé, conservador e constante para o canal inteiro, porque o codec aplica um bound fixo por canal — não um bound que varia com o valor. Em nível baixo (ex.: 1,3 pé no início da série) esse mesmo ε=0,05 é mais folgado que a política pediria (0,01 pé) — decisão de engenharia, documentada, não medição.
2. A surpresa crua tem um falso positivo real neste dado — e o motivo é interessante. Numa noite completamente calma (22–23/set, nível estável em 1,35–1,36 pé, variação líquida de ~0,01 pé em 4h) o detector de deadband simples chegou a marcar 100% de emissão por várias janelas seguidas: o nível estava oscilando bem perto de uma fronteira do quantizador (step=2ε=0,10 pé), então o mesmo ruído de leitura de 0,01 pé do sensor foi suficiente para o valor reconstruído "pular" o bound repetidamente, sem o rio de fato subir. Um detector operacional que confiasse só na fração de surpresa teria disparado um alarme falso ali. Por isso o gatilho relatado acima exige surpresa sustentada + subida líquida mínima confirmada — a combinação que separa "chuva chegando" de "ruído de quantização parado no limite". Isso é uma limitação real do detector ingênuo, não um ajuste cosmético para a demo funcionar.
3. Este posto específico não teve gap durante o próprio evento — mas isso não é garantido em geral. O registro iv aprovado (qualificador "A" em todas as 1.344 leituras) não tem nenhuma lacuna relevante durante a subida, o pico ou a descida — só um intervalo isolado de 30 min na madrugada de 28/09, já na recessão. Isso é uma sorte de engenharia, não a regra: o USGS estimou que 10 a 20 postos na região de Asheville/upstate SC foram danificados ou submersos pela Helene e precisaram de reparo/recoleta manual de dado. Um demo construído sobre um dos postos que falhou no pico teria exatamente o buraco que mais importa — no meio do evento — e é isso que qualquer sistema real de alerta precisa assumir como cenário, não como exceção.
4. O número "final" já mudou desde o dia do desastre. A imprensa noticiou em set/2024 um pico provisório de 24,67 pés (batendo o recorde de 23,10 pés de 1916). O valor que está hoje no NWIS iv, já com qualificador "aprovado", é 24,82 pés — 0,15 pé mais alto que o número que circulou no dia. A diferença é pequena, mas real: é exatamente por isso que existe uma etapa de aprovação/QA, e é o motivo pelo qual qualquer prova certificada como esta precisa dizer quando o dado foi puxado do NWIS, não só de onde.
5. Usamos nível (gage height), não vazão. Os 4 estágios de enchente do NWS são definidos diretamente em pés de nível — por isso esta consulta certificada não depende da curva-chave nível→vazão (rating curve), que é conhecida por degradar em eventos recordes (a extrapolação além da maior vazão já medida diretamente, e o efeito de sedimentação/erosão do canal após um evento desse porte). Se este demo fosse sobre vazão (cuft/s, parâmetro 00060), essa limitação valeria e precisaria ser dita — aqui, não se aplica.
Por que isso importa para alerta de enchente. O boletim de defesa civil já confia no cruzamento de um número — e esse número, medido aqui, chega quase 8 horas depois do compressor já estar gritando. A surpresa do TUBE roda no mesmo pipeline que já reteria o nível por custo de armazenamento — de graça — e dá ao operador uma janela real de antecedência, com prova (bracket certificado, consistência índice=full-scan) em vez de "achismo de dashboard". Honesto: 7h45 é o que este posto e este evento mediram — outro rio, outra topografia de bacia, outro tempo de concentração, dá outro número; o método (surpresa sustentada + confirmação de subida) generaliza, o número específico não. Dado real: USGS 03451500, French Broad River em Asheville, NC — série iv 00065, 20/set–03/out/2024. Estágios: NWS AHPS, posto AVLN7. TUBE e gzip/gorilla no mesmo dado, mesmo ε.