Forensiq demos used to be a function of the person running them. The MITM scenario was supported in the tool but not as a first-class demo scenario, which meant setting it up was a manual sequence that varied from run to run. The logs were plain text dumps that looked like log dumps. There was no way to point at a recorded demo and say "this is the one that ran last week." In late May we shipped three commits that made Thalamus demos reproducible from artifacts rather than dependent on the operator. The MITM scenario is now a flag, log output renders in RichLog panes for inspectability, and the demo captures (videos + stills) form a corpus that anyone can review, replay, and rerun. This post covers the framing decision, what was fragile in the prior model, what each commit does, and what reproducible demo quality looks like in practice.
Decision
The framing decision was that demo quality should be a property of the system, not a property of the operator. The same demo run by two different people should produce the same observable result, and a third person reviewing the demo a week later should see what the first two saw.
Three things had to be true for that to hold. The scenario had to be declarative, so the demo run is the same set of operations every time. The log output had to be inspectable, so a reviewer can read what the tool actually did without parsing plaintext. The artifacts had to be persisted, so a demo is a thing the team can refer back to rather than a thing that happened once.
The RichLog pane is the inspectability piece. The MITM flag is the declarative piece. The capture corpus is the persistence piece. Each commit handled one of those, and the merge is where the three become a coherent demo surface.
Evidence
The evidence for the prior fragility was in three places. The first was the demo run log: a Markdown checklist of setup steps that an operator walked through manually, with no automated validation that the steps were actually performed. The second was the live demo itself: the same demo could produce different observable results depending on what the operator emphasized or skipped. The third was the post-demo review: when someone asked "what did the demo actually do," the only answer was the operator's recollection, which drifted within a week.
The RichLog evidence was the plain text dumps. Logs that should have been inspection-friendly were strings, and reviewers had to scroll past timestamps and grep for the relevant lines. The MITM scenario evidence was subtler: the scenario was technically possible but required the operator to know which flags to set, in what order, and how to interpret the partial output. The first-time hit rate was low.
The captures evidence was simply that captures did not exist. There were screenshots in slide decks, but no continuous recordings, no canonical stills, and no way to point at "the demo from the last review" because there was no last review of a demo.
Implementation
8d79671 (2026-05-29) is the core of the change. The Forensiq demo now accepts a --scenario flag, and the mitm value runs the MITM scenario end to end: setup, the man-in-the-middle handshake, the intercepted payload, the recorded evidence. The flag is declarative — the same flag in the same environment produces the same demo run. The same commit also adds RichLog panes to the demo output, which render the log stream as structured panels with timing, severity, and source. The reviewer can collapse the panes that are not relevant, expand the ones that are, and follow the demo through the visual structure of the run rather than a wall of text.
723aee2 (2026-05-29) adds the capture corpus. The Forensiq demo now records a video of the run and a set of canonical stills at key moments. The stills are the high-signal frames: the moment the MITM handshake completes, the moment the payload is intercepted, the moment the evidence is recorded. The video is the continuous record. The corpus lives in the demo directory and is the canonical reference for the demo — anyone reviewing can pull up the stills, watch the video, and see what the demo actually did, in the order it did it.
57c0f8e is the merge of the scenario branch. The interesting thing about the merge is the order. The RichLog pane and the capture corpus landed in the scenario branch first, were exercised against the MITM scenario for a week, and then merged back. The week of exercise is what made the merge low-risk. The pieces were already proven against the hardest scenario we had, so the merge is the boring part of the change.
What reproducible demo quality looks like
The shape of a reproducible demo is a small number of properties that hold across runs and across reviewers.
The scenario is declarative. A reviewer who wants to see the MITM demo runs the same command and gets the same demo. A reviewer who wants to compare two runs diffs the captures, not the operator's recollection.
The output is inspectable. The RichLog panes let a reviewer see the demo's behavior at the same level of detail the operator saw it. The structured panels make the relevant lines findable without grep, and the timing makes it possible to ask "what was happening at second 14" and get an answer.
The artifacts persist. A demo is a thing in the repo, not a thing that happened once. The captures are the demo's record. A new reviewer three months from now can pull up the captures and see the demo the team saw in May.
The merge is uneventful. The hardest scenario we have was the integration test for the new pieces. The scenario branch was exercised against MITM for a week, the bugs were fixed, and the merge was a confirmation, not a bet.
For operators, the practical effect is that demo quality is now a property of the system. A senior operator can hand the demo to a junior operator and the demo runs the same. A reviewer can ask for a specific scenario and get a recording of it. A retrospective can refer to "the MITM demo from the May review" by hash.
Next
The next round of work covers three surfaces. First, additional scenarios are moving into the same framework — a credential-theft scenario and a data-exfil scenario are next on the list, and they will ship with the same declarative flag, RichLog panes, and capture corpus. Second, the captures are moving to a CI artifact path, so a demo can be regenerated from the same source and the captures can be diffed across runs to catch silent regressions. Third, the RichLog panes are getting a sharing mode, where a pane can be exported as a standalone image and dropped into a review comment or a ticket without a screen recording.
The commits covered here are 8d79671, 723aee2, and 57c0f8e, shipped around 2026-05-29.