DEADBYTE — An AI Archaeologist for Abandoned Software

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

What happens when software is abandoned?

Repositories become inactive. Dependencies disappear. APIs become obsolete. Documentation gets outdated. Eventually, the people who understood the system move on, leaving behind fragments of what once worked.

I built DEADBYTE, a local-first AI archaeologist that investigates abandoned and legacy software projects.

The idea behind the project was to interpret Ghost in the Machine quite literally: software may be dead, but its source code, comments, dependencies, error logs, and configuration files still contain traces of its past.

DEADBYTE examines those traces and attempts to reconstruct the story.

It can:

• Scan a project without executing its code.
• Identify potential signs of legacy technology, deprecated APIs, and missing dependencies.
• Extract evidence with traceable file and line references.
• Use a local AI model to interpret the collected evidence.
• Generate a Markdown investigation report and a structured JSON case file.
• Produce a fictional, atmospheric final transmission based on the investigation.

The goal isn't to pretend that AI can know why a project was abandoned. Instead, DEADBYTE tries to distinguish what the evidence actually shows from what might merely be a hypothesis.

Think of it as digital archaeology, with a little horror mixed in.

Demo

Watch the demo video to see DEADBYTE investigate a sample legacy project, collect evidence, generate AI-assisted findings, and produce a structured investigation report.

dev5.mp4 - Google Drive

drive.google.com

Code

The complete source code is available on GitHub:

Gitcarbonath / DEADBYTE

DEADBYTE

Every program leaves behind a ghost.

DEADBYTE is a local-first AI archaeologist for abandoned and legacy software. It scans a project without executing it, collects traceable evidence, asks a local Ollama model to interpret the evidence, and writes a Markdown case report.

Requirements

• Python 3.11+
• Ollama installed locally (optional when using --no-ai)
• A model installed in Ollama, such as qwen3.5:9b if available in your catalog

Install (Windows PowerShell)

ollama pull qwen3.5:9b
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"
deadbyte doctor
deadbyte investigate .\examples\haunted_project --model qwen3.5:9b

Without AI:

deadbyte investigate .\examples\haunted_project --no-ai

Reports are saved under deadbyte_cases/<case-id>/.

Safety

DEADBYTE does not execute project code, build scripts, or installers. It skips common generated directories, binary files, symlinks, and obvious secret files. AI mode sends selected evidence to the configured Ollama endpoint (…

View on GitHub

How I Built It

I wanted to build something around open-weight AI that would do more than simply send prompts to a hosted API.

The core stack:

• Python — The main implementation language.
• Typer — Command-line interface.
• Rich — Terminal output and presentation.
• Pydantic — Structured data models.
• Ollama — Local model inference.
• Qwen 3.5 9B — The local model used for interpreting investigation evidence.
• Pytest — Regression testing.

The architecture follows a fairly straightforward pipeline:

1. Scanning: Discover eligible project files while skipping common generated directories, binaries, and symlinks.
2. Extraction: Identify potential evidence, such as deprecated APIs, legacy technologies, dependency issues, and suspicious error patterns.
3. Analysis: Package bounded evidence and send it to the local Ollama model for interpretation.
4. Reporting: Generate a Markdown report and JSON case file.
5. Final transmission: Produce an atmospheric conclusion, clearly identified as fictional.

One important design decision was to keep evidence collection separate from AI interpretation.

The scanner and extractors determine where evidence comes from. The model interprets that evidence rather than inventing file locations.

Another important decision was not to execute the investigated project's code, build scripts, or installers. DEADBYTE is an investigative tool, not a sandbox.

Why Does Open Innovation Matter?

Open innovation made this project possible in a way that aligns with its purpose.

I could build around an open-weight model, run inference locally through Ollama, and experiment with the analysis pipeline without depending on a proprietary hosted AI API.

This gives the project several advantages:

• Local inference without requiring a hosted model API.
• More control over the model and inference environment.
• Freedom to experiment with different models.
• A reproducible architecture that other developers can inspect and extend.
• No mandatory per-request dependency on a closed AI service.

It also means developers can investigate software while keeping the inference workflow on their own machine, provided they configure Ollama locally.

For a project about preserving the history of abandoned software, building on open technologies felt particularly appropriate.

The Spirit of It

The most interesting part of DEADBYTE isn't simply finding deprecated dependencies or outdated APIs.

It's the idea that a repository can tell a story even when nobody is maintaining it anymore.

Imagine opening an old project and finding:

• A comment explaining a workaround nobody remembers.
• A dependency that no longer exists.
• An error log from a crash that was never fixed.
• An API that was once essential but has since disappeared.

These are fragments of a system's history.

DEADBYTE attempts to bring those fragments together into an investigation.

And when it finishes, it leaves you with a final transmission.

Not a real message from a ghost, of course.

Just a reminder that abandoned software isn't necessarily empty software.

Somewhere in the code, something still remembers.