The Dark Factory

The Dark Factory is REQQA's longer-term vision: a requirements-driven, increasingly autonomous software development lifecycle, where a well-specified application in REQQA becomes the input to an AI builder that produces working software with progressively fewer human stops along the way.

The name borrows from manufacturing — a "dark factory" is one that can run with the lights off, because the work is automated. REQQA's version is not lights-off today, and may never be entirely. It is a direction of travel: each release tightens the loop between specifying what you want and getting working software, while keeping the human decision points that actually matter.

note

This page describes both shipped behaviour and forward-looking design. We are careful to mark which is which. Where something is a vision or a planned capability rather than something you can use today, it says so.

Why a lifecycle at all

AI-assisted development compresses execution time dramatically. A build phase that once took weeks can take hours. The instinct is to conclude that process is now overhead — that you can simply ask for software and receive it.

REQQA takes the opposite view. When execution is fast, the cost of building the wrong thing is no longer measured in calendar time; it is measured in wasted cycles and rework. Speed makes explicit governance more valuable, not less, because the only thing protecting you from rapidly building the wrong thing is the quality of the specification and the discipline of the decision points around it.

So the Dark Factory is built around an explicit, staged lifecycle. The stages are sequential in logic but rapid in execution, with feedback loops at every step. This is not waterfall — the defining difference is that the builder participates in reviewing the specification, a stage that does not exist in conventional processes because human builders rarely have the bandwidth for it. An AI builder does, and the review costs minutes.

The seven stages

The lifecycle moves a unit of work from specification to accepted delivery through seven stages:

Specify → Scope → Review → Design → Plan → Build → Accept

Stage	Owner	What happens	Output
Specify	You, in REQQA	Write and refine requirements, generate and curate stories, build the glossary, run DeFOSPAM analyses, resolve issues	Analysed requirements, analysed stories, populated glossary
Scope	You, in REQQA	Select a coherent set of stories that form a deliverable unit; the requirements come along via their parent stories. State exclusions and constraints	A named Release (a scope) with its story linkage and boundaries
Review	Builder, with your oversight	The builder reads the whole package as a prospective implementer and raises specification gaps, risks, and questions as issues	Builder-review issues against specific artefacts
Design	Builder, with your approval	Translate requirements into technical design decisions — data model, UI flow, architecture — before committing to a build approach	A design record with logged decisions and rationale
Plan	Builder, with your approval	Produce a concrete, phased, testable implementation plan	A versioned build plan linked to the Release
Build	Builder, with your testing at boundaries	Implement the design phase by phase, autonomously within each phase	Committed code, phase reports, migration scripts, test results
Accept	You, in REQQA	Test, formally accept, capture the as-built state, and record learnings to the backlog	A closed Release, a build report, backlog additions

Each stage has explicit transition criteria — you don't drift from "I think we're ready to build" to building; you meet defined criteria and transition. For example, a Release should not move from Scope to Review until its in-scope requirements have been analysed (the core DeFOSPAM checks), its stories have valid Gherkin, and the glossary covers the terms the analysis flagged.

tip

In the user interface the word for a unit of work is Release. Under the hood the object that a Release configures is called a scope — you'll see this in the data model (a Release links stories via a scope-stories table) and in the code paths. When this page explains the model it says "scope"; when it talks about what you do, it says "Release". See Releases and Scopes for the full story.

Why Design is a separate stage from Plan

It would be tempting to fold Design into Plan — they both come after Review and before Build. REQQA keeps them apart deliberately, because they answer different questions:

• Design answers "what are we building, and how does it fit together?" — data models, architecture, UI flow, the decisions that shape the shape of the thing.
• Plan answers "in what order do we build it, and how do we verify it?" — phases, sequencing, tests, risks.

The distinction matters for a concrete reason: design decisions are specification-adjacent and can flow backwards into requirements, whereas planning decisions rarely do. If the design reveals that you need a junction table nobody mentioned, that is a gap in the specification — it feeds back to Specify. If the plan decides to build feature B before feature A, no requirement changes. Conflating the two leads to designs driven by delivery convenience rather than correctness.

Feedback loops are first-class

The stages are sequential, but going backwards is not failure — it is the process working. Feedback flows backward at defined points, and every backward flow leaves a traceable record:

• A blocker raised in Review that exposes a requirement gap feeds back to Specify.
• A Design choice that reveals a missing requirement feeds back to Specify.
• An edge case discovered during Build that needs a new story feeds back to Specify.
• Something found during Accept testing that was never specified becomes a backlog item, or a new requirement.

How REQQA artefacts feed the builder

The thread that runs through every stage is that REQQA is the system of record. Conversation context is ephemeral; REQQA records are permanent. Concretely, the artefacts you build in REQQA become the builder's input:

