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:
| Offering | Proposed price | What the customer receives |
|---|---|---|
| Assisted setup | â‚ą4,999 or $53 once | Help configuring one workshop and validating its initial assumptions |
| Workshop plan | â‚ą1,499 or $16/month | Application updates, support and periodic configuration reviews |
| Integration work | Quoted separately | Future imports or connections to existing operational systems |
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:
| Section | The question it answers |
|---|---|
| Exposure | How is this factory configured, what could the disruption cost, and which recovery should we review? |
| Floor | What work is assigned to each machine, and when? |
| Impact | Which connected stages and customer orders are affected? |
| Materials | Are stock availability or supplier deliveries constraining recovery? |
| Memory | What happened previously that could inform the next estimate? |
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:
FactoryGraph
When a machine stops, understand the impact before making the next move.
FactoryGraph is a factory operations copilot for small manufacturers. It connects machines, production stages, qualified workers, materials and customer orders in FalkorDB, traces the consequences of a breakdown, calculates feasible recovery options and estimated financial exposure, and lets an operator approve the response.
Connected factory context · Deterministic planning · Human approval · Sourced memory · Local Gemma briefings
This repository contains a working local demonstration with synthetic factory data. Financial results are estimates from configured rates. Machine-health readings are explicitly simulated.
Contents
- The problem
- What FactoryGraph does
- Screenshots
- Architecture
- Technology stack
- Graph data model
- Recovery workflow
- Scheduling and financial calculations
- Gemma and the AI boundary
- Memory, maintenance and procurement
- Installation
- Configuration
- Complete demo walkthrough
- Interface guide
- API reference
- Command-line tools
- Repository structure
- Testing and verification
- Persistence and shop isolation
- Troubleshooting
- Current limits
The problem
A…
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.
| Question | Evidence checked |
|---|---|
| Can approval apply an altered or outdated proposal? | Tests cover proposal tampering and stale planning context |
| Can another workspace’s data leak into the Guide? | Frontend checks cover scope boundaries |
| Does clicking through explanatory screens change production? | Navigation is checked separately from mutation |
| Can the workflow continue without Gemma? | Briefing failure and deterministic fallback are tested |
| Does the complete example work through the interface? | Browser walkthrough covers recovery, repair, restoration and memory |
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:
- A workshop pilot: validate the configuration against actual scheduling habits and recorded breakdowns.
- Easier onboarding: import existing machine, order and shift data instead of entering everything manually.
- 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.
Top comments (0)