Pitch v3: film + demo + proof + scale (run of show)

This page replaces the timing, slide list and demo click path in pitch. The numbers sheet, the limits and the Q&A in that page stay valid. Prompts for the next build steps are in pitch prompts.

v4 (26 Sep): airframe-pitch-film/pitch-v4/ changes this run of show: heartbeat first (no cold open), a new "answer" scene (what the engineer sees for T-03) before "how", the pivot after "how", a new "robust by design" scene after "trust", demo 1:15, close "Keep every gear turning.". Times and demo path: airframe-pitch-film/pitch-v4/SPEAKER-NOTES.md.

Built: the full presentation is in airframe-pitch-full/ (pitch-full.html, speaker notes, backup PDF). The original film stays unchanged in airframe-pitch-film/.

Inputs: the pitch film (airframe-pitch-film/pitch-film-v2.html on main, by Hannes), the pitch plan (05), the jury review (internal/review/JURY-REVIEW.md) and the detector state on branch fix/jury-review (11 incidents).

1. What the film does well, and what is missing

The film tells the problem very well: one torque tool (T-03), one missing message, a line that stops, EUR 885,000 of output stuck, "nobody was alerted". It uses real capture data and tags every number as DATA or SCENARIO.

What the film does not do, and what the jury scores:

Problems in the film to fix before the pitch:

1. Length. Scenes 1–10 run about 2:40 with transitions. That leaves 2:20 for solution, demo, proof and scale. Too little. Target for the film: 1:10 at the start + 0:30 at the end.
2. Name. The film says "Airframe" (12 times). The dashboard, the docs and the domain say "Gearbox". "Airframe" is Tesla's challenge name. Using it as our product name confuses the jury. Decision needed; recommendation: Gearbox (change 12 strings in the film).
3. T-03 does not exist in the dashboard. The dashboard shows b8:27:eb:00:00:03. The demo must open "Torque tool T-03" with the same name, the same AP (AP 0f) and the same times (missed check-in 12:35:14, sign-off 12:36:32).
4. "18 minutes → 60 seconds" is a scenario (stream mode with alerts). Today Gearbox analyses captures in batch. Keep the SCENARIO tag and say it once: "in stream mode, see scale".
5. Visual break. Film = black and cinematic, dashboard = light. The cut into the demo must not feel like a different product: a dark pitch mode for the dashboard (see section 6).

2. Core message and the one idea the jury must keep

"Tool offline" is a symptom, not a cause. Gearbox finds the cause in 1.1 million header-only frames, proves it with the frames, and sends it to the one person who can fix it.

The slide that carries this idea ("One symptom. Four causes."):

Background incidents (show in the "what we found" list, one line each): controller stalls (beacons late on all 8 channels at once), sensor clocks off by up to 1.2 s and 25 ppm (planted), TESLA-TOOLS uses one shared password without 802.11w, 15 devices sign off in the first seconds, join ramp (one device every 2.0 s).

3. How technical?

The jury is Tesla's wireless engineers plus business people. Rule: two layers on every screen.

• Spoken + large text: plain words. "The login server does not answer." "The controller kicks devices."
• Small mono text / tags: the 802.11 proof the engineers can check. EAP-Request/Identity, reason 3, seq +1 vs AP probe-resp counter, sensor03 #184233.

One deep moment of about 20 s in the demo, not more: the kick campaign. "Is it an attacker? No. The sequence number continues the AP's own counter and the signal equals its beacons. The AP sends it, so 802.11w would not help. Check your controller." This is the moment where the engineers see that we read the frames, not just count them.

What we do not do: explain 802.11 to them, show code, show more than one architecture diagram.

4. Run of show (5:00)

Buffer: the demo is the only part that can overrun. If we are behind at 3:00, skip the replay step.

5. Presentation style for the new parts

The new parts are scenes in the same film engine (SCENES array in the film HTML), not a separate slide deck. One file, one clicker, one visual world. Between film and demo we switch windows (Alt+Tab) on a "LIVE" hand-off scene.

Rules (from airframe-pitch-film/docs/PITCH-VISUAL-BRIEF.md, keep them):

• Black stage 1920×1080, Inter + JetBrains Mono, three text sizes (XL one per scene, M one line, S 2–3 lines), honesty tag on every scene with numbers.
• One hero per scene. The hero is always a visual, never a bullet list.
• Signal colours only with meaning: red = loss / line risk (TESLA-TOOLS), amber = warning (TESLA-CORP), green = recovered. Add violet only for security (same meaning as in the dashboard). Cool blue tint for neutral network.
• Continuity: the heartbeat line of T-03 is the visual thread. In the pivot it splits into four lines, in "how it works" it becomes one device story, in "trust" it becomes the evidence frame, in "scale" it becomes one of thousands again.
• Motion slow and confident. No bullet points flying in.

5.1 Changes to the existing film scenes

5.2 New scenes

