Current status

Document status: rolling facts page. This page states what the code implements and what deployers complete themselves. Brand guide governs product positioning.

Conclusion summary

Ingot's main software workflow is implemented, including field-data integration, run comparison, process diagnosis, and engineer-confirmed next-recipe recommendations generated directly from real recipe runs. Controlled validation is a separate optional workflow.

The repository claims only code, database contracts, automated tests, and reproducible software behavior. It bundles no scenario-specific validation data, historical protocols, or effect results.

• Repository responsibility: software capabilities, constraints, permissions, audit, fail-closed behavior, and a deployment reference.
• Deployer responsibility: data quality, scenario applicability, process safety, recipe adoption, and realized-benefit evaluation.

Status overview

Implemented software capabilities

The repository currently covers:

• connecting field sources, standardizing fields and units, and resuming delivery after a network outage;
• linking equipment, product, specification, material, tooling, process curves, and quality outcomes to one run;
• checking completeness, actual execution values, units, sources, and versions before analysis;
• comparing eligible runs and showing key differences, candidate causes, counterevidence, and evidence gaps;
• automatically combining admitted real recipe runs with quality outcomes into optimization observations without requiring a user-created experiment;
• generating next-recipe recommendations inside safety boundaries and the observed parameter envelope without automatic dispatch;
• designing controlled validation with controls, repetition, and safety boundaries when needed;
• selecting response-surface or Gaussian-process methods according to the data and degrading when evidence is insufficient;
• preserving evidence, constraints, model versions, engineer review, and final outcomes for every recommendation;
• providing a permissioned analysis assistant plus backup, restore, monitoring, and basic failure-drill tooling.

“Implemented” means repository code, database contracts, and tests exist. It does not mean the software fits every process or has produced a particular business benefit.

Repository validation boundary

The repository bundles no public or field-validation datasets, historical round protocols, result trajectories, or effect reports. Optimizer unit tests cover algorithm contracts, determinism, constraints, fail-closed behavior, and historical replay without future-result access. Scenario-specific effect comparisons run in the deployer's own environment.

Deployer responsibility

Deployers are responsible for:

• defining objectives, controllable parameters, safety constraints, and acceptable risk;
• ensuring reliable identity and timing across runs, recipes, process data, and quality results;
• comparing applicable baselines on their own data and choosing acceptance thresholds;
• reviewing, adopting, or rejecting recipe recommendations;
• evaluating actual quality, cost, cycle-time, and production-safety effects.

See Scenario validation for an optional evaluation method.

Production-deployment boundary

The default Docker Compose setup is for local development and a single-machine reference deployment; it does not complete production requirements. Production deployers still configure secrets, identity, and site isolation and complete backup, recovery, capacity, alerting, equipment interlock, human approval, stopping, and fallback drills.

See Production architecture for the target topology and Deployment for current operating steps.

Status update rules

1. Software capability follows merged code, database migrations, and automated tests.
2. Scenario effects and business benefit are confirmed by deployers using their own evaluation data.
3. Production maturity is confirmed by recovery, capacity, security, and operating evidence from the target site.