Inspiration

A supplier cancellation or a workcenter outage can disrupt a manufacturing plan that already has confirmed orders, purchased materials, and scheduled production. Starting over can waste valid commitments, while a plausible recommendation still needs to be translated into precise ERP changes.

ForgeFlow makes this recovery process reviewable: understand the disruption, inspect a repair plan, authorize specific changes, and verify the result against the ERP.

What it does

ForgeFlow is an AI-assisted workbench for two manufacturing recovery scenarios: supplier cancellations and workcenter outages.

The product workflow lets a reviewer:

  • Inspect affected orders, failed supply, and existing commitments.
  • Review proposed purchase and manufacturing changes, costs, and constraint checks.
  • Ask NVIDIA Nemotron, served through Nebius Token Factory, to explain the case and execution evidence.
  • Approve a specific plan before controlled execution.
  • Inspect ERP readback and the original task verifier's result.

The product assistant has read-only access to scoped evidence. A person authorizes ERP changes.

A separate autonomous research mode lets a Pi agent call prepare_recovery and execute_recovery(plan_id) under its configured execution authorization. Product acceptance and autonomous research outcomes are reported separately.

How we built it

The workbench uses React and TypeScript, with a Python and FastAPI backend. Docker hosts synthetic Odoo ERP environments. NVIDIA Nemotron runs through Nebius Token Factory and supports evidence-based review.

ForgeFlow builds on two ERP-Bench recovery tasks. ERP-Bench provides the task definitions, synthetic business data, Odoo environments, CP-SAT reference planner, and original business verifiers.

Our contribution connects those foundations into a product workflow: ERP document mapping, independent checks, plan-bound approvals, controlled execution, persistent journals, ERP readback, and case-specific verification receipts.

The hosted demo provides separate persistent reviewer workspaces. Judges can use the application without installing software or supplying a model API key.

Challenges we ran into

A recovery plan has to distinguish the full planning scope from the directly affected demand and the actual supply gap. In Scenario A, those are 50 units across five orders, a linked 13-unit customer order, and a failed three-unit purchase.

Execution introduces another set of challenges: ERP state can change after planning, requests can be retried, and operations can stop partway through. We built explicit approval validation, execution journals, and readback checks so that a generated plan, an authorized action, and a verified result remain distinguishable.

We also clarified cost and margin definitions so that whole-plan costs are not confused with the incremental cost of a disruption.

Accomplishments we're proud of

The supplier-recovery workflow performs real writes to a synthetic Odoo sandbox, replacing failed supply while retaining valid commitments.

Documented local product acceptances passed 51 of 51 applicable rules for supplier cancellation and 95 of 95 for workcenter outage, each scoring 100/100 with the original ERP-Bench verifier. These runs used authorized HTTP approval drivers; they establish approved workflow results, not autonomous model completion.

The public two-minute video demonstrates the supplier-recovery workflow and includes a separately recorded historical workcenter-outage result. The repository links the implementation, screenshots, receipts, and validation evidence.

What we learned

Language-model explanations, constraint planning, execution authorization, and business verification need clear responsibilities.

Nemotron helps a reviewer understand the evidence. CP-SAT computes recovery plans. Approval establishes permission to act. ERP readback and the original verifier establish what happened and whether the task requirements were met.

Keeping these responsibilities visible makes the system easier to inspect and its results easier to trust.

What's next for ForgeFlow

Current complete product execution supports one finished product and a single-level bill of materials.

Next steps include broader product and multi-level bill-of-materials support, additional disruption scenarios, improved recovery from interrupted execution, and more systematic autonomous-agent evaluations with both successful and unsuccessful runs retained.

Built With

Share this project:

Updates

Submission history