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

What I Built

A machine breaks down at eight in the morning.

There is another machine in the workshop. The inspection bench is working. People are available.

So why might the customer’s order still arrive late?

Because those facts, individually, don’t tell you whether recovery is possible. The replacement machine might already be booked. The available worker might not be qualified to use it. Inspection might be waiting for parts that haven’t been made yet.

That connected problem is what I wanted to explore with FactoryGraph, a factory operations copilot for small manufacturers.

An operator configures the factory, reports a breakdown, and gets a traceable view of the consequences. FactoryGraph compares feasible recovery options, estimates their operational costs, and shows the assignments that would change.

The operator reviews and approves the response. After the repair, its actual outcome becomes evidence for future planning.

FalkorDB connects the factory. Deterministic rules calculate the options. Local Gemma helps explain them. The operator approves the changes.

Caption: Waiting and recovery are compared using the same configured factory assumptions. The proposed assignments remain unchanged until approval.

Who would pay for this?

My starting audience would be owners and production supervisors at small machining or fabrication workshops: businesses with a few connected production stages, qualified operators, and customer deadlines to protect.

The service I would offer is factory setup plus ongoing planning support.

The initial work would involve mapping their machines, dependencies, shifts and cost assumptions. The recurring value would come from helping them evaluate disruptions and retain useful repair and supplier history.

A pricing experiment I would test is:

These are hypotheses, not validated prices. I haven’t established willingness to pay, and there is no billing integration in the current application.

Before adding checkout, I would want a workshop to use the product and answer a more important question: does this make their next recovery decision easier?

Demo

The recording starts with the guided walkthrough, then moves into the full operational workspace.

The example is deliberately small enough to follow:

• CNC One stops at 8 AM.
• The estimated repair takes two hours.
• Cutting affects inspection.
• The customer needs the brackets by 2 PM.
• Waiting projects a 3 PM finish.
• The demonstrated recovery projects completion by 2 PM.

In this synthetic configuration, the waiting baseline is ₹4,000, compared with ₹3,750 for the selected recovery: ₹250 in estimated cost avoided.

That is a result from configured demonstration rates, not measured savings from a real factory. The customer order’s ₹40,000 value is also separate from the estimated operational loss.

Why I added a Guide

While preparing the demo, I realised I needed help explaining my own interface.

The application had the pieces, but moving between screens didn’t automatically explain how those pieces belonged together.

That led to the eight-step Guide:

Factory → Breakdown → Impact → Recovery → Approval → Repair → Restoration → Memory

It uses the actual application APIs and saved proposals in a separate practice factory. The walkthrough is another way to use the workflow, rather than an animation showing a predetermined success.

Caption: Inspection needs finished parts. Showing that dependency first makes the later disruption easier to understand.

The full workspace separates the operational responsibilities:

FactoryGraph currently runs locally. The video demonstrates the application with synthetic factory data; live machinery integration is future work.

Code

The implementation, setup instructions, architecture and tests are available here:

Browse the FactoryGraph repository

For the most interesting implementation details, start with the grounded Gemma briefing, the guided workflow, and the architecture documentation in the README.

How I Built It

1. Represent the relationships before asking for recommendations

The factory is represented in FalkorDB through connected operational entities: machines, jobs, operators, materials and customer orders.

Those relationships let the application follow a disruption beyond its immediate location.

A machine failure affects a production stage. That stage may block another stage. Those stages contribute to a customer order.

This makes the impact inspectable. An operator can follow the path behind an affected order instead of accepting an unexplained warning.

Caption: The affected customer order is connected to the failed machine through recorded production dependencies.

2. Keep scheduling and money in deterministic code

I wanted the AI boundary to be clear.

The planner checks machine suitability, operator qualifications, existing bookings, shifts, permitted overtime, dependencies and material readiness.

The financial calculation uses configured rates for components such as equipment downtime, waiting labour, changeovers, repair labour and order delay penalties.

Money is stored as integer paise.

This also exposes trade-offs that an optimistic summary could miss. Moving production elsewhere may protect a deadline, but it does not erase the broken machine’s downtime cost. A changeover can add cost even when the overall recovery is preferable.

The planner is bounded and designed around small modeled factories. It does not claim industrial-scale optimal scheduling.

