feat: implement Pillars 2-4 and fix a production false-positive in Pillar 1

Pillar 1 v1.1 (shipped earlier) flagged benign browsing bursts as
beaconing: on short captures, grid periods longer than the observed
span never complete a cycle, so significance saturates to 1 and the
score sticks at exactly 0.5. v1.2 caps the grid at a third of the
observed span, requires a minimum number of completed cycles, and
excludes protocols that are periodic by nature (NTP, DNS, mDNS,
ICMP). Validated against 300 seeds per scenario: false positives on
bursty traffic drop from the 290-300/300 that v1.1 produced to 0/300,
with every beacon-detection scenario scoring unchanged.

Add Pillar 2 (persistent/long-lived sessions, with Zeek's fragmented
TCP sessions rejoined after a 5-minute gap), Pillar 3 (DNS tunneling
via Shannon-entropy information volume per subdomain per hour; the
Jensen-Shannon divergence was measured and does not separate tunnels
from benign CDN subdomains, so it stays in the evidence at zero
weight instead of in the score), and Pillar 4 (deterministic
noisy-OR fusion across the three pillars).

The fusion formula was validated against 8 labeled real-traffic
vectors (IoT-23, CTU-Normal) with tolerance <= 1e-4. A known
limitation is kept, not hidden: a benign Philips HUE bulb's strict
periodic polling and a 21.9h session score it above three real C2
hosts. No weight or threshold was tuned to mask this; it is
documented in the architecture docs instead.

Also fixes real bugs found along the way: ingest_dir's partition
count summed file names instead of distinct dates, DuckDB errors
were counted as bad rows, /api/alerts always returned an empty list
regardless of the last analysis, and the dashboard still claimed
every pillar was unimplemented.

Restores four design corrections that were missing from
docs/architecture.md (KL to Jensen-Shannon, the persistent-session
detector, the JA4 licensing boundary, and deterministic reduction
order), and catalogs the public datasets used for validation
(IoT-23, CTU-Normal, Mendeley DTQBC) with their licenses and SHA-256
checksums under research/validation/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD

README.md

@@ -8,11 +8,11 @@
 
 ---
 
-**Status: pre-alpha skeleton.** The project structure, documentation, CI and
-compiling stubs exist. The four mathematical detection pillars, the real Zeek
-parser, DuckDB storage and the alert engine are **under development** and are
-not shipped yet. Nothing on this page should be read as a claim that detection
-already works.
+**Status: pre-release (initial version).** The project structure, documentation, CI,
+Zeek ingestion for `conn.log` and `dns.log`, DuckDB/Parquet analytical storage, and
+initial versions of detection pillars 1 to 4 are implemented and validated against
+public traffic. Automatic continuous ingestion and cross-restart alert persistence are
+planned for upcoming releases.
 
 Acauã is a network threat hunting engine built around deterministic evidence,
 not an opaque model. The goal is to answer not only "this looks suspicious" but
@@ -36,30 +36,26 @@ not an opaque model. The goal is to answer not only "this looks suspicious" but
 
 | Area | State |
 |---|---|
-| Rust workspace and CLI stubs | ✅ compiles |
-| Axum API with health, status, alerts and analyze routes | ✅ stub |
-| Embedded web dashboard | ✅ UI shell, served by daemon |
+| Rust workspace and CLI (`acaua`) | ✅ functional |
+| Axum API with health, status, alerts and analyze routes | ✅ functional |
+| Embedded web dashboard | ✅ UI served by daemon |
 | Documentation and CI/release workflows | ✅ |
 | Docker multi-arch image and compose deployment | ✅ |
 | DuckDB analytical store | ✅ official prebuilt library linked |
-| Four detection pillars | 🚧 under development |
-| Zeek log parser | 🚧 stub |
-| Alert evidence and scoring | 🚧 stub |
+| Four detection pillars (P1–P4) | ✅ initial version |
+| Zeek log parser (`conn.log`, `dns.log`) | ✅ functional |
+| Alert evidence and scoring | ✅ deterministic JSON + noisy-OR fusion |
 | Published releases | ❌ none yet |
 
 ## The four pillars
 
-All four are **under development**. The roadmap keeps them as future work, not
-as implemented features.
+All four pillars are implemented in their **initial version (v1)** and validated against synthetic fixtures and public captures:
 
-1. **Beaconing:** periodicity on event timestamps with a Rayleigh/Schuster
-   periodogram, and generalized Lomb–Scargle only where a real `y` exists.
-2. **Persistent sessions:** long connections that never produce a short `Δt`
-   and would otherwise stay invisible to a beaconing detector.
-3. **Protocol anomalies:** deterministic features over Zeek protocol logs,
-   including identity and lateral-movement signals.
-4. **Evidence fusion:** bounded, symmetric combination of pillar scores with a
-   reproducible evidence record per alert.
+1. **Beaconing (Pilar 1 v1.2):** periodicity on event timestamps with a Rayleigh/Schuster
+   periodogram bounded by the observed span, regularity significance gating, and infrastructure exclusions.
+2. **Persistent sessions (Pilar 2 v1.0):** long TCP connections chained across Zeek inactivity timeouts (up to 3600s gap without new SYN), log-scale persistence score, and PCR/failed attempt tracking.
+3. **Protocol anomalies (Pilar 3 v1.0):** deterministic information capacity (Shannon entropy $\times$ unique subdomain characters per UTC hour) in DNS queries to detect tunneling.
+4. **Evidence fusion (Pilar 4 v1.0):** per-host weighted noisy-OR combination ($w_1=w_2=w_3=0.75$) with deterministic JSON evidence and ranking.
 
 The design decisions behind these pillars, including the six corrections to the
 original blueprint, are in **[docs/architecture.md](docs/architecture.md)**.