The Caisey 'Endpoint Archaeology' Workflow: Investigating a Six-Month-Old Issue Using Durable Session History as Primary Source

You have a ticket that's been open for six months. Intermittent WiFi disconnects on a single laptop. Four different technicians have touched it. The ticket notes read like a game of telephone: "checked drivers," "updated drivers," "seems OK now," "reappeared after Windows Update." No one can pin down the root cause because each technician started from scratch, ran a few commands, and left a vague summary. The machine is still dropping connections twice a week.

This is where Caisey's durable session history becomes more than an audit trail—it becomes an archaeological tool. Because every command, every output, every diagnostic step is stored in a full-text-searchable SQLite database inside Cloudflare Durable Objects, you can treat prior sessions as primary source evidence. No more relying on what a technician remembered to write down. You search the actual diagnostic artifacts.

The Ticket: Six Months of Intermittent WiFi Disconnects

The scenario is painfully common. A Windows laptop at a client site loses WiFi connectivity for 30–60 seconds, several times a week. The user reboots, it comes back, but the pattern repeats. Over six months, the ticket has been reassigned to four different technicians. Each one spent 15–30 minutes running diagnostics, applied a band-aid, and moved on. The ticket notes are a graveyard of half-truths: "Ran netsh wlan show all, drivers looked fine," "Updated driver to latest from OEM site," "Seems stable now—closing." But the issue always returns.

As the internal sysadmin now assigned to close this once and for all, you need to understand what actually happened on that machine. You could call each previous technician and ask what they saw, but two have left the company and the third doesn't remember. You could dig through RMM script history, but most RMMs purge logs after 90 days and don't offer free-text search across output. You're stuck.

The Dead End of Ticket Notes

Ticket notes are the default source of truth in most MSPs and internal IT shops. They're also notoriously unreliable. A technician might write "checked drivers" without recording the driver version. They might note "ran netsh" but not include the output. They might close a ticket because the issue seemed resolved at the moment, even though the underlying condition remained.

In this case, the notes tell you nothing useful. You don't know which driver version was present during any of the prior sessions. You don't know whether the same diagnostic commands were run each time, or if each technician took a different approach. You don't know if the issue correlates with a specific Windows update or a change in network profile.

Without a reliable record of what was actually done and seen, you're forced to re-diagnose from scratch. That's time you don't have, and it's exactly the kind of waste that Caisey's session history is designed to eliminate.

Caisey as the Archaeological Tool: Full-Text Search Across Sessions

Caisey stores every session as a durable record in a SQLite database, backed by Cloudflare Durable Objects. Each session includes the full transcript: every command sent, every output received, every approval prompt, every note added by the technician. Crucially, the entire transcript is indexed for full-text search.

Open Caisey's console and navigate to the machine card for that laptop. In the search bar, type wlan or 802.11 or WiFi. Caisey returns every session where any of those terms appear in the transcript. The search is sub-second because it runs against the Durable Object's SQLite index via Cloudflare Workers.

You find three prior sessions that actually ran WiFi-related commands. Session 1 (four months ago): technician ran netsh wlan show all and driverquery—the output shows driver version 22.40.0.7. Session 2 (two months ago): another technician ran netsh wlan show drivers—driver version 22.50.1.1. Session 3 (three weeks ago): a third technician ran Get-NetAdapter -Name "Wi-Fi" | fl *—driver version is back to 22.40.0.7.

You now have a timeline of driver versions, pulled directly from the actual command outputs, not from someone's memory.

The Discovery: Driver Version Cycling

The pattern is clear. The driver version cycles between 22.40.0.7 and 22.50.1.1. Session 1: 22.40.0.7. Session 2: 22.50.1.1. Session 3: back to 22.40.0.7. What could cause that? A quick check of the Windows Update history (also accessible via Caisey's command interface) reveals that each time a cumulative update was installed, Windows Update replaced the OEM driver with a generic Microsoft driver. The OEM driver (22.50.1.1) is the stable one; the generic driver (22.40.0.7) causes the intermittent disconnects.

The technicians who touched the machine never noticed this pattern because they only saw a single snapshot. The ticket notes didn't record driver versions. But Caisey's full-text search across multiple sessions revealed the cycling.

Root Cause and Fix

The root cause is a driver replacement policy conflict. Windows Update is overwriting the OEM WiFi driver with a generic version that doesn't handle the hardware's power management correctly. The fix is straightforward: create a driver exclusion policy using Group Policy or a registry key that prevents Windows Update from replacing the OEM driver.

You apply the exclusion, verify the driver stays at 22.50.1.1 after the next update cycle, and close the ticket with a detailed summary that includes links to the three Caisey sessions as evidence. If the issue ever resurfaces, you—or any future technician—can search again and see the full diagnostic history.

Why This Matters: Transcripts as Primary Source

This workflow is fundamentally different from relying on ticket notes or RMM script history. RMMs typically store script execution logs with limited retention (often 90 days) and no free-text search across output. If you want to know what a previous technician saw, you have to read their notes—if they wrote any.

Caisey's session history is a primary source. It's the raw diagnostic data, preserved in a searchable format, with no interpretation layer. You're not reading what someone thought was important; you're reading exactly what the machine returned. That makes it possible to do endpoint archaeology—to reconstruct the history of a machine's behavior across multiple interactions, even when those interactions were performed by different people with different approaches.

Conclusion

Intermittent issues are the hardest to diagnose because they require pattern recognition across time. Caisey's durable session history, backed by SQLite and Cloudflare Workers, gives you the ability to search across every diagnostic session for a given machine. You can find the commands that were run, the outputs that were returned, and the context that was captured—all without relying on fallible human memory or sparse ticket notes.

The next time you inherit a chronic issue, don't start from zero. Start with a search.