software-factory
Type: types/tag-readme.md
Software factories in the Greenfield sense: configured, family-specific software-production environments, the development work that builds and revises that reusable machinery, and the larger software house that stays responsible for software evolving for external users. The defining notes are software factory, factory development, and software house. Notes here ask when agentic systems become factories and what it would mean for a factory to learn. Assign this tag when reusable production machinery for a product family, its development, or the organization responsible for it is a substantive subject. Producing software with an agent alone is insufficient. Theory-builder covers systems that criticize and revise stated theories; work on a system that does both can carry both tags. A child of self-improving-systems.
Definitions and boundaries
- Software factory — the configured environment for one declared family; implies no learning or autonomy
- Factory development — revising reusable family-level machinery, as opposed to solution development on one product
- Software house — the complete persistent producer, including people and machinery; wider than any factory it uses
- Task families and product families classify different things — why a benchmark task family is not a factory's product family
- Universal software factory needs a declared universality axis — what must be declared before "universal" means anything
Agentic factories
- An agentic substrate becomes a software factory through family-specific production machinery — a generic harness is not yet a factory
- Broad software demands create pressure for agentic factory development — why predefining every family's machinery is implausible
- Factory construction is not evidence of production-knowledge acquisition — prior recursive constructors were handed the knowledge that determined their factories
- Preferential codification concentrates less predictable work at the agent boundary — what remains for agents as a factory codifies its predictable steps
- An addressable theory can coordinate heterogeneous factory development — natural-language project theory as the coordinating layer
- An open-domain theory builder becomes a software house when new domains require production-machinery changes — where the Commonplace arrangement crosses into software-house territory
Factory learning
- Factory learning is experience-responsive retention that improves the factory — the working definition: retained change to reusable machinery that later production depends on
- Factory-learning mechanisms should be compared on the same causal job — update mechanisms compared on retention, separated from the project-theory function
- A better-factory claim compares operative states under an antecedent assessment relation — what an improvement claim compares, and that the relation is fixed in advance
- Open-ended theory learning and factory learning close the same reflective loop — in Commonplace one connected path serves both
- A fixed-model house must retain missing procedures for theory use — with weights pinned, new procedures must live outside the model
Related Tags
- self-improving-systems — the parent: factory learning is self-improvement of production machinery
- theory-builder — the theory side of the same reflective loop; shares the software-house and coordination notes
- continual-learning — factory learning is one case of retention that accumulates across production episodes
- improvement-loop — the search, evaluation, and retention machinery a factory revision can pass through
- reflection — revising production machinery through a self-representation
- warranted-autonomy — whether an automated software house can take its factory decisions without humans