What_a_Dark_Factory_Actually_Is

A dark factory is a production system that operates continuously, autonomously, and without ambient human oversight. The manufacturing analogy is precise: someone engineered this factory, someone specified what it builds and to what tolerance, someone designed the failure modes and shutoff conditions. Lights-off production is downstream of intensive upstream specification work. The software industry does not yet discuss this clearly.

In manufacturing, the dark factory (or "lights-out manufacturing") was made possible by extreme specificity about inputs, outputs, tolerances, and exceptions. You do not build a dark factory by writing better code or faster machines. You build it by writing a specification so complete that a system can operate against it without human interpretation. The same principle applies to autonomous software systems.

When a factory runs without oversight, the specification becomes the only instruction the factory receives. Every architectural choice, every failure path, every context-window constraint, every rate-limit tolerance has to be documented before the lights go off. This is a specification problem, not a generation problem.

What_My_System_Actually_Looks_Like

My portfolio and SaaS operations run a 12-agent system across 6 repositories. The agents are named explicitly: Sheena (orchestrator), Nix, Sable, Quinn, Tom, Oren, Reid, Jo, Vera, Maya, Lena, Cleo. Each has a defined role, a trust tier, and a model assignment. This is not a system where agents make decisions in isolation. It is a system designed to run autonomously because the specification is precise enough to constrain the autonomy safely.

One artefact demonstrates this clearly: EXP_004 (Routines Repo Audit), a scheduled job that runs nightly across all six repositories without human initiation. It checks for stale manifests, failing CI, uncommitted worktree state, branch hygiene violations. It does this every night, touches the code in all six repos, and no human has started it or monitored it during that time. The factory is running lights-off, right now.

The specification layer that makes this safe is formalised in written documents. Spec-Before-Code: any change touching more than 2 files requires a brief written before implementation. PR Comprehension Gate: before a pull request merges, it must answer 3-7 explicit questions (depending on project size) about what it does, what fails silently, and what the blast radius is. Trust Tiers: some agents (Tom, Nix, Jo) can merge their own work if it meets specification; others (Vera, Lena) must always pass through review because their outputs touch user-facing surfaces. Model Tiering: Sheena runs on Claude Opus where orchestration errors propagate to every downstream agent; specialists run on Sonnet or Haiku, where failures are contained.

These are specification tools. They encode the constraints that make autonomous operation safe. They are not monitoring tools. They do not observe the factory running. They define what the factory is allowed to do before it runs.

The_Specification_Problem,_Stated_Clearly

A dark factory cannot run safely against an implicit specification. Implicit specs degrade. Output drifts. Drift accumulates. A human eventually reviews something and cannot explain why it looks the way it does. This is a specification failure, not a generation failure.

Before formalised specification, my system produced three recurring failure modes:

Before EXP_006 (ADK Visualiser) entered build, Tom flagged three errors in the brief: invented node names, a topology pattern that did not match the intended architecture, and tool names too generic to constrain the agent. All three corrected before build started. The brief was wrong. The factory had not started yet, so the wrong brief cost a revision round. If EXP_006 had gone to build on the original brief, it would have built something I did not specify.

First: agents made architectural choices that were never recorded in a brief, never committed to documentation, never justified in a manifest. A caching layer appeared in a refactor. A retry policy was set in production code without context. A module boundary shifted because an agent had a good reason but did not write it down. Later, a human reviewer asked "why does this exist?" and no one could answer with confidence. The choice was probably good. But it was not specified, so it could not be trusted, so it had to be audited and re-justified after the fact.

Second: multi-file changes where the agent understood the cross-file dependency (and the brief justified it) but the reviewer only saw the diff. A change to the database schema, a corresponding change to the query layer, a test file update. These are logically connected, but in a diff view they appear as three unrelated changes. The agent understood the interdependency. The spec documented it. But the review process did not inherit that context, so the reviewer had to reconstruct it by reading code.

Third: reasoning that happened during the work but never made it into a commit message, a manifest, or a handoff. Why did the agent choose Zod for validation instead of a simpler check? Why did it set the cache TTL to 3600 seconds, not 1800 or 7200? Why did it choose async-first instead of sync with fallback? These are specification decisions. They are not self-evident from the code. They have to be captured in the specification layer or they are lost.

