It's a little past 6 AM. The sky is slowly turning that shade of blue you only see after an all-nighter, and I've just spent the last twenty minutes fighting with port 11434 on my MacBook.
If you've ever typed kill -9 into your terminal at 5 in the morning, only to see the exact same process come back a few seconds later with a completely new PID, you probably know what I'm talking about.
Twelve hours earlier, we had nothing more than an idea, a shared frustration, and an empty project directory. By sunrise, we had built IssueFlowP6 — a local-first, AI-powered decision intelligence tool designed to solve a problem almost every software development team has faced at some point.
And we did it without depending on cloud APIs or blindly trusting whatever an LLM decided to tell us.
The Problem: Important Decisions Get Lost
Think about how a typical development team works.
There's a long discussion on Discord or Slack about which database to use, how an API should behave, or why a particular architectural approach might not work. Someone suggests an idea, another person disagrees, and eventually the team reaches a decision.
Sounds simple, right?
Now imagine trying to find that exact decision three days later.
The conversation is buried under hundreds of messages. Nobody remembers who suggested what, why an alternative was rejected, or where the final decision was made.
We realised that this wasn't just a documentation problem. It was a knowledge recovery problem.
The obvious solution would be to feed the entire conversation into an LLM and ask it to summarise everything. But there's a catch: LLMs can confidently paraphrase, change the meaning of statements, or even invent details that were never part of the original discussion.
For engineering decisions, that can become a serious problem.
We wanted something different. Instead of simply trusting the AI, we wanted to make it prove what it extracted.
That became the core idea behind IssueFlowP6.
Building the Pipeline at 1 AM
One of our biggest priorities was keeping the entire system local. We didn't want to send private engineering discussions to external APIs or depend on cloud services.
So, we built our stack around Ollama and Qwen 2.5 (7B), running locally on Apple Silicon.
We divided the project into three main components:
1. The Reader — extract.py
This is where everything begins.
The module takes raw discussion logs, such as api_discussion.txt and database_discussion.txt, and passes them to the locally running Qwen model.
Its job is to identify important engineering decisions, their supporting context, and alternatives that were rejected. The extracted information is then returned in a structured format.
2. The Fact-Checker — verify.py
This is probably the most important part of our architecture.
Rather than accepting everything generated by the LLM, this module checks whether the supporting quotes actually exist word-for-word in the original discussion.
If a quote cannot be found in the source, it gets rejected.
The idea is simple: an AI-generated decision shouldn't be treated as reliable evidence unless its supporting statement can be traced back to the original conversation.
3. The Command Center — cli.py
Finally, we needed a simple way to bring everything together.
The CLI allows developers to run the extraction and verification pipeline from the terminal and retrieve recovered decisions from structured JSON files.
No complicated interface was needed to demonstrate the core functionality. Just a command and a clear output.
Of course, getting all three components working together wasn't exactly smooth.
Early in the night, we ran into a series of 404 errors because Ollama couldn't find the model we expected to be available locally.
After pulling qwen2.5:7b and getting the local setup running properly, we finally executed:
python3 -m decisionlab.cli extract
And waited to see what would happen.
The 3 AM Plot Twist: "Verified & Kept: 0"
This was easily one of the most interesting moments of the entire hackathon.
The terminal finished processing and displayed:
Verified & Kept: 0
For a moment, we genuinely thought something was broken.
The model was reading the conversations. It was identifying the right decisions. The extraction seemed to be working.
So why was absolutely nothing making it through verification?
After going through the logs, we figured it out.
Qwen 2.5 was extracting the correct information, but it was doing what LLMs often do: making small improvements to the wording. Sometimes it changed a phrase, corrected the grammar, or paraphrased a sentence slightly.
To a human reader, the meaning was practically identical.
But our verify.py module wasn't interested in whether the sentence sounded similar. It was checking for an exact match against the original source.
Even a tiny difference was enough to reject the quote.
And then it clicked.
Our verification system was doing exactly what we had designed it to do.
We hadn't built a system that simply accepted whatever the AI generated. We had built one that challenged its output.
That zero-result output wasn't necessarily proof of a broken pipeline. It exposed a limitation in the model's extraction behaviour and showed us why strict verification mattered in the first place.
It also gave us a much better story to explain during the final presentation.
The 5 AM Boss Battle: The Process That Wouldn't Die
With the main implementation tested and committed to main, I thought the hardest part of the night was finally over.
I was wrong.
Before the presentations, I wanted to shut down the local Ollama server and free up some RAM on my MacBook.
I started with:
lsof -i :11434
Found the process, grabbed PID 82248, and killed it.
Checked the port again.
Ollama was back.
This time, with PID 82673.
I tried unloading the macOS launchctl plist and killing the process again. Somehow, it returned with PID 83120.
At this point, it genuinely felt like I was fighting a digital hydra. Every time I killed one process, another appeared.
Eventually, I used:
pkill -9 -f Ollama
And finally, the port was quiet.
For the first time in a while, my terminal was actually listening to me.
The Final Challenge: Getting the Presentation Ready
Once the technical work was mostly done, we still had one important task left: preparing the presentation for the judges.
We wanted the slides to look as good as the project itself, so we experimented with several visual directions, including Neumorphism, Glassmorphism, Claymorphism, and Neo-Brutalism.
We explored different layouts and design styles before settling on a bold, high-contrast direction that made the architecture, terminal workflow, and core features easy to understand.
There were a few frustrating moments with our Canva integration, including repeated PERMISSION_DENIED errors when trying to generate designs.
With the deadline getting closer, we had to adapt, work around the interruptions, and focus on getting the final deck ready.
It was another reminder that hackathons aren't just about writing code. Sometimes, you have to figure out how to keep moving when the tools you depend on stop cooperating.
What I'll Remember About This Hackathon
Looking back, the most memorable part of this experience wasn't a particular feature or even the final working demo.
It was everything that happened in between.
It was figuring out why a model kept paraphrasing quotes, understanding why our verification system rejected them, watching the three Python modules finally work together, and spending an unreasonable amount of time trying to stop a background process.
Somewhere between debugging, testing, redesigning slides, and fighting sleep, IssueFlowP6 went from an idea to a working project.
We learned that building with AI isn't just about getting a model to generate useful answers. It's also about understanding where it can go wrong and designing systems that account for those limitations.
Our goal was never to make AI sound smarter. It was to make the information it provides more trustworthy.
The port is finally quiet. The presentation is ready. The code is committed.
IssueFlowP6 is ready for the judges.
Now, hopefully, it's time to get some sleep.
Built with Team RAGA | Hacktoberfest 2026 | Newton School of Technology, Rishihood University
This is a submission for the MLH x DEV Writing Challenge
Top comments (0)