3. Give Gemma a useful, restricted responsibility

FactoryGraph uses Gemma 3 4B locally through Ollama for the recovery briefing.

Its responsibility is to help a beginner notice the important facts in an already calculated proposal.

The application prepares a set of supported facts. Gemma selects identifiers for the summary, trade-offs and review checks. The server validates those identifiers and renders the corresponding text.

That means the recovery briefing cannot introduce an invented rupee amount or a new machine assignment.

The application also always includes the cost comparison and the reminder that approval belongs to the operator. Those essential details do not depend on the model remembering to mention them.

Caption: Gemma selects relevant points from calculated evidence. It has no production mutation or approval tools.

4. Treat model failure as an expected condition

During development, the briefing sometimes showed a rule-based fallback. That was a useful reminder that connecting a model is only part of the job.

A local model can be unavailable, take too long to load, or return an unsupported response.

The briefing now uses a constrained selection schema, validates its output, and distinguishes failure reasons such as an unreachable service, missing model, timeout or invalid response.

If generation fails, the application identifies the fallback and keeps the recovery workflow available.

I would rather show an honest, limited explanation than make a model’s availability a requirement for reviewing a calculated plan.

5. Approve the exact proposal that was reviewed

A recommendation is useful only if the approval refers to the same recommendation.

The server creates a canonical hash for a proposal. Approval submits that hash, and the application checks ownership, proposal status, revision and current planning context.

If the context changes, the operator must reanalyse rather than apply an old proposal.

Repair completion is separate, too. Recording that a machine is available does not silently move work back. Restoration gets its own review.

How the pieces fit together

Suggested diagram: Browser → FastAPI → FalkorDB and planning logic; FastAPI → Ollama/Gemma for read-only briefings; LangGraph → saved day-based workflow checkpoints.

The browser interface is built with HTML, CSS and JavaScript. FastAPI handles the application endpoints. FalkorDB stores connected factory context and operational records.

LangGraph manages the separate day-based recovery workflow with saved checkpoints. The hourly breakdown workflow shown in the Guide uses its own saved reviews and approval endpoints; it is not simply one long language-model conversation.

What I verified

The latest local verification included 61 passing backend tests, five frontend tests, and a packaged Linux smoke check.

These checks establish behavior in the demonstrated environment. They do not establish real-world savings, factory-scale performance or production readiness.

Why Does Open Innovation Matter?

A factory’s order deadlines, operating rates and recovery choices can be sensitive business information.

Running Gemma locally means the briefing does not require sending that factory context to an external model API. After the model and dependencies are installed, the local inference path does not need a hosted inference service.

It also gives me control over the model, schema and failure handling. I can change the briefing behavior without rewriting the scheduling rules or tying the product to one provider’s inference pricing.

There are still costs: hardware, electricity, setup and support. A cold model can also take time to load. Local inference makes those trade-offs mine to manage; it does not make them disappear.

Open-source frameworks matter beyond inference as well. LangGraph provides inspectable workflow machinery, while the surrounding application can preserve explicit boundaries between reading context, proposing work and approving changes.

A hosted API could support a similar design. The advantage here is being able to offer the local deployment model and control that this particular customer might value.

What I would build next

Before adding more AI features, I would prioritise:

1. A workshop pilot: validate the configuration against actual scheduling habits and recorded breakdowns.
2. Easier onboarding: import existing machine, order and shift data instead of entering everything manually.
3. A paid-service foundation: accounts, subscriptions, backups and support tooling once the pilot establishes value.

Live telemetry is another direction, but the current machine-health readings are simulated. I would not describe them as failure prediction.

The next milestone I care about is a workshop supervisor being able to inspect a recovery and say, “Yes, that matches how our floor works.”

Prize Categories

Best Use of Gemma

FactoryGraph runs Gemma 3 4B locally through Ollama to select useful briefing points from calculated factory facts. Its output is validated, its operational permissions are restricted, and the workflow remains available when inference fails.

Building FactoryGraph made me appreciate how much happens between “a machine stopped” and “we know what to do.”

The schedule, the dependencies, the customer promise, the cost assumptions and the repair history all have to meet somewhere.

That is the product I want to keep building: a place where a small workshop can bring those facts together and make its next decision with more confidence.