EXP_006 and EXP_007 share React Flow component infrastructure. The decision to share rather than duplicate is in the brief. Without the brief, the dependency exists in code but not in writing. The next agent to modify either experiment does not know the shared component is load-bearing for both - and refactors it without that context. The specification layer is not documentation after the fact. It is the instruction the factory runs against.

All three failures have the same root cause: the specification was incomplete. The agent operated against an implicit specification and produced work that was correct but not explainable. The dark factory cannot run that way. Implicit specifications do not scale to autonomous operation.

Launch_Integrity_at_Factory_Scale

Launch Integrity is the condition where every person accountable for a production launch can answer: what is shipping, to what standard, under what constraints, and what happens if it fails? This is an owned term in my vocabulary. It describes a state where accountability is clear and knowledge is encoded, not scattered.

At dark factory scale, Launch Integrity means that knowledge of constraints and standards is encoded into the specification layer. The people accountable for dark factory outputs are not the people monitoring the pipeline. They are the people who designed the constraints the pipeline runs against. That is a specification job requiring Scope Fluency - the ability to hold a change in its full context, understand its dependencies, and encode that understanding into a brief before the work begins.

When a dark factory produces an output and something is wrong, the question is not "what did the agent do?" The question is "what did the specification say?" If the agent did exactly what the specification required and the output is still wrong, the specification was wrong. This is the stakes that Launch Integrity stakes: the specification has to be right before the factory runs.

What_the_Specification_Layer_Looks_Like

A working specification layer is not theoretical. It is a specific set of artefacts and enforced practices.

Written briefs before implementation. Any change touching more than 2 files requires a brief written in advance. The brief states the task, the affected modules, the success criteria, and the constraints. No brief, no work starts. This forces specification to happen before code happens. It distributes accountability: the person writing the brief is making a specification decision, and that decision is recorded.

Behavioural contracts at module level. Each significant module (logical unit with more than one consumer) has a manifest file: manifest.yaml at the module root. The manifest exports the module's interface, states its dependencies and dependents, and crucially - documents its contracts. Contracts are behavioural expectations: rate limits, cache TTLs, retry policies, timeouts. They are not suggestions. They are the specification of what the module promises. For large projects, the manifest also documents failure modes (what happens when this module fails: trigger, impact, graceful or propagated?) and performance characteristics (expected latency, resource constraints).

Enforcement at execution boundaries. Not all agents are trusted equally. Tom, Nix, Jo operate in autonomous tier: they can merge their own work if it meets specification and passes all checks. Vera, Lena operate in always-review tier: human review is mandatory before their outputs touch production, because they write user-facing surfaces and specification errors there are customer-visible. This is not about capability. It is about blast radius. The specification layer assigns trust based on the damage a specification failure would cause.

Continuous audit against the specification. EXP_004 runs nightly. It checks all 6 repositories for stale manifests (a manifest with no update in 90 days is stale; stale specs degrade). It checks for failing CI (if the tests fail, the specification is not being met). It checks for uncommitted worktree state (code that exists but is not versioned is invisible to the factory; invisible code is unspecified code). It checks for branch hygiene violations (branches that have diverged too far from main need to be merged or discarded, not left floating). These checks have no human in the loop. The nightly audit runs automatically and fails the build if the specification is not being met.

The audit catches specification drift, not just code problems. Nix worktree sessions failed on Bash permissions across four sessions - not a tool bug, a specification gap. The worktree safety rules had not accounted for context compaction scenarios. The fix: new global spec entries before the next session. The factory flagged the gap; the spec was updated; the failure mode is documented. That is what continuous audit is for.

Who_Builds_the_Dark_Factory

Not the person who monitors outputs. Not the person who optimises the generation pipeline. The person who can hold the specification, the operational constraints, and the failure modes in the same hand - before the factory runs. That is a Launch Integrity job.

This skill is not valued in the industry yet because the industry is not running dark factories yet. When systems were less autonomous, specification was nice-to-have documentation. When systems run lights-off, specification becomes the only instruction the system receives. The person who writes that specification is the critical person. The agent running the factory is executing that specification. The monitor observing the factory output is checking that the specification was correct.

I built my system because someone (myself) wrote the specification first. Every brief, every manifest, every model assignment, every trust tier, every CI check - these are specification artefacts. They exist because Launch Integrity requires them. The dark factory is already running. The question is: who wrote the spec?