The Assembly Line Needs Receipts: Coordinating an Automation Factory

Introduction

This is independent personal research, undertaken autonomously and without organizational sponsorship. It draws only on public sources, personal reasoning, and bounded experiments where useful; it contains no confidential material. The ideas are provisional and may change as evidence improves.

This is a plain-language inquiry into a familiar architectural metaphor: organizing repeatable software work like a factory while keeping evidence and human judgment visible. The term is general industry language, and every design described here remains provisional.

Problem statement

An ordinary factory turns repeatable inputs into repeatable outputs. In software, the metaphor is useful only if it makes work easier to understand: what entered the process, which rules acted on it, what evidence was produced, and who retained authority over the result. This paper uses automation factory as a general architectural phrase. It does not name a repository, organizational system, commercial product, or unique invention.

The working hypothesis is modest: a software team can coordinate reusable automated work as a factory-like flow while preserving human judgment, traceable evidence, and reversible decisions. AI-enabled test design is one optional station in that flow. It may propose tests; it does not decide that software is safe to release.

Context and prior work

What “factory” means in software

Software architecture uses factory in more than one established sense.

First, a creational factory separates the request for an object from the details of constructing it. Factory Method and Abstract Factory are familiar examples: callers ask for a capability, while a dedicated component selects or assembles the concrete implementation.

Second, a software factory is an operating metaphor for producing related software through reusable models, patterns, frameworks, tools, and controlled variation. The aim is not to make creative work mechanical. It is to make the repeatable parts explicit so people can focus on the decisions that remain uncertain.

In this paper, factory means a coordinated system with five properties:

1. requests enter through a defined boundary;
2. reusable capabilities perform bounded work;
3. state changes are visible and explainable;
4. evidence accompanies important claims; and
5. a named decision rule determines whether work stops, continues, or returns for revision.

The phrase predates this paper

The underlying vocabulary has a documented history. Robert W. Bemer described a machine-controlled “software factory” in the proceedings of the 1968 NATO Software Engineering Conference. The 1994 Design Patterns catalog formalized Factory Method and Abstract Factory as creational patterns. Greenfield and Short later described software factories as a model-driven approach to product-line development.

The earliest exact use of automation factory located in the sources reviewed for this paper is Bowstreet's 1999 Web Automation Factory, a commercial system for producing customized business-to-business websites. A 2009 paper used intelligent automation factory for a service-composition facility. A 2017 OpenText case study used automation factory for a program that identified repetitive work and created reusable automations.

These references show prior use in documentation, products, and instructional material. They do not prove a single canonical definition, and this paper is not a claim that the author originated the term or model. The phrase is best treated as ordinary architectural language whose exact boundaries must be stated by each author.

Contribution

What “automation” adds

Automation applies repeatable rules without requiring a person to perform every step manually. In a factory-like software system, automation may classify a request, select a workflow, prepare an environment, run checks, gather results, or route an exception.

Automation does not remove responsibility. It changes where responsibility sits. People define the permitted actions, evidence thresholds, exception paths, and final authority. The system performs bounded operations and records what happened. A useful automation factory therefore distinguishes three kinds of activity:

• deterministic work, where the same input and rules should produce the same result;
• probabilistic assistance, where a model proposes or ranks possibilities; and
• governed decisions, where evidence is evaluated against an explicit policy and consequential action remains controlled.

Treating all three as interchangeable creates false confidence. A generated answer is not the same thing as an observed result, and an observed result is not automatically permission to act.

System or method

A generic architecture

A small conceptual model is enough to discuss the pattern without prescribing a product stack:

This separation matters because coordination, execution, and judgment fail differently. A workflow can be correctly followed while a tool produces a bad result. A test can pass while measuring the wrong thing. A model can suggest a plausible improvement while inventing its rationale. Each layer needs its own evidence and failure response.

AI-enabled test design as one optional station

Research published before the date declared for this paper showed that large language models could assist with unit-test improvement and text-to-test-case generation. That prior work supports experimentation, not unrestricted delegation.

One possible governed integration of AI-enabled test design is:

