Enter the preview passphrase to read what is ready so far.
Industrialized AI puts a repeatable process around work done by AI models.
Industrialized AI uses AI models to manufacture products such as reports, documents, and source code. We arrange the work as a series of predefined stages, called a pipeline, in which models manufacture a product, inspect it, repair defects found during inspection, and inspect the revised version. Software runs this pipeline, calling models to do the work, recording what happens at each stage, and enforcing business rules and limits.
AI models can make mistakes when manufacturing, inspecting, or repairing a product, just as people can. We treat each stage like anything else in engineering: define what it must do, record what happened, test how well it works, and improve it when it fails.
We record the source information, every version of a product, the problems found, the changes made, and the decision to accept the product or stop work. An accepted product is released with the evidence supporting its acceptance, so that decision can be reviewed if the product is questioned later.
We need to know what a product is for before we can decide how to make it and what would make it good enough to use. A software team might need a reviewed vulnerability report to decide what requires attention, so the report must distinguish claims supported by evidence from conclusions that still need investigation.
Illustrative incoming AI-generated vulnerability report
Once we agree what a product needs to do, we define a pipeline that sends each version for inspection before release. The results of inspection are recorded as inspection findings: whether a version meets its requirements and, if it doesn't, what is wrong and why. The pipeline uses those findings to decide whether to release the product, send it for repair, or stop if the requirements can't be met within agreed limits.
Models manufacture a product from source material, inspect it against agreed requirements, and repair any problems found. The pipeline sends repaired versions for inspection again and releases a version only when it passes the required checks.
Produces a product version from the recorded material.
Checks the product against the agreed requirements.
Uses the version that failed inspection and the reasons it failed to produce a corrected version.
Makes the accepted version available with its evidence.
Source material is the information used to produce and inspect a product, so we record it before work begins and use it to check what the models produce. The incoming report and the evidence needed to assess its claims provide that material in this example.
| Incoming report | The report claims a critical, internet-facing remote-code-execution vulnerability in gateway runtime 4.2. |
|---|---|
| Vulnerability advisory | The vulnerability is rated Critical (9.8). The affected feature permits unauthenticated remote code execution when it can be reached. |
| Runtime and configuration | Gateway runtime 4.2 is installed and the vulnerable feature is enabled on port 8443. |
| Scanner observation | Port 8443 accepted a connection from the corporate network. |
| Network controls | No route from the internet is published, and the recorded firewall rules include a rule denying incoming internet connections. |
| Known gap | No independent connection test was made from outside the corporate network. |
Before manufacture, we agree what a product needs to do and how inspection will check that it meets those requirements. The report must answer the questions below and explain what information is missing and what can't be concluded without it.
| 01Applicability | Are the affected runtime version and vulnerable feature present? |
|---|---|
| 02Exploitability | Can the vulnerable feature be exploited, and what conditions must be met? |
| 03Exposure | Can the vulnerable feature be reached from inside or outside the corporate network, or both? |
| 04Severity and action | Do the established facts support the rating and recommended response? |
| 05Limits | What information is missing, and how could it change the report's conclusions? |
In this example, a model reviews the incoming report and supporting evidence, then drafts a report answering the questions agreed before manufacture. The process saves this first version so it can be inspected.
| Affected component | Confirmed: gateway runtime 4.2 is installed. |
|---|---|
| Vulnerable feature | Confirmed: the feature is enabled on port 8443. |
| Impact | Unauthenticated remote code execution if the vulnerable feature can be reached. |
| Exposure | Internet-facing. |
| Severity | Critical (9.8), as rated by the advisory. |
| Recommended action | Interrupt planned work and deploy the patched version immediately. |
Producing a first version doesn't establish that it meets the requirements, even when it looks convincing. Inspection follows manufacture so that the work is checked before it's released for use.
Inspection uses source material to check whether a product meets the requirements agreed before manufacture. For this report, a model checks whether the answers are supported by evidence and whether the report explains what information is missing and what can't be concluded without it. The pipeline uses the inspection findings to decide whether to release the report, send it for repair, or stop.
In this case, the claim of internet exposure isn't supported: the connection came from the corporate network, and no external connection test was supplied. The pipeline sends the report for repair so that the unsupported claim can be corrected.
Repairs continue within the agreed limits, and a product is released only after it passes the required checks. If those checks can't be completed or the product still fails when the repair limit is reached, the pipeline stops.
| Question | Can the gateway be reached from the internet? |
|---|---|
| Report claims | The connection to port 8443 confirms internet exposure. |
| Evidence shows | The connection came from the corporate network. No external test was supplied. |
| Model’s assessment | Internet exposure has not been established. |
| Process decision | Repair required |
A model used for both manufacture and inspection may repeat a mistake when checking its own work, so a passing inspection doesn't prove that the product is correct. We can test a model's inspection accuracy using reports whose correct conclusions are already known, including versions with deliberate mistakes such as the unsupported exposure claim here. Comparing the inspection findings with the known conclusions shows which errors the model catches or misses and whether it wrongly rejects correct conclusions. The test results help a team improve inspection and judge whether it's reliable enough for their work.1
Most of the report still holds up, so repair can keep those parts and correct the unsupported claim without starting the review again.
Repair takes the version of the product that failed inspection and the reasons it failed, and uses those to produce a corrected version. The pipeline sends the report and supporting evidence to a model, along with inspection findings that explain why the claim of internet exposure isn't supported.
reviewed-report-r001 Failed inspection The report treated a connection from the corporate network as proof of internet exposure.
No connection test was made from outside the corporate network.
reviewed-report-r002 Repaired report The report no longer claims internet exposure and identifies the missing external test.
Repair can introduce new mistakes or leave the original problem unresolved, so the new version goes through the same inspection again. The checks cover the whole product, including the parts that repair was meant to preserve.
The revised report distinguishes internal connectivity from internet exposure and identifies the missing external test. It passes inspection because its conclusions are supported by the supplied evidence and it explains why internet exposure hasn't been established.
For this report, the source material, earlier versions, and inspection findings show what changed and why the final version was accepted.
| Affected component | Confirmed: gateway runtime 4.2 is installed. |
|---|---|
| Vulnerable feature | Confirmed: the feature is enabled on port 8443. |
| Impact | Unauthenticated remote code execution if the vulnerable feature can be reached. |
| Observed exposure | Confirmed from the corporate network. |
| Internet exposure | Not established by the available evidence. |
| Severity | Critical (9.8), as rated by the advisory. |
| Recommended action | Deploy the patched version. Verify whether the service is reachable from the internet. |
If a mistake is discovered after release, a team can examine the records from the process to investigate where it arose and why it wasn't caught.2 These records also help a team improve manufacture, inspection, and repair by testing changes on examples with known answers and measuring how those changes affect quality, cost, and delivery time.