🔍 ACTIVE INCIDENTS: SERVER-SIDE FILTERED AT ALERT-STORM SCALE
?
A SOC analyst subscribed to a single global feed sees only the entities in a simulated 500-entity shadow alert population that are currently over the critical-risk threshold. Every other entity's raw telemetry never reaches this browser at all. This is Lightstreamer's COMMAND mode: the server maintains the authoritative list and pushes ADD, UPDATE, and DELETE row events as incident membership changes, so update volume scales with how many incidents are actually open, never with the size of the underlying alert-generating population.
| Incident ID | Segment | Alert Type | Source | Status |
|---|
No incidents currently open. The board updates the instant one crosses the critical-risk threshold, with nothing to poll for.
⚡ LIGHTSTREAMER DELIVERY PROOF
?
The server publishes client-environment and command-center telemetry at a constant rate regardless of any client's network condition. Lightstreamer's MERGE channel tracks the last value delivered to each connected screen and intelligently consolidates intermediate updates when bandwidth is constrained. Each analyst's screen always receives the most recent state, never a backlog. The conflation ratio shown here is the ratio of server events to client deliveries: 1 to 1 at full bandwidth, rising as network degrades. Critical-alert and network-forensics events on their DISTINCT channels bypass this conflation entirely and always deliver in full.
SOC Data to Lightstreamer
ApolloStreamAdapter publish rate
29
updates/sec (server)
Client environments (12)2 Hz ea.
SOC command center (2 feeds)1 Hz ea.
Compliance frameworks (3)1 Hz ea.
Active-incidents boardCOMMAND
Critical & forensics eventsDISTINCT
MERGE Conflation
?
Conflation ratio: server publish rate divided by client receive rate. At full bandwidth this is 1 to 1. As network degrades, Lightstreamer consolidates intermediate values so the screen always shows the latest state. Critical-alert and network-forensics events bypass conflation and always deliver in full, regardless of bandwidth. This is a separate readout from the Alert-Storm Conflation figure in the SOC Command Center panel below, which shows the aggregate threat count's own conflation at storm-scale generation volume.
1:1
server events per
client delivery
client delivery
Only the delta is sent.
Unchanged fields transmit 0 bytes.
Unchanged fields transmit 0 bytes.
Lightstreamer to This Screen
This browser's receive rate
29
updates/sec (client)
Client environments (12)2 Hz ea.
SOC command center (2 feeds)1 Hz ea.
Compliance frameworks (3)1 Hz ea.
Active-incidents boardALL · COMMAND
Critical & forensics eventsALL · DISTINCT
📡 NETWORK SIMULATOR
?
These buttons simulate the network conditions Apollo's own SOC dashboard sessions actually encounter: a wired analyst desk, a field analyst checking status from a phone, a client's own on-site security contact working through a degraded VPN tunnel during an active incident (capped illustratively at 256 Kbps per the PoC Requirements), and a full session drop with reconnect. Lightstreamer adapts automatically to each condition with no configuration required. StreamSense (transport selection) and Adaptive Throttling (per-client bandwidth degradation) are two distinct mechanisms shown together here for convenience, but reported separately in the PoC Requirements and this account's material.
Effective bandwidth
Unthrottled
Protocol (StreamSense)
WebSocket
Adaptive Throttling
Off
Critical & forensics events
Unaffected
SOC Analyst Desk: WebSocket delivers all SOC data at full publish rate. Every environment update and guaranteed event arrives the instant it is published.
⚠ DISTINCT CHANNELS: GUARANTEED DELIVERY
?
Critical alerts (Track 1, the roughly 2% of generated events promoted to critical) and network-forensics/NDR events (Track 2) each use their own Lightstreamer DISTINCT channel: zero consolidation, every event delivered exactly once, in sequence, regardless of network conditions. They are shown as two separate counters here on purpose: both are DISTINCT-mode, guaranteed delivery, but they represent conceptually different event streams and are never combined into one number. When a connection drops, events queue server-side and flush the instant it restores. Published and received counts must always converge for each channel independently: that is the DISTINCT guarantee.
Critical Alerts (Track 1)
Published
0
Received
0
Network Forensics (Track 2)
Published
0
Received
0
0
events queued (either channel) during last outage
🌐 SOC COMMAND CENTER
?
The aggregate threat count and alert-storm status update once per second from the same Lightstreamer server that powers the per-tenant dashboards. A SOC supervisor subscribes to these two feeds rather than every individual tenant environment to get an instant read on overall posture. During a connection drop, Lightstreamer holds the last known state server-side and delivers the current values instantly on reconnect. The Alert-Storm Conflation figures below are a separate, honest readout of the storm-scale generation rate versus the much lower MERGE-conflated rate actually delivered to this screen.
Alert-Storm Aggregate (APOLLO_SOC_GLOBAL)
Aggregate Threat Count
?
Open critical incidents across all tenant environments right now, out of the full 500-entity simulated shadow population. Updates every second via MERGE.
--
open incidents
Storm Status
?
NOMINAL under baseline generation volume, ALERT_STORM during a scripted burst toward the 10,000 events/sec illustrative peak rate from the PoC Requirements.
--
current mode
Generated (Storm-Scale)
?
The adapter's internal event-generation rate, conceptually representing the alert-storm scale named in the PoC Requirements. This is never pushed to the browser as individual events; it is exposed only as this one honest counter.
--
events/sec (server-internal)
Alert-Storm Conflation
?
Generated events per second divided by the one conflated MERGE update per second actually delivered to this screen for the aggregate threat count. This is the honest conflation ratio for Track 1's headline metric, separate from the network-mode-driven MERGE Conflation figure in the Delivery Proof panel above.
--
generated : delivered
Program Parameters (APOLLO_STORM_STATUS, PoC Requirements section 10)
Polling Baseline
?
The interval-poll baseline this PoC compares against: a typical client-portal architecture polling on a fixed interval regardless of whether alert volume changed.
--
seconds/poll
Degraded VPN Cap
?
The illustrative bandwidth cap used to represent a client's own on-site security contact working from a degraded connection during an active incident, per the PoC Requirements.
--
Kbps cap
Target P95 Latency
?
The PoC Requirements' target for end-to-end delivery latency at the 95th percentile, even at full alert-storm volume.
--
ms target
Reconnect Test Windows
?
The two reconnect-drop durations scripted in the PoC Requirements. This demo defaults its Session Drop & Reconnect scenario to the shorter window; append ?dropSec=60 to the dashboard URL to demo the longer one.
--
short / long (s)
⚠ GUARANTEED EVENT LOG: DISTINCT CHANNELS
?
Every critical alert (Track 1, tagged CRITICAL ALERT) and network-forensics event (Track 2, tagged FORENSICS) appears here in real time. They are shown chronologically together for readability, but their published/received counters above are tracked entirely separately: this log is a shared display for readability; the guaranteed-delivery counters above are what track each channel independently. Events shown as QUEUED during a connection drop will flip to DELIVERED on reconnect. The sequence number confirms no event was skipped.
Awaiting first guaranteed event...
⚙ LIGHTSTREAMER SESSION LOG
?
Live event stream from the Lightstreamer client library: connection status, subscription acknowledgements, and protocol transitions. WebSocket connected means lowest latency delivery. HTTP Streaming is the fallback for networks that block WebSocket. Smart Polling is the last resort for highly constrained environments. StreamSense selects the right protocol automatically with no configuration required.
Connecting...
📈 COMPLIANCE DRIFT (INFORMATIONAL)
?
Illustrative of a continuous compliance-posture-by-framework view, directly answering the "Compliance Theater" problem Skaarup has spoken about publicly: a point-in-time audit snapshot versus continuous drift monitoring. This track is explicitly informational: no public source confirms what already powers Apollo's own compliance reporting today, so treat this as a shape to validate with Apollo directly rather than a benchmark against it.
Track 3 is scoped as informational per the PoC requirements: lower confidence, no pass/fail gate, kept separate from Track 1's operational metrics.