[dd-Splunk]

Why

#45 slowed Eventgen from about 3,000 to about 300 events/min (the attack stream from about 1,500 to about 150). The slides and the demo script were written for the old volume. The qualitative story still holds, but the results are smaller samples, and the timing of the Demo 2 story changes. This PR makes the narrative match what the stack now produces.

What changes

All figures were measured on the running stack.

Default mode, 10 minutes after start: about 3,000 events, 150 purchases of which 43% fail, about $1,400 lost. Platforms land between 34 and 43% on 140 to 930 events each. Failed purchases spread over about 50 cities, about 1 each, so per-city rates mean nothing.

Threat mode: the validate tool lists the Pyongyang IPs after about 2 minutes. By about 5 minutes 175.45.* is about 90% of failed purchases and about 95% of lost revenue. If you ask the question too late, the 15-minute window is nearly all attack and the 503/404 baseline fades, so the narrative now says to ask 2 to 5 minutes after enabling.

Slides (s4r-demo-slides.md):

• the Step 2 expected line;
• the Buttercup Insights table ("roughly flat 34–43%", "about 1 failure per city", "hundreds of $");
• the Demo 2 expected line;
• the warm-stack line (at least 10 minutes);
• the NK troubleshooting row;
• speaker notes on sampling noise, and on how the attack range skews the international-vs-US and platform answers.

S4R-DEMO.md: a data-pace table, the Demo 2 timing and expected results, and the matching troubleshooting row.

make demo-prep: the warm-stack reminder now mentions the Eventgen warm-up.

s4r-demo-slides.html: rebuilt with LC_ALL=C, so only the intended changes differ.

Severity labels (second commit)

The Buttercup Insights slide showed "Critical" for IT Ops and Business Analytics, but the Power User template only allows low, med and high, and every agent run reported High. Both cells now say High, so the slide shows what a live run produces. The table still tells the story through DevOps ("High, escalate IT Ops") and the server-side root cause.

The Power User template also gets one line defining the three levels, so runs stay consistent: high means money or checkout is being lost now, med means degraded but not losing money, low means nothing to act on.

Testing

• I rendered the five edited slides (16, 24, 27, 30 and 32) to images and checked that none overflow.
• The figures come from queries on the running stack and from the Demo 1 and Demo 2 runs.
• pre-commit run --all-files, make test

🤖 Generated with Claude Code