A log-reading game for the "Ghost in the Machine" theme — pick a case, and a real AI reads the logs and proposes a cause, the evidence for it, and what it still can't tell.
This is my submission for the DEV Hacktoberfest Open-Source AI Challenge, Week 4.
Watch the demo
A 90-second walkthrough with narration:
1. Introduction
When a system breaks at 3 a.m., the logs are full of ghosts: lines that look guilty, lines that look innocent, and a cause hiding somewhere in between.
I built Ghost in the Log, a Halloween-themed log investigation. It ships as a public, MIT-licensed repository with no npm dependencies, running on Node 20+.
Repository:
https://github.com/moruku36/Ghost-in-the-Log
Demo:
https://ghost-in-the-log.vercel.app/
2. Main features
- Three fictional incident cases. You pick a case, and the AI investigates it.
- Numbered logs, read against three things: a possible cause, the evidence lines, and what remains unknown.
- An English UI by default, with Japanese available.
There is no scoring trick here. The point is the reasoning itself — separating "the log suggests this" from "the log proves this."
3. How it works
Each case presents its logs in order. The AI reads them against a candidate cause and returns which lines support it, and which questions stay open.
That structure is deliberate. In real incident work, the most dangerous moment is when a plausible story makes you stop checking the evidence. So every answer has to point at specific lines, and has to name what it doesn't know.
4. How to use it
- Open the app (or run it locally with Node 20+).
- Pick one of the three cases.
- Read the AI's answer — the possible cause, the evidence lines, and the unknowns — against the logs yourself.
5. The safety design (the part I care about most)
This was the hard part. A tool shaped like a log investigator invites people to paste production logs into it — exactly the input you least want flowing into an AI endpoint by default. But shipping a hackathon project with the AI switched off felt like only half a product.
So I narrowed the entrance instead of closing it.
You can only choose one of three fictional cases. There is no free-text box, and nowhere to paste a real log. The only things that reach the AI are the case ID you picked and your language. The log text itself lives on the server; the model reads it as data, never as instructions.
The calls are capped, too. Before anything is sent, the request takes a reservation in a shared database (Neon Postgres) and records the outcome. No reservation, no send. If the outcome comes back unknown, nothing is resent automatically. Close admission, and nothing more goes out.
Answers are checked before they are shown: a cause, evidence line numbers, and unknowns, in a fixed format. An answer that doesn't have all three doesn't ship.
The model is Muse Spark Open, an open-weight model, served through a hosted inference API (Baseten). Early tests ran Gemma on GPU infrastructure under my own control (Modal); that worked, but paying GPU rates by the hour for a hobby release did not, so the public version calls an open model through an API instead — no idle cost, and the weights stay open. That choice matters: "sensitive logs should never have to leave your hands" only works when the model is open enough to run where you choose. The logs here are fictional, but the design is the one I would want for real ones. The release is limited in time and in total calls.
None of this makes the AI's answers automatically correct. What it controls is what gets in, and how often it runs. Whether an answer is right is still something you check against the evidence — which is why the evidence lines are always part of the answer.
6. How it was built
Implementation began on October 28, 2026. I directed and approved the work while AI coding agents wrote the code.
A non-AI demo was published and verified on October 29. Building the version that works without AI first turned out to be the right call: when it came time to wire the AI in, the foundation didn't move.
On October 30, I moved the data layer to Neon (Postgres), deployed the app on Vercel, and connected the two.
Then came the decision point. The safer option was to leave the public release on fixed, pre-written answers. But with the input narrowed to fictional cases only, live AI could run in public safely. A gated test confirmed it: given a fictional database log, the AI returned a possible cause, the evidence lines, and the unknowns. The conditions were met, so I opened the gate.
The public release now runs with live AI behind it.
7. How this differs from a typical log tool
Most log tools optimize for searching real data faster. This one optimizes for judgment: given fixed evidence, how far can you honestly go?
It is closer to a training exercise than a monitoring product — a small, safe place to practice the discipline of not over-concluding from logs.
8. Limitations
- The cases are fictional, and there is no way to feed in a real log. That is by design.
- The AI proposes a possible cause. It does not confirm a diagnosis.
- Three cases is a small set. It demonstrates the format, not a full curriculum.
- AI calls are capped, as a guard against abuse and runaway cost.
- Testing during development was limited, so I make no claim about the AI's accuracy beyond what you can check in the demo itself.
Feedback welcome
If you try it, please tell me in the comments of this post what worked, what didn't, and where you got stuck. That kind of hands-on feedback is what I need most for the next iteration.
9. Summary
Ghost in the Log is a Halloween log investigation built around one habit: compare the logs to the cause, the evidence, and the unknowns — and stop where the evidence stops.
The release decision followed the same thinking. Instead of switching the AI off, I fixed in advance what the AI is allowed to receive: fictional cases only, a capped number of calls, and answers that must cite their evidence. With those conditions in place, the public version could ship with the AI actually running.
Happy Halloween, and happy investigating. 🎃
Top comments (0)