Every metric is traceable. Every claim is reproducible. Every artifact is committed.
The pipeline doesn’t need a human to defend it — it publishes its own proof.
Sourcecurrent-authority.json
Locked04-07-2026
Verified04-07-2026
HeartbeatSUCCESS
ReconciliationPASS
210 detection rules + 10 IR playbooks103 Sigma28 Wazuh rule blocks79 Splunk SPL (lab)10 IR playbooks
Public benchmark snapshot: reviewer-authoritative values from data/truth/current-authority.json.
Runtime snapshot: telemetry from data/truth/current-live.json, displayed as informational only.
CLAIM: AutoSOC processed 324,074 alerts, auto-closed ~88%, and produced 8,574 escalations across 8/8 coverage.
CONTEXT: Current-facing metrics on this page are locked to the April 7, 2026 canonical snapshot. Historical recovery evidence remains linked as historical context only.
EVIDENCE:docs/execution/AUTOSOC_PIPELINE_RECOVERY_CASE_STUDY_03-13-2026.md -> final run shows run_id=autosoc-20260313T215029Z-31020, status=SUCCESS, cases_processed=173, reconciliation.mismatch_count=0; proves real output and validated recovery.
EVIDENCE:/assets/pp_soc_integration/t3-workflow.png -> proves a concrete workflow snapshot of the triage and evidence-pack pipeline surface.
~88%
Auto-Close Rate
↗ Computation method
8,574
Published Escalations
↗ What each escalation pack contains
Field notes
Engineering case studies
Operational decisions documented from source evidence — pipeline logs, preflight output, scheduler metadata. Not post-hoc summaries.
The pipeline was exercised through a documented recovery event. The run log below proves a real execution cycle with zero reconciliation mismatches — not a hand-maintained health claim.
Pipeline recovery case study from 03-13-2026. Final run: run_id=autosoc-20260313T215029Z-31020, status=SUCCESS, cases_processed=173, reconciliation.mismatch_count=0. Proves concrete execution output and validated recovery path.
Historical reference only — not current-facing authority
Splunk Evidence
Splunk Proof Lane
Scope: home lab environment.79 Splunk detection searches across 9 SPL files were written and tested against Wazuh-forwarded log data in a local Proxmox VM (vm104). This is not a production SOC or enterprise Splunk deployment. The evidence below reflects that honest scope.
Detection inventory
Splunk Query Count
Splunk detection searches:79 across 9 SPL files (lab environment, home lab only)
Context: Queries target Wazuh-forwarded events ingested via Splunk Universal Forwarder in vm104
Claim ceiling: Lab-deployed, integration-tested; not enterprise, not production SOC
Artifact reference
Splunk Ingest Proof
Pipeline proof artifact confirms Splunk ingest was operational for the locked reviewer snapshot. The export remains in the repository under the Splunk evidence path.
Splunk role: home lab only — verified per current-authority.json claim ceiling
Historical Reference
Historical Evidence Artifacts
The following artifacts pre-date the April 7, 2026 authority snapshot. They are preserved as supporting evidence for the operational timeline but must not be read as current authority.
Historical benchmark reference
Canonical Metrics Snapshot
The canonical metrics artifact records the locked benchmark used for the current public authority layer. Treat it as historical support, not live telemetry.
Historical only — superseded by the current authority snapshot
Historical detection validation
Continuous Detection Validation
The automated validation suite passed all required checks for the locked public benchmark and preserved the supporting proof artifacts in the repository.
Clone the repository, run the public verification commands, and compare output to the committed proof artifacts. The KPI ledger above reflects the latest committed proof snapshot — not a hand-maintained health claim.
Source: current-live.json (_layer_rank 2) — non-authoritative for public claims. Reviewer-authoritative metrics are in the KPI ledger above.
DETAILS
Metric definition
Total cases is the cumulative count of alert events ingested and processed by the SignalFoundry pipeline since operational baseline. Each case corresponds to one Wazuh alert that entered the triage loop and received a disposition.
What is counted
A case is counted when poll-alerts.py ingests a Wazuh alert and triage.py assigns a disposition: AUTO_CLOSE_BENIGN, AUTO_CLOSE_KNOWN_FP, or ESCALATE. Cases that stall before disposition are not counted.
What is excluded
Duplicate alert events deduplicated at ingest
Test/synthetic events injected during pipeline development
Cases that did not complete the redaction gate
Provenance
Value sourced from data/truth/current-authority.json — metrics.stable_total_cases. Derived from the operational ledger at the locked authority snapshot. Confirmed by scripts/verify/verify-counts.ps1.
Auto-close rate is the percentage of total cases that received a AUTO_CLOSE_BENIGN or AUTO_CLOSE_KNOWN_FP disposition without requiring analyst escalation.
~88% auto-close means the pipeline deterministically handled roughly 285,625 of 324,074 cases through benign plus known-false-positive handling without analyst escalation. The remaining cases either escalated or were flagged for manual review. This demonstrates the signal-to-noise reduction the triage policy enforces.
Label format
Displayed as ~88% (approximate label) because the operational ledger uses integer counts and the displayed percentage is rounded. The raw combined count is auto_closed_benign + known_fp = 285,625.
285,625 auto-closed324,074 total85,953 known_fp
What an escalation is
An escalation is a case where triage.py assigned disposition ESCALATE, triggering assemble-pack.py to generate a structured evidence pack and publish it as a GitHub artifact.
What each escalation pack contains
00_one_pager.md — intake summary, analyst-ready
01_full_report.md — investigative narrative with full context
02_timeline.csv — event timeline with timestamps
03_queries.md — reproduction queries for the alert
04_closure_report.md — disposition rationale and audit trail
All packs pass the redaction gate before publication. Host identifiers, internal IPs, and environment-specific values are sanitized per PROOF_PACK/REDACTION_RULES.md.
Provenance
Value: escalated: 8574 from data/truth/current-authority.json. This is an exact integer count, not an approximation.
8,574 exactpublished to GitHubredaction-gated
Coverage definition
8/8 means all monitored lab endpoints were actively reporting telemetry at the time of the authority snapshot. Coverage is computed by the pipeline gate: if any endpoint stops reporting, coverage drops and the gate fails.
Endpoint roster
Specific host identifiers are redacted per the repo redaction policy. The roster below uses sanitized labels. All endpoints are Proxmox VMs in the home lab environment.
lab-endpoint-01 · REPORTING
lab-endpoint-02 · REPORTING
lab-endpoint-03 · REPORTING
lab-endpoint-04 · REPORTING
lab-endpoint-05 · REPORTING
lab-endpoint-06 · REPORTING
lab-endpoint-07 · REPORTING
lab-endpoint-08 · REPORTING
Last confirmed: authority snapshot · Identifiers redacted per repo redaction policy · Lab environment only
What a coverage failure looks like
If any endpoint goes silent, the pipeline coverage gate sets coverage_status: FAIL and the heartbeat drops to a warning state. No coverage failure was recorded in the authority snapshot.
8/8 reporting0 gapsProxmox labWazuh agents
What reconciliation means
Reconciliation is a post-run ledger check. After the pipeline processes a batch of cases, it compares the count of cases that entered the triage loop against the count of cases with committed dispositions. A mismatch means a case was lost or processed twice.
PASS definition
PASS (0 mismatches) means: for every case ingested, exactly one disposition was recorded. No cases dropped. No cases duplicated. The ledger is clean.
This matters because evidence packs depend on the triage ledger being accurate. If a case slips through without a disposition, an escalation artifact may never be generated — silent evidence loss. PASS means that didn’t happen.
Provenance
Value: reconciliation_mismatch: 0 from data/truth/current-authority.json. Confirmed in recovery run log autosoc-20260313T215029Z-31020.
0 mismatches100% success rateledger-verified
What heartbeat validates
Heartbeat is the pipeline’s self-certification signal. It runs after each processing cycle and confirms: the ingest process reached the Wazuh API, triage policy loaded successfully, at least one case was processed to completion, and the reconciliation gate passed.
SUCCESS definition
SUCCESS means all four conditions cleared in the last confirmed run. It is the highest-confidence pipeline health signal and is the only state that permits proof artifacts to be published.
heartbeat.status = SUCCESS
heartbeat.gate = LIVE
heartbeat.blocker = NONE
What a non-SUCCESS state means
If heartbeat is DEGRADED or FAIL, the pipeline gate blocks publication. The March 24 authority snapshot was locked only after the pipeline returned to SUCCESS following the 03-13-2026 recovery event.
Provenance
Value: heartbeat: "SUCCESS" from data/truth/current-authority.json. Cross-referenced against recovery run log autosoc-20260313T215029Z-31020.