How Industrialized AI works at scale.
Industrialized AI's core loop manufactures one product, inspects it, repairs any defects, and releases an accepted revision. Larger products can be made from smaller products which have each passed that loop. Their accepted revisions become source material for manufacturing the larger product, which then receives its own inspection. This is composition: it lets us divide large work into products which can be manufactured and repaired independently, while still checking whether they work when combined.
When we reuse a component in other products, we call it a part. We package it with the information needed to manufacture it again: what it provides, the source material it uses, its acceptance basis, and its pipeline. That part can be shared directly or arranged with others in a catalog. Running the part's pipeline produces an accepted product revision for the work which needs that component.
Once parts and components are being manufactured by different pipelines, those pipelines need to pass accepted products between them. Connected in that way, they form a factory. The connections determine which work can run, what must wait, and where a failed product returns for repair. Each pipeline keeps its own process and evidence, while the factory can produce one or more larger products from their accepted outputs.
Composition
Manufacture the components, then use their accepted revisions to manufacture and inspect the finished product.
Start by defining the finished product and the components it needs.
To see how this works, imagine a team replacing an authentication library used by several services. The finished product is the complete software change: the updated services, tests, and operating documentation, all working together and ready to release.
We begin by identifying the components needed to make that finished product. Each component gets its own acceptance criteria and goes through the complete process before it can be used during assembly. For this change, the components look like this:
| Component | What it contributes | Acceptance criteria |
|---|---|---|
| Gateway change | The updated request-handling code and tests. | Uses the shared validator, preserves HTTP behavior, and keeps signing keys outside the handler. |
| Accounts change | The updated login path and tests. | Uses the replacement validator and preserves the existing login behavior. |
| Worker change | The updated service-token handling and tests. | Uses the replacement library and passes the worker job tests. |
| Operating documentation | Updated configuration and operating guidance. | Describes the accepted implementation rather than the library it replaced. |
Manufacture and inspect each component.
Each component goes through the core process with its own source material and acceptance criteria. The gateway, accounts, worker, and documentation can therefore be manufactured and inspected separately, while the finished product still records exactly which version of each component it requires.
source material:
recorded change requirements
gateway/session.go
gateway/session_test.go
shared auth.Validator contract
acceptance conditions:
every token is checked through auth.Validator
the handler never reads signing-key configuration
existing 200, 401, and 403 responses remain unchanged
the complete gateway test suite passesEvery component is handled in the same way. Some may pass the first time while others need repair, but assembly receives only accepted versions and the process retains exactly which version of each component it may use.
Manufacture the finished product from the accepted components.
The accepted component versions now become source material for another manufacturing operation. Assembly combines them with the parts of the repository which were deliberately left alone and produces the complete software change.
Gateway, accounts, worker, and documentation components.
Combine those components with the repository areas recorded as unchanged.
The assembled product now goes through its own inspection.
Component acceptance tells us what went into assembly, but it cannot establish that the components work together. That belongs to the inspection of the finished product.
Inspect the finished product for cross-component defects.
Finished-product inspection checks the properties which no component can establish on its own: whether every required component is present, the accepted versions were used, their interfaces agree, and the complete product behaves as expected. Those become acceptance criteria for the product as a whole.
| Finished-product criterion | What inspection establishes | Result |
|---|---|---|
| Complete scope | Every required component is present in the assembled repository. | Pass |
| Accepted versions | The exact component versions which passed inspection were used. | Pass |
| Interfaces | Accounts writes the user identity to sub; the gateway still reads user_id. | Fail |
| End-to-end behavior | A token issued by accounts is rejected by the gateway with a 401 response. | Fail |
| Documentation | The operating guidance describes the implementation being released. | Pass |
Both components passed their own inspections; their disagreement appears only when the finished product uses them together. This is why finished-product inspection is not a repeat of component inspection: it checks the relationships between accepted components. The model records the interface mismatch as a semantic finding; the decision table applies the finished-product tolerance, treats the defect as blocking, and sends the affected work to repair.
Repair the affected work, then manufacture the finished product again.
A cross-component defect does not send every component back through manufacture. Repair identifies the affected boundary and returns only the relevant work to the component process; any changed component must pass inspection again before its replacement can be used in a new assembly.
The accounts and gateway components disagree about the user-identity claim.
The gateway reads the claim produced by accounts and is accepted after complete component inspection.
The accepted replacement is assembled with the other accepted components.
Reassembly produces a new finished-product revision, so the previous inspection no longer applies. The complete inspection runs again to establish that the interface defect was corrected and that everything which passed before still holds; if it finds another defect, the product goes around the loop again.
The semantic assessment contains no finding which the declared tolerance treats as blocking, so the decision table accepts revision 2. It is ready to release together with the accepted component versions used to manufacture it.
Breaking work into products and components means the whole job doesn't have to fit into one enormous prompt, followed by an equally unmanageable review. Each operation deals with something clearly defined, and its accepted result becomes controlled source material for the next level.
This lets the process grow while keeping the work inspectable. We can make larger products from smaller ones without losing track of what was accepted, how the parts were combined, or where a defect needs to be repaired.
Reuse
Share reusable parts together with the information needed to manufacture them.
Parts let us reuse products we know how to manufacture.
The composition above starts with the components needed for one finished product and manufactures each of them for that job. Once the same kind of component is needed by several products, defining how to make it again every time would waste both effort and everything learned from the earlier runs. We can reuse the component as a part, packaged with the information needed to manufacture it again.
A part records what the product provides, the source material from which it can be made, the acceptance basis it must satisfy, and the pipeline which will manufacture, inspect, and repair it. The part can be shared directly with anything which needs that product; once there are enough parts, they can be arranged into catalogs to make them easier to find and retrieve.
Software libraries are a familiar example: several products can depend on the same interface, while each released version is built and checked from recorded sources.
| A part records | What it tells us |
|---|---|
| Identity and interface | What the part provides and how another product can use it. |
| Source material | The recorded information the pipeline may use to manufacture the product. |
| Acceptance basis | The characteristics, requirements, and tolerances every accepted product revision must satisfy. |
| Production pipeline | The operations which manufacture, inspect, repair, and release the product. |
When another product needs that component, it can receive the part directly or retrieve it from a catalog. Its request identifies the intended use and the source revisions to use, then the pipeline recorded by the part manufactures a product for that request.
- Retrieve the partReceive it directly or find it in a catalog.
- Run its pipelineManufacture, inspect, and repair until the product passes or the run stops.
- Accepted productA released product revision with the evidence behind its acceptance.
The core process has not changed; the part makes the information needed to manufacture the product reusable.
The output is a product revision manufactured from the part. It is released only after inspection accepts that revision, and the release carries the source material, production records, inspections, and any repairs which support it.
The accepted product revision can then become source material for another product. That product records which revision it used, so improving the part's sources, acceptance basis, or pipeline benefits future production without changing the history of products made from earlier revisions.
Coordination
Connect pipelines so accepted products from one become recorded inputs to another; together those pipelines form a factory.
Connected pipelines form a factory.
The work above involves several production lines: parts and components have to be manufactured, accepted revisions have to reach the pipelines which depend on them, and the larger products must then go through their own inspection and repair. When we connect those pipelines so that the accepted output of one becomes a declared input to another, the connected system is a factory.
Those connections record the products the factory must produce, the accepted inputs each pipeline requires, and the routes between their outputs. Independent pipelines can run together, while dependent work waits for its inputs. Because the dependencies and routes are declared, the factory does not ask a model which pipeline to run next or where its output should go.
There’s more to consider once several pipelines are working together, including how much work can run at once and whether inspection and repair can keep up with manufacture.
- Supply pipelinesManufacture the required parts and bespoke components.
- Accepted productsRecorded revisions become inputs to dependent pipelines.
- Assembly pipelinesManufacture and inspect one or more larger products.
- Factory outputsRelease accepted products with their connected evidence.
| Pipeline | Receives | Produces | Used by |
|---|---|---|---|
| Part pipeline | A shared part and recorded source material. | An accepted product revision. | Any component or assembly which requires that product. |
| Component pipeline | Its assignment, source material, and any required parts. | An accepted component revision. | The pipelines manufacturing larger products. |
| Assembly pipeline | The accepted parts and components declared for the product. | An inspected larger product. | Release or another pipeline which needs that product. |
| Dependent product pipeline | An accepted product and any additional source material. | Another accepted product derived from it. | The factory's declared outputs or another dependent pipeline. |
Passing an accepted product between pipelines is a recorded handoff. The receiving pipeline gets the accepted revision named by the connection, while the factory record retains the link to the run which produced it. The larger product can therefore show which product and component revisions were used without copying their production history into its own pipeline.
Inspection of a larger product may find a problem which belongs to one of its inputs or to the way several inputs were combined. The factory follows the route declared for that result, sends the rejected revision and defect to the pipeline responsible for correcting them, then resumes the dependent work from the accepted replacement. Products which were not affected remain available; their pipelines do not have to run again merely because another part failed.
A factory may produce one larger product, as the composition example does, or several related products with their own acceptance bases. Each product is released only after its own inspection passes, and the factory record connects every release to the pipeline runs and accepted inputs which produced it. When a shared part changes or one product fails, we can see what needs to run again without reconstructing the entire operation from a collection of prompts.
With these capabilities in place, we can plan and build products that would be impractical if people had to coordinate every step of production. We can select a coherent product variant, reuse qualified parts, choose how much machinery and capacity to apply, run independent work in parallel, and allow the time needed for inspection and repair.
That gives us control over the Golden Triangle of fast, cheap, and good. Instead of treating cost, speed, and quality as consequences we discover after the work is finished, we can specify the balance we want before production begins. The next page shows how those choices become a production order the factory can execute.