Numbers on scenes must come from the live dashboard (/api/datasets/ff1d9f54dee9) on the morning of 26 Sep, after the jury-review branch is deployed. Do not copy them from this page blindly.

6. Dashboard: goal and changes

Goal. A wireless / IT engineer opens Gearbox and sees in 10 seconds: what is broken, where (network, AP, channel, sensor), since when, how many devices, who must act, and why we are sure. And the jury sees that Gearbox detects and separates every fault class, not only the four headline incidents.

6.1 Must have (before the pitch)

1. Deploy fix/jury-review. The live site still shows 10 findings with the old texts (deauth = attacker, "network not on the air"). Push = deploy, then check the numbers.
2. Cause board at the top (replaces or merges "Most important warnings"): one card per root cause, ordered by line risk. Each card: plain cause ("Login server does not answer"), network colour, scope (devices / APs / channels), since when, who acts, one-line proof in mono.
3. Connection ladder ("where devices stop"): per network, a funnel of the join sequence scan → authenticate → associate → EAP identity → EAP method → 4-way handshake → data / heartbeat → still online. Each drop is coloured by its cause. This is the visual proof that Gearbox separates causes: CORP devices stop at EAP (login server), 12 devices stop before authentication (home AP off), T-03 drops after data (switched off), kicked devices fall back and repeat. Counts come from the pipeline result; add a small API field if they are not there.
4. "What we checked" matrix: every fault class Gearbox tests (login server, home AP off, controller kicks, device gone, controller stall, handshake break, association rejected, roaming ping-pong, AP silent, sensor blind spot, congestion, non-Wi-Fi interference, deauth flood / spoofing, evil twin, short-lived network, sensor clock drift, security config) with state found (links to the incident) or checked, clean. This answers "can you detect everything?" and "false positives?" in one glance.
5. Human names that match the film. Tools as T-01 … T-27 (Raspberry Pi index), APs as AP 0f, networks by SSID. MAC and BSSID stay visible as small mono text. The demo opens "Torque tool T-03".
6. Finding detail in a fixed order: cause in one sentence → where (AP, channel, sensor) → since when → who acts and next step → why we are sure (3 bullets) → what we ruled out → evidence frames (sensor + frame number) with Copy Wireshark filter. Texts follow the jury corrections (controller, not attacker; home-AP binding, not "network missing").
7. Pitch mode: dark theme with the film palette, larger type, no upload / chat / nav clutter, opened with ?pitch=1. The cut from the film into the demo then feels like one product.

6.2 Should have

• Deep link /?pitch=1&finding=<id> so the demo opens T-03 directly.
• Replay starts at 12:35 (one minute before T-03 signs off) in pitch mode.
• Timeline with one swim lane per cause over the 30 minutes (reuse incident-timeline.tsx).
• Remove or fix any tile that claims cross-sensor de-duplication (one sensor per channel here).

6.3 Not for the pitch

• New detectors, ML, the LLM summary in the main demo path (Q&A only), /engineering and /architecture (Q&A only).

7. Demo click path (1:30)

1. Dashboard, pitch mode. Status sentence: "2 problems can stop the line · 4 tools affected". Cause board with the four causes. "Eleven incidents instead of 1.1 million frames." (15 s)
2. Torque tool T-03 (from the film). Ladder: heartbeat, missed check-in 12:35:14, sign-off reason 3 at 12:36:32, silence. Who acts: line lead, swap the tool. (20 s)
3. Login server. Ladder: 63 CORP devices reach EAP identity, none gets further, on 26 APs. Open one evidence frame, Copy Wireshark filter. (25 s)
4. Kick campaign, the deep moment: sequence number and signal prove the AP sends it → controller job, not an attacker, 802.11w would not help. (20 s)
5. What we checked: all fault classes, found vs. clean. (10 s)
6. Optional if on time: Play at 60×, the hall stops when the tools problem starts. (10 s)

Backup: screen recording of exactly this path (1080p) on the laptop and a USB stick; screenshots of each step.

8. Consistency checklist (film ↔ scenes ↔ dashboard)

• One product name everywhere (film, scenes, dashboard, report, domain title)
• T-03 = b8:27:eb:00:00:03, AP 0f, TESLA-TOOLS, missed 12:35:14, sign-off 12:36:32 in film and dashboard
• 1,118,853 frames · 8 sensors · 29 AP radios · 87 connected · 27 tools · 11 incidents: same in film, scenes, dashboard
• Line risk: same count of line-risk problems and tools affected in the pivot scene and the status sentence
• Kick campaign told as controller, never as attacker, in scene, dashboard and Q&A
• Missing APs told as "home AP off, no fallback", never as "network not on the air"
• RADIUS: "not one login in the whole capture", never "stopped at 12:24"
• Every scene with numbers has a DATA / SCENARIO / MEASURED tag
• READ_ONLY=true on the pitch day, no re-analysis in the last hour