The first problem was gathering the context.
System Sentinel grew out of troubleshooting instability on my own computer. I was moving between Windows utilities, event logs and one-off scripts, then carrying the results into a conversation with ChatGPT. Assembling a useful account of the problem was a task in itself.
I wanted a place to inspect those signals together and choose what to bring into the next conversation. The instability was the reason to start; making fragmented technical evidence easier to understand became the product problem.
Inspect, select, compose.
I built a dashboard with views for system events, hardware information, drivers and crash records. Its Context Composer lets me gather selected items, choose summary or full event detail, and copy the assembled text for analysis in an AI tool.
A selected event can also carry earlier events as context. That gives the conversation more than an isolated error message: it can include some of what happened before it. The composer keeps the choice of evidence in the user’s hands.
Connect the collection to the conversation.
The Next.js dashboard sits over a Python and FastAPI backend, with Windows collection through PowerShell and WMI. Event streaming and hardware-error processing feed diagnostic views; the composer brings selected evidence into a readable handoff.
The architecture connects two kinds of work: gathering technical records and making them useful to the person investigating. I can move from a system event to its underlying fields, then include the relevant context in the conversation.
Carry the investigation forward.
I designed the handoff around a practical question: what does the next conversation need to understand this machine and the problem I’m investigating? Selecting the evidence is part of that work, alongside collecting it.
The result is a workspace for preparing a diagnostic conversation. I can inspect the available records, choose a focused set of evidence, and carry the assembled text into the AI tool I want to use.