Update README to document 4-run rule for warnings and immediate pass for errors

README.md

@@ -1,6 +1,6 @@
 # LOGAR: Edge-Thin Log Analysis & Temporal Verification System
 
-**LOGAR** is an enterprise log aggregation, verification, and anomaly detection architecture designed for heterogeneous server fleets (Windows & Linux). It combines lightweight zero-state edge forwarders with a centralized cloud hub that applies OpenPGP encryption, authenticated TCP streaming, temporal persistence tracking across 12-hour evaluation windows, and an automated 4-run rule to filter out transient infrastructure blips before reporting verified anomalies to **Hermes**.
+**LOGAR** is an enterprise log aggregation, verification, and anomaly detection architecture designed for heterogeneous server fleets (Windows & Linux). It combines lightweight zero-state edge forwarders with a centralized cloud hub that applies OpenPGP encryption, authenticated TCP streaming, temporal persistence tracking across 12-hour evaluation windows, an automated 4-run rule to filter transient warnings, and immediate pass-through for critical errors before reporting verified anomalies to **Hermes**.
 
 ---
 
@@ -27,14 +27,15 @@ Site agents running on Windows and Linux act strictly as lightweight forwarders:
 - **End-to-End Encryption**: Logs are encrypted using the server's OpenPGP public key before leaving the edge node.
 - **Secure TCP Sockets**: Ingestion occurs over low-overhead authenticated TCP sockets rather than bulky HTTP/HTTPS endpoints.
 
-### 2. Cloud-Side Temporal Persistence
+### 2. Cloud-Side Temporal Persistence & Severity Routing
 The central Python/TCP hub handles the heavy lifting:
 - State tracking is managed centrally in SQLite (`logar_state.db`).
 - Candidate issues are evaluated over a **12-hour temporal evaluation window**.
-- An issue must persist across **at least 4 consecutive runs / cycles** to be confirmed as a genuine system anomaly. Transient blips and sporadic spikes are filtered out automatically.
+- **Warning Persistence (4-Run Rule)**: `WARNING` level issues must persist across **at least 4 consecutive runs / cycles** within the 12-hour window to be confirmed as genuine anomalies, automatically filtering out transient blips.
+- **Immediate Error Pass**: Critical errors (`ERROR`, `CRITICAL`, `FATAL`) bypass the 4-run threshold and are promoted immediately to `VERIFIED` on their first occurrence.
 
 ### 3. Agentic Integration with Hermes
-Instead of human engineers manually diving through noisy logs, **Hermes** ingests pre-filtered, 4-run validated anomalies directly from the cloud hub (`GET /api/hermes/report`), treating them as verified system artifacts to trigger precise team notifications.
+Instead of human engineers manually diving through noisy logs, **Hermes** ingests pre-filtered anomalies directly from the cloud hub (`GET /api/hermes/report`), treating verified errors and 4-run validated warnings as actionable system artifacts to trigger precise team notifications.
 
 ---
 
@@ -111,11 +112,15 @@ Incoming candidate logs are tracked in SQLite table `active_issues`:
 - **Issue Fingerprint**: Formatted as `{site_name}:{server}:{signature}`.
 - **12-Hour Evaluation Window**:
   - When an issue is observed, the hub compares `(now - last_seen)`.
-  - If more than 12 hours have passed since the issue was last recorded, the previous window is expired and the cycle resets to `run_count = 1` with status `TRANSIENT`.
+  - If more than 12 hours have passed since the issue was last recorded, the previous window is expired and the cycle resets to `run_count = 1`.
-- **4-Run Rule**:
+- **4-Run Rule for Warnings**:
+  - The 4-run persistence threshold specifically applies to `WARNING` (and `INFO`) events to eliminate transient operational noise.
   - For each distinct run batch, `run_count` increments.
-  - Issues with `run_count < 4` are marked as `TRANSIENT` and ignored by downstream reporting.
+  - Warnings with `run_count < 4` are marked as `TRANSIENT` and excluded from Hermes reports.
-  - When `run_count >= 4` within the active 12-hour window, the status transitions to `VERIFIED`.
+  - When `run_count >= 4` within the active 12-hour window, the warning transitions to `VERIFIED`.
+- **Immediate Verification for Errors**:
+  - High-severity events (`ERROR`, `CRITICAL`, `FATAL`) **always pass immediately**.
+  - On their very first ingestion (`run_count = 1`), errors are promoted directly to `VERIFIED` and surfaced to Hermes without waiting for 4 runs.
 
 ---
 
@@ -124,7 +129,7 @@ Incoming candidate logs are tracked in SQLite table `active_issues`:
 The server hub serves a REST reporting API (default port `8443`):
 
 ### `GET /api/hermes/report`
-Returns exclusively **verified anomalies** that have satisfied the 4-run rule within the active 12-hour evaluation window:
+Returns all **verified anomalies** (immediate critical errors and warnings verified after 4 consecutive runs within the 12-hour evaluation window):
 
 ```json
 [