Demos had drifted into a small, familiar ritual. Someone would spin up a live query against the AuthLokr Graph surface, someone would narrate what was happening, and everyone in the room would hold their breath when the network stuttered. The pressure was twofold: we needed demo narratives that survived flaky networks, and we needed to walk operators and partners through detection scenarios that felt grounded rather than improvised. Today the Thalamus Graph demo work shifted to fixture-driven scenarios, anchored by a new set of AuthLokr detection fixtures that give us a controlled, repeatable surface for those conversations.
Decision
We moved Thalamus Graph demos from ad-hoc live queries to fixture-driven scenarios. The reasoning is straightforward: a demo is a contract with the room, and contracts should not depend on whatever the upstream service felt like that morning. With fixture-driven scenarios, the same inputs produce the same outputs - the same graph state, the same detections, the same narrative beats - every time we run them. The story we tell in rehearsal is the story we tell in a partner meeting, and it is the same story the system would tell on its own when the data is real.
This is not a small change in posture. Live demos are performances: they require a stable environment, a calm operator, and a certain amount of luck. Fixture-driven demos are tools: they run the same way on a laptop in a coffee shop as they do in front of a customer. We chose the latter because our detection work is the part that needs to land cleanly, not the network plumbing.
Evidence
Two commits closed the loop.
92cd7d0adds AuthLokr Graph API detection fixtures (Lab709). These fixtures model realistic detection paths on the Graph surface - accounts, sessions, tokens, and the relationships between them - in a known, recorded shape. They give us the substance of a live detection narrative without depending on a live AuthLokr deployment being up, healthy, or returning the kind of data we want to talk about.cd4aaa3adds the Graph fixture-driven demo scenarios themselves, wiring the fixtures into a demo harness so the fixtures are not just static data but actually runnable end-to-end walkthroughs. This is the difference between having a transcript and having a play.
Together, the fixtures are the inputs, the demo path is the harness, and what an operator sees in rehearsal is what a partner sees in a meeting. Nothing in the middle is improvised.
Implementation
Fixture-driven demos improve reliability in the obvious way - they do not break when the upstream provider is unavailable, slow, or returning a different shape of data than expected. But the deeper gain is communication. When we walk a partner through an AuthLokr detection scenario, we are not explaining what might happen on a real account. We are showing what did happen, in a recorded shape, on a known graph state. The conversation moves away from "trust me, in production it would..." and toward "here is the detection path, here is why it fires, here is what the operator sees." That is a more honest, more useful conversation, and it is one reviewers can prepare for.
Graph data is especially well-suited to this pattern. A detection is rarely a single fact; it is a path through relationships - an account that authenticated from an unexpected place, used a session in a way that did not fit its history, and touched a token that has since appeared somewhere it should not. Walking that path on a live system means racing a clock. Walking it on a fixture means narrating at the speed the room can absorb.
Practically, this also lets the team rehearse in parallel. A reviewer can run the same scenario on their own time, in their own environment, and arrive at the meeting already aligned on what they are about to see. No one is waiting on a live connection. No one is guessing what the next query will return. If we want to focus the conversation on a specific detection - a particular traversal, a particular signal - we can highlight that fixture and stay there for as long as the room needs.
There is also a quiet gain for the fixtures themselves. Once a detection is captured as a fixture - with known inputs, known traversals, and known outcomes - it becomes a contract. If a future change to AuthLokr or to the Graph surface changes the detection behavior, the fixture is the place where that drift shows up first. We get a regression test as a side effect of having a good demo. That is the kind of leverage we want from internal work, and it is one of the reasons fixture-driven demos tend to outlive the meetings they were built for.
Next
We will extend the fixture library as new detection scenarios are validated, with a bias toward fixtures that are small enough to reason about and rich enough to support a real conversation. We are also tracking broader use of fixture-driven demos across other Thalamus surfaces, and looking at ways the same pattern can support internal reviews, partner briefings, and the kind of post-incident walkthroughs where the graph state is the story.