Ingot: A Local-First System for Turning Production Runs into Optimized Recipes

What Ingot Actually Solves

Ingot addresses a specific pain point in manufacturing: turning every real production run into usable evidence for process optimization. Traditional approaches often require designed experiments before any optimization can happen. Ingot flips that. The standard workflow is "real recipe run → automatic optimization observation → next recipe recommendation → engineer confirmation → new run flows back." This matters for processes where recipe trials are expensive, sample sizes are small, and quality targets are explicit. The intended user is a process engineer who owns both the quality outcome and the recipe decision. Ingot does not automate the decision. It assembles evidence and proposes a next recipe, but the engineer confirms whether that recipe can go into production. The README is clear that the system does not replace MES, SCADA, LIMS, QMS, or ELN. It sits between those systems and the optimization step, adding a traceability layer that is often missing in ad-hoc spreadsheet-based analysis.

The Evidence Chain: From Run to Next Recipe

The core mechanism in Ingot is the linkage between a production run and its quality outcome. The platform API is the formal record source for factory business data and evidence assembly. It stores process configuration, field mappings, run records, and quality results. The optimizer is a separate, stateless numerical service that handles experimental design, surrogate models, and constrained sequential optimization. When a run comes in, the system checks whether the data is admissible for optimization. If it passes, the optimizer can recommend a next recipe with prediction intervals, risk estimates, and an evidence scope. If the data does not pass admission, the system stops recommendations, records the reason, and degrades to response surface methodology or traditional DOE. This admission gate is a deliberate design choice. It prevents garbage-in-optimization-out scenarios. The README also describes an Agent component that runs in the same process as the Platform API, but it can only access structured facts through authorized read-only analysis tools. It does not generate numerical settings or approve experiments. That boundary keeps the system from becoming another AI agent that hallucinates recipes.

Getting It Running: Demo and Full Stack

The quickest way to see Ingot is the local demo. It requires only Node.js 22.22 or later, no database, no Docker, and no devices. After cloning the repository, run `npm --prefix apps/platform ci` to install dependencies. Then start two terminals: one running `node scripts/platform-demo.mjs` and the other running `npm --prefix apps/platform run demo`. Open `http://127.0.0.1:3001` and log in with `demo / demo`. The demo uses synthetic data from a lens surface error case, showing how to open an out-of-tolerance run, compare it with a conforming run, view candidate causes, and enter the recipe optimization workspace. For a full deployment, the README gives a Docker Compose command: `docker compose -f docker-compose.app.yml up -d --build`, after copying `.env.example` to `.env`. You must change the database password, the Edge upload token, and the admin configuration before starting. The full stack runs on `http://localhost:3000`. Development requires .NET SDK 10, Node.js 22.22+, and uv 0.12.5, with a single verification script `./scripts/verify.sh`.

Architecture Boundaries You Should Know

Ingot's runtime architecture separates concerns in a way that mirrors real factory deployments. The Edge ConnectorHost has its own identity, local storage, and fault recovery lifecycle. It handles field protocols, semantic mapping, offline buffering, and replay. The Platform API is the formal record, and the Optimizer is a stateless numerical service. The Agent runs in-process with the Platform API. The README warns that code project boundaries do not equal deployment boundaries. Production topology and high-availability requirements are documented separately in `docs/production-architecture.md`. This is a practical distinction. You cannot assume that because the optimizer is a separate project, you can deploy it independently. The documentation forces you to read the production guide before scaling. That is a sign of maturity, but it also means the initial setup is not a single `docker-compose up`. You need to understand the edge connector's role, the admission criteria, and how data flows before you can trust any recommendation.

A Genuine Limitation: No Built-In Validation Data

The README is explicit: the repository only declares code, automated tests, and reproducible software behavior. It does not include any scenario-specific validation data or results. The local demo uses synthetic data and only verifies the interface and business flow, not real process gains. This is a significant limitation for evaluation. You cannot run the demo and assume the system will work on your process. The README says deployment teams must use their own data to assess suitability, safety, and actual benefit. That means the first real step after installation is not optimization but data preparation and admission testing. If your data does not meet the admission criteria, the system will stop recommendations and log the reason. This is a safe failure mode, but it also means you may spend weeks cleaning and mapping data before seeing a single recipe suggestion. The system is wrong for teams that want a plug-and-play optimizer without investing in data governance.

The Alternative: Designed Experiments vs. Natural Run Evidence

The main alternative to Ingot is traditional design of experiments (DOE) or response surface methodology applied to a dedicated experiment plan. In that approach, you deliberately vary factors across a designed matrix, run the experiments, and fit a model. Ingot's approach is different: it uses natural production runs as evidence, with no requirement to set up experiments first. The README describes a fallback to DOE or response surface when data admission fails. That fallback is not a separate product; it is built into the optimizer's method selection. The key difference is the source of data. DOE generates data under controlled conditions, which gives you causal confidence but costs time and resources. Ingot uses observational data from real runs, which is cheaper but requires careful admission checks to avoid confounding. If your process has very high experiment costs and you already have a rich history of production runs, Ingot's approach is attractive. If you need causal confirmation for a new material or equipment, the README says you must design a controlled verification separately. Ingot does not replace that step.

Maintenance, License, and Upgrade Path

Ingot is licensed under Apache License 2.0, not MIT as some quick scans might assume. The README lists the license as Apache License 2.0. This is a permissive license that allows commercial use, modification, and distribution, with the requirement to retain copyright notices. It does not impose copyleft obligations like GPL. For maintenance, the project provides a verification script `./scripts/verify.sh` that runs the full CI gate. The repository includes xUnit tests in `tests/Ingot.Core.Tests` for backend behavior, module boundaries, and protocols. The README mentions a roadmap that includes tightening natural run data admission, recipe recommendation explanation, and deployment reliability. There are no recent releases retrieved, so versioning is unclear. The default branch is `main` and the project is not archived. For upgrade cost, the documentation structure suggests a staged rollout: `docs/rollout.md` covers historical replay, shadow mode, and online verification. That implies you can test changes in a shadow mode before switching to online recommendations. The maintenance burden is real: you must keep the .NET SDK, Node.js, and uv versions aligned, and you must read the production architecture guide before any serious deployment.

Editorial conclusion

Adopt Ingot if you run high-cost, limited-sample manufacturing processes with clear quality targets and safety boundaries, and if you need a local-first, evidence-traceable way to turn real runs into next-recipe recommendations. Do not adopt it if you expect it to replace MES, LIMS, QMS, or real-time control systems. Before any pilot, verify that your data can meet the system's admission criteria; the README explicitly states that deployment teams must evaluate suitability and safety with their own data. Start with the local demo, then read docs/status.md and docs/pilot.md to understand what is implemented and what remains a boundary.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases