Group Project Referee: A local-AI assistant for understanding the real state of collaborative projects

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Group Project Referee is a local-AI project coordination assistant built for my hackathon teammates.

Group projects have a surprisingly common problem: everyone gives updates, but nobody has a reliable picture of what is actually happening.

One person says an API is finished. Someone else says they still cannot access it. Another person is waiting for a database migration. A blocker gets fixed, but the old blocker continues to make the project look unhealthy.

I built Group Project Referee to act as a neutral referee for these situations.

Team members simply submit updates in plain language, such as:
"I am working on the authentication tests. I need Priya's database migration before I can run the tests."

The referee extracts useful project information from those updates:

• Completed work
• Work currently in progress
• Blocked work
• Dependencies
• Risks
• Potential conflicts
• Resolved issues
• Suggested next actions

The important part is that the system keeps an evidence trail. AI conclusions can be traced back to the actual team updates that produced them.

It doesn't try to decide who is lying or who is right. It identifies statements that may need clarification and lets the team investigate them.

The result is a shared project dashboard that answers:
"What is actually happening in our project right now?"

Demo

https://drive.google.com/file/d/1UFVnYGsj6oXr8sYMaWgfnMKzoPrJS7zS/view?usp=sharing

Code

Gitcarbonath / group-project-referee

Group Project Referee

A local-AI assistant for understanding the real state of collaborative projects.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.

Repository: https://github.com/Gitcarbonath/group-project-referee

Why I built it

Group projects are difficult to coordinate when updates arrive as informal messages. One teammate may finish an API while another still cannot access it; a blocker may be resolved without everyone noticing. Group Project Referee was built to help teammates see progress, dependencies, risks, and unresolved work without assigning blame.

What it does

Teammates submit natural-language updates, such as:

I am working on the authentication tests. I need the database migration before I can run them.

The application stores the updates and uses Gemma 3 running locally through Ollama to interpret project events. A project dashboard displays:

• Completed, in-progress, and blocked work
• Risks and possible conflicts
• Dependencies and suggested next actions
• A chronological update timeline
• Evidence linking findings to…

View on GitHub

How I Built It

The core of the project is Google's Gemma 3, running locally through Ollama.

Instead of sending team updates to a hosted AI API, the application sends them to a local Gemma model for structured extraction.

                Team Member
                     │
                     │ Natural-language update
                     ▼
              React Dashboard
                     │
                     ▼
                FastAPI
                /       \
               /         \
              ▼           ▼
         SQLite        Ollama
                          │
                          ▼
                       Gemma 3
                          │
                          ▼
                 Structured events
                          │
                          ▼
                Project State Engine
                          │
                          ▼
                Referee Dashboard

Gemma is responsible for understanding the natural-language updates and extracting events such as:

• completed work
• started work
• blockers
• dependencies
• risks
• conflicts
• resolutions The backend then uses deterministic project-state logic to distinguish historical events from the current project state. For example, if someone originally says: "I can't access the login API."

and later says:
"The login API access issue is fixed."

the original blocker remains visible in the project timeline, but it should no longer be counted as an active blocker. This separation between history and current state became one of the most important design decisions in the project.

The dashboard also supports multiple devices connecting to the same local FastAPI server, allowing team members on the same network to see updates from one another.

Why Does Open Innovation Matter?

For this project, using an open-weight model locally wasn't just a way to satisfy the challenge requirement. It directly changes what the application can be.

A group-project referee deals with potentially sensitive information:

• unfinished work
• internal project problems
• disagreements between teammates
• technical blockers
• project architecture
• development progress

Sending all of that to a closed third-party AI API would introduce an external dependency and require trusting another service with the team's project data.

With Gemma running locally, the team can keep its updates on its own machine.

It also gives us much more control over the system. We can experiment with prompts, model versions, extraction formats and deterministic logic without redesigning the application around a proprietary API.

Most importantly, the AI becomes a component we can run, inspect and build around rather than a remote service that the project depends on.

That is what open innovation made possible here: a private, local AI referee that can become part of the project's infrastructure itself.

Prize Categories

I am entering Best Use of Gemma.

Gemma 3 is the central AI component of Group Project Referee. It runs locally through Ollama and is responsible for converting unstructured team updates into structured project events that drive the referee's analysis.