ScopeGuard AI: Catch Scope Creep Before It Costs You

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

ScopeGuard AI is a local-first AI assistant for freelancers, independent developers, consultants, and small agencies who need to manage changing project requirements.

Here's what it does:

• Analyses client requests against the project's original agreed scope.
• Classifies requested changes as in_scope, potentially_out_of_scope, or needs_clarification.
• Provides supporting evidence by quoting relevant wording from the agreement.
• Explains its assessment and recommends the next step.
• Drafts professional client replies that users can review, edit, and copy.
• Stores projects and analysis history in a local SQLite database.

One important design principle is that an unmentioned feature isn't automatically an explicitly excluded feature.

For example, if an agreement says "Do not implement checkout," ScopeGuard AI should identify checkout as explicitly excluded. If price sorting isn't mentioned, the system should recognise that the agreement may be insufficient to determine whether it was included.

The goal isn't to replace a freelancer's judgement or provide legal advice. It's to make scope discussions more structured, evidence-based, and less uncomfortable.

Demo

dev3.mp4 - Google Drive

drive.google.com

Code

Gitcarbonath / ScopeGuard-AI

ScopeGuard AI

An evidence-led, local-first assistant for reviewing client requests against an agreed project scope.

ScopeGuard AI helps freelancers and small development teams review proposed changes before agreeing to them. It compares a client's request with the project's stated scope, separates the request into findings, quotes relevant scope evidence, and drafts a professional reply for the user to review.

ScopeGuard AI is a decision-support tool, not a legal adviser. AI assessments can be incomplete or incorrect. Always review the evidence and use your own judgement before making commitments to a client.

Features

• Three-way classification: in_scope, potentially_out_of_scope, and needs_clarification.
• Evidence-led findings: relevant quotations from the agreed scope and an explanation of what the wording does—and does not—establish.
• Explicit exclusion handling: distinguishes a feature expressly excluded by the agreement from one that is simply not mentioned.
• Separate findings for combined requests: evaluates individual requested features when the analysis returns…

View on GitHub

How I Built It

ScopeGuard AI combines an open-weight language model with a conventional application backend.

Technology stack

• Gemma 3 4B: The language model used for analysing client requests.
• Ollama: Runs the model locally and provides the inference interface.
• FastAPI: Handles API requests and backend analysis logic.
• Pydantic: Validates request and response data.
• SQLite: Stores project information and analysis history.
• React and Vite: Power the interactive frontend.

The workflow is straightforward:

1. A user saves the original agreed scope for a project.
2. The user enters a new client request.
3. The backend sends the relevant context to the model for analysis.
4. The application validates and refines the returned classification and supporting evidence.
5. The frontend presents the findings, recommended action, and editable reply.

The most challenging part wasn't simply getting an LLM to classify a request. It was making sure the explanation remained grounded in the agreement.

During testing, I encountered cases where the model was too cautious about routine visual changes, too confident when the original scope was vague, or selected a valid quotation that wasn't the most relevant evidence.

I worked on improving feature-level classification, evidence selection, explicit-exclusion handling, and the distinction between missing information and an actual prohibition.
These improvements don't eliminate model errors, but they make the reasoning easier to inspect. The user remains responsible for reviewing the result before making a decision.

Why Does Open Innovation Matter?

For this project, open innovation matters because of control over inference, data handling, and operating costs.

Client agreements and project requirements can contain commercially sensitive information. By designing ScopeGuard AI around local inference with Ollama, I can analyse project information on my own machine without requiring a hosted model API for every request, provided the model endpoint is configured locally.

Using an open-weight model also makes experimentation easier. I can try different supported models, compare their classifications, adjust the analysis prompts, and improve the evidence-handling logic without redesigning the entire application around a proprietary API.

There are trade-offs. Local inference requires sufficient hardware, and smaller models can still make mistakes. Downloading a model may require an internet connection, and the privacy benefits depend on the endpoint and deployment configuration.
For this use case, however, having control over where inference happens is a meaningful advantage.

Open-source application code also lets other developers inspect the implementation, reproduce issues, contribute improvements, and adapt the project to their own workflows.

Prize Categories

Best Use of Gemma

ScopeGuard AI uses Gemma 3 4B through Ollama as its core language model for analysing client requests against agreed project scopes.