• The mission gives the builder the context every requirement inherits — what the application is for, who uses it, what's in and out of scope.
• Requirements and their stories describe what to build, with Gherkin scenarios as concrete acceptance behaviour.
• The glossary pins down the domain vocabulary so the builder and the specification mean the same things by the same words.
• DeFOSPAM analysis has already found and (where you chose) resolved faults in the requirements and stories before the builder ever sees them — so the builder starts from a specification that has been stress-tested. See The Analysis Engine.
• A Release packages a coherent slice of all of the above into a deliverable unit.

One architectural decision ties the lifecycle together: all feedback across every stage uses the same issue mechanism that DeFOSPAM analysis already uses. Issues carry a source field — analysis for findings from REQQA's own engine, builder_review for the builder's specification review, and build_phase for things discovered during implementation. There is one issue workflow, one set of status transitions and comment rules, not three separate feedback systems. The builder's review is, mechanically, just more issues against your artefacts — which means you triage them with the tools you already know.

When a builder rejects one of your requirements as flawed, or you reject one of the builder's suggestions, the rejection requires a comment. The principle is firm: the analyst is the authority on requirements; the builder is an advisor. After a capped round of negotiation, your decision is final, and any unresolved disagreement is recorded as an acknowledged risk rather than silently dropped.

The autonomy levers

Reaching the Dark Factory is not one switch; it moves along two independent axes:

• Autonomy — fewer human intervention points per build (bounded by permission prompts, ambiguous decisions, and closure handshakes).
• Parallel — more builds running at once (bounded by shared infrastructure: one database, one app instance, file conflicts).

The design treats these as separate problems with separate solutions, advanced through a set of named levers:

• Permission allowlisting — approving classes of safe commands so routine actions don't prompt each time, with a permanent denylist for dangerous operations and human gates preserved at phase start and close.
• Conflict-aware scheduling — every multi-feature Release produces a conflict map (shared files, tables, fixtures) measured from the actual codebase, which determines what can build in parallel and what must be serialised.
• Decision precedent — when the builder hits an ambiguous design choice, it checks for precedent and proceeds if one exists, otherwise pausing for you; your answer becomes the next precedent.
• Phase-close redefinition — moving the single human-test gate from every phase boundary to the Release boundary, where you work through an aggregated testing checklist against the integrated result.
• Worktree-based parallel builds — isolated working trees so concurrent builds don't tread on each other (a later step, adopted only once the demand is proven).

These levers are advanced one trial at a time: process layers are built only to the extent the next trial needs them, each trial validates a lever, and its lessons feed the next.

The first real experiments

The vision is grounded in real builds, not just design documents.

The first end-to-end run of the build loop was Investo, a separate personal-investment-tracker application built on the same py4web stack. Its specification lived in REQQA as a Release; the build was planned, executed, and closed through the lifecycle's skills; and the builder posted feedback back into REQQA as issues against the requirements — including a real recommendation to tighten a requirement around currency handling, which became a traceable issue rather than a lost conversation. The first Investo release shipped with a substantial Playwright and controller-level test suite and a traceability matrix mapping its Gherkin scenarios to tests.

REQQA also builds itself this way — its own features are specified as requirements, scoped into Releases, planned, built, and closed through the same lifecycle. This "dogfooding" is the most demanding test of the model: the tool that manages the specification is also the thing being specified.

note

Vision vs shipped, in one paragraph. Shipped today: the full specify-analyse-scope workflow in REQQA, a public API the builder reads and writes through, the skills that drive the build loop (planning, starting, and closing builds), and real end-to-end builds (Investo, plus REQQA's own features). Forward-looking: full parallel builds across isolated worktrees, the most autonomous form of the decision-precedent lever, and the falsifiability metrics that will tell us whether the factory is genuinely working (throughput, defect rate per release, hours of human attention per shipped feature). The lifecycle definition is a living document and evolves with every release.

What this means for you

If you are using REQQA today, the practical takeaway is this: the quality of what comes out of the factory is set by the quality of what you put in. A thin mission, vague requirements, and an empty glossary give the builder little to reason with. A comprehensive mission, requirements that have been analysed and cleaned, stories with concrete Gherkin, and a glossary that pins down the vocabulary give the builder a specification that has already been stress-tested before a line of code is written.

That is the whole point of the lifecycle. The factory cannot manufacture clarity you didn't supply — but everything REQQA does in the Specify and Scope stages is aimed at making that clarity easy to produce.

Related

• Releases and Scopes — how a Release packages a unit of work, and the scope object behind it.
• The Analysis Engine — DeFOSPAM, the technique that hardens the specification before the builder sees it.
• The Mission — the context every requirement and every build inherits.
• Key Concepts — the vocabulary the rest of the manual builds on.