Production Bottleneck Agent

An interactive decision-support demo for factory managers and line engineers. It turns a synthetic production-line condition into a plain-language diagnosis, compares three practical responses, and recommends the best first action for restoring flow and meeting the shift target.

The project is designed for short-term operational decisions, not automated production control. All station names, operating figures, event patterns, and outcomes are fictional.

Try the demo

Live site: Open LineLens

Use New cause + parameters to generate a different operating condition from the nine-case playbook. Review the line and its highlighted clues, then select Run diagnosis. Use Refresh diagnosis to replay the analysis without changing the current condition.

Production-line model

Load -> Preprocess -> Process A + Process B -> Merge -> Inspect -> Pack
                                                     ^          |
                                                     |-- Rework-|

Process A and Process B run in parallel, so Merge must receive output from both. Units that fail inspection enter Rework and return to Inspect before packing.

The interface shows throughput, work in progress (WIP), time per unit, busy time, stopped time, time waiting for material, and time unable to unload. Circled values are diagnostic clues, not automatic proof of a root cause.

Nine-scenario playbook

Each generated condition selects one causal pattern and varies its operating values with a seed. The values change, but the clues, diagnosis, and recommended response remain internally consistent.

Scenario	What the line may show	First action to test
Uneven material supply	Low WIP; both branches wait for material	Feed smaller batches at regular intervals
Irregular finished-goods pickup	High WIP; Pack cannot unload	Trigger pickup at a set fill level
Inspection drift	Rejects rise while known-good parts pass a separate check	Recheck Inspect with known-good samples
Frequent product changes	Output falls after repeated changeovers	Group compatible product families
Branch equipment stops	One branch pauses repeatedly; Merge waits for it	Repair the recurring stop on the affected branch
Insufficient finished-goods space	Completed-unit space stays full despite normal pickup	Add controlled temporary overflow space
Shared staffing constraint	Inspect and Pack wait for help at the same time	Provide separate coverage during peak periods
Pack equipment fault	Pack stops even when material and output space are available	Repair the recurring Pack interruption
Upstream quality problem	Excess failures circulate through Rework	Correct the upstream defect source

See SCENARIO_PLAYBOOK.md for the full clue-reading guide, definitions, competing explanations, and intervention logic. See PROJECT_BRIEF.md for the product thesis and scope.

How the diagnosis works

1. Generate: choose one playbook cause and vary its synthetic operating parameters.
2. Observe: display the resulting line state, WIP, throughput, station conditions, and event-pattern clues.
3. Diagnose: connect clues across the line and rank plausible causes.
4. Compare: estimate three independent what-if actions from the same baseline.
5. Recommend: show the strongest first action, expected throughput gain, and whether it reaches the target.

The public demo uses bundled planning estimates. It does not run a new discrete-event simulation or call an AI model when a button is selected. Recommendations are examples for human review, not validated instructions for a real production line.

How Codex and GPT-5.6 were used

GPT-5.6, working through Codex, supported the project throughout development:

• translated the factory decision problem into the nine causal scenario patterns;
• helped distinguish observable symptoms from assumptions and root causes;
• reviewed whether each recommendation followed from the clues displayed in the interface;
• generated and refined the synthetic parameter variations and what-if comparisons;
• identified contradictions between station metrics, highlighted clues, and scenario explanations;
• rewrote specialist terminology into concise factory-floor language;
• implemented the interactive site, diagnosis controls, responsive layout, and automated checks; and
• documented the product boundary so the static demo is not presented as a live model or a validated industrial control system.

Historical evaluation reports in reports/ record earlier blinded experiments in which Codex selected interventions through a sealed local simulator. Those reports are supporting development evidence; they are not the runtime behavior of the public site.

Local setup

Requirements:

• Node.js 22.13 or newer
• npm

From the repository root:

cd site
npm install
npm run dev

Open the local address printed in the terminal. No API key, external dataset, test account, or factory connection is required. The sample scenarios are bundled in the project.

Build and test

cd site
npm test

The test command creates a production build and checks the rendered product surface, including the separate diagnosis refresh behavior.

To create only the production build:

cd site
npm run build

Data and implementation boundary

• Scenario selection and parameter variation happen in the browser.
• The scenario library and planning outcomes are bundled with the site.
• The deployed interface does not require an OpenAI API key.
• No proprietary factory data, employer screenshots, or confidential operating rules are included.
• A real deployment would require calibration against the factory's topology, event definitions, process distributions, costs, and safety controls.

Being API-free keeps this demonstration easy to run and review, but it is not the main product claim. The central value is the traceable decision chain from line condition to evidence, likely cause, practical comparison, and recommended first action.