1. provide a bounded requirement, interface, or change description;
2. ask the model for candidate tests and the assumptions behind them;
3. reject candidates that lack a traceable target or observable result;
4. run accepted candidates in an isolated test environment;
5. compare failures and coverage with existing human and automated release gates; and
6. retain the prompt, candidate, execution result, and reviewer decision as separate evidence.

The model produces candidate tests. Execution produces observations. Existing human and automated release gates determine whether the observations are sufficient. This keeps generative assistance inside established testing and software-factory patterns instead of pretending that generation creates authority.

Evaluation

Failure conditions

The proposal should be revised or rejected when any of the following occurs:

• the factory metaphor adds more coordination cost than it removes;
• evidence cannot be traced from a decision back to an execution;
• probabilistic suggestions are presented as deterministic facts;
• one component silently becomes the sole source of state and authority;
• recovery requires hidden manual knowledge;
• test generation increases test volume without improving fault detection; or
• people cannot explain why an automated decision was permitted.

These are not edge cases. They are tests of whether the phrase describes a useful architecture or merely decorates an ordinary collection of scripts.

Artifacts and reproducibility

The conceptual layers, six-step AI-testing boundary, failure conditions, and research roadmap are the complete public artifacts for this paper. No implementation repository, confidential system, empirical dataset, or production result is part of the claim.

An illustrative research roadmap

The smallest useful investigation would proceed in three reversible steps:

1. Trace one workflow. Choose a low-risk task and record its request, actions, evidence, and decision.
2. Add one assisted test-design experiment. Compare model-proposed tests with tests written without that assistance, using the same change and evaluation criteria.
3. Exercise recovery. Interrupt the workflow, repeat an action, and confirm that state and evidence remain understandable.

This is a research roadmap, not an implementation backlog. Its purpose is to test the pattern's claims before expanding the system.

Alternatives considered

The factory metaphor is not required. A team could describe the same concerns using a pipeline, state machine, control loop, or service choreography. Those metaphors may be clearer when the work is mostly linear, state-centric, feedback-driven, or distributed. “Factory” earns its place only when reusable production, controlled variation, and inspectable evidence are central to the discussion.

Threats to validity

The historical search was bounded and may not have located the first use of the exact phrase. Product announcements and case studies establish that a phrase was used, not that the named systems succeeded. The AI-testing papers report particular studies whose results may not generalize to different languages, systems, or evaluation criteria.

Operational limits

This paper is an architectural synthesis, not evidence that an automation factory improves delivery. It presents no production deployment, controlled trial, or general performance result. Generated tests are not assumed to be correct, sufficient, or economical, and the proposed governance boundary does not replace legal, security, or domain-specific review.

Conclusion

An automation factory can be described using existing software language: factories separate construction from use and organize repeatable variation; automation performs bounded repeatable work; workflows coordinate state and evidence; and release governance preserves authority. The phrase is older than this paper and has no single owner.

The contribution here is one provisional arrangement of those established ideas. Its distinctive boundary is evidentiary: AI may help design tests, but generated tests do not authorize release. The pattern remains useful only while people can trace what happened, challenge the evidence, and reverse the decision.

References

1. Bemer, R. W. “Machine-Controlled Production Environment.” NATO Software Engineering Conference, Garmisch, 1968, pp. 94–95. Conference proceedings.
2. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
3. Bowstreet Software Inc. “Bowstreet Releases Web Automation Factory.” The Gilbane Report, vol. 7, no. 10, 1999. Archived issue.
4. Greenfield, J., and Short, K. “Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools.” OOPSLA, 2003. Paper.
5. Liao, Y. et al. “Intelligent Automation Factory.” 2009. IEEE record.
6. Banguero, S. “Operations Bridge helps Schlumberger's IT Operations Automation Maturity Scale.” OpenText Community, 2017. Case study.
7. Alshahwan, N. et al. “Automated Unit Test Improvement using Large Language Models at Meta.” 2024. arXiv:2402.09171.
8. Siddiq, M. L. et al. “Enhancing Large Language Models for Text-to-Testcase Generation.” 2024. arXiv:2402.11910.