WOODHOUSEThe Loftwah Software Factory
Index

Founding essay · 28 September 2026 · 6 minute read

I Didn't Mean to Build a Software Factory

A practical habit of composing tools grew into a system for directing software agents, checking their work and seeing what survived in the real world.

A founder-supplied retrospective. Sequence is preserved; dates are used only where the public snapshot supports them.

An original illustration of a steward at his desk overlooking an active operations floor.
WOODHOUSE / THE STEWARD'S OFFICEA metaphor for the factory

A public account of the work

The work began with making software. It grew into a system for deciding what the software had actually proved.

The first part of the story was ordinary web work: joining useful tools together instead of rebuilding each capability. A reverse proxy, a VPS and WordPress plugins formed a practical stack. The skill that lasted was composition: knowing which piece was good at a job and how to make the pieces cooperate.

The tools changed. Plugin-shaped capability gave way to APIs, cloud services, infrastructure, models, skills and agents. Development moved from assembling a website toward operating the platform and its delivery system.

When one pair became a working system

A coding agent first changes how one person writes software. Multiple agents change the shape of the work. Requests need to become bounded tasks; people and agents need clear ownership; competing changes need review; and release evidence must be attached to the exact state being claimed.

The supplied founding account describes agents working across several products for extended stretches. At that point, writing code was no longer the only bottleneck. The operator needed to see which work had started, what had changed, what had survived review and what still needed proof.

PLATE 01

From pair programming to factory

28.09.26
From pair programming to factoryThe operator supplies intent and remains accountable while bounded work moves through agents, review, qualification and production.LOFTWAH SOFTWARE FACTORY · FROM PAIR PROGRAMMING TO FACTORYREQUESTHuman intentGoal and authorityQUEUEDurable workScope and ownerWORKERSParallel agentsBounded workREVIEWIndependent checkReview the revisionRELEASEProduction proofObserve the releaseA HANDOFF CHANGES WHO WORKS, NOT WHO OWNS THE OUTCOME.
  1. Request · Human intentGoal and authority
  2. Queue · Durable workScope and owner
  3. Workers · Parallel agentsBounded work
  4. Review · Independent checkReview the revision
  5. Release · Production proofObserve the release
The operator supplies intent and remains accountable while bounded work moves through agents, review, qualification and production.

A backlog is useful when it tells the truth

Delegation creates a new coordination problem. The task list has to show what the work means, who can act on it and which evidence closes it. Repository state and review records then provide a durable account that survives a chat ending or an agent stopping.

A green check cannot inherit authority it was never designed to provide. A build can establish that code compiled. Review can challenge a proposed change. Qualification can test a candidate. Only a live observation can support a production claim, and only the owner can decide whether the result meets the intended bar.

The system therefore needs to preserve several kinds of state instead of compressing them into a single percentage or a vague “done.”

Failures become useful when the control changes

The factory's projects expose different edges of the same problem. In Fighter, geometry checks passed while the interface still missed its visual purpose. Pirates has to account for original source rules before agents invent an expansion. MAX cannot use a browser test as evidence that a person can find the real walker. Bubbles can be functionally mature while browser and owner acceptance remain open.

These are not interchangeable bugs. Each needs its own evidence. The general pattern is to record what was expected, observe what happened, name the class of failure and put a control where it can catch the same mistake again.

PLATE 02

The failure loop

28.09.26
The failure loopA lesson only becomes a factory control when it changes how later work is reviewed or qualified.LOFTWAH SOFTWARE FACTORY · THE FAILURE LOOPBELIEFState the modelRecord the expectationATTEMPTMake the changeImplement against the modelREALITYObserve the resultCheck the real behaviourINCIDENTName the missIdentify what escapedCONTROLChange the systemPrevent repeat failuresTHE CONTROL TRAVELS WITH THE LESSON
  1. Belief · State the modelRecord the expectation
  2. Attempt · Make the changeImplement against the model
  3. Reality · Observe the resultCheck the real behaviour
  4. Incident · Name the missIdentify what escaped
  5. Control · Change the systemPrevent repeat failures
A lesson only becomes a factory control when it changes how later work is reviewed or qualified.

Trust is a ladder, not a label

The operating model separates what was observed from what was implemented, merged, qualified, verified in production and accepted by the owner. A project may have strong evidence at one rung and an open question on another.

PLATE 03

The evidence ladder

28.09.26
The evidence ladderEach step is a new claim. A result lower on the ladder does not automatically establish the steps above it.LOFTWAH SOFTWARE FACTORY · THE EVIDENCE LADDEROBSERVEDA source or behaviour was inspectedEvidence has a place and a time01IMPLEMENTEDThe requested change existsThe code or product state changed02MERGEDThe reviewed change entered its branchThe integrated revision is identifiable03QUALIFIEDRequired checks passed on the candidateThe named release gates were satisfied04PRODUCTION VERIFIEDThe deployed version was observedThe live system matched the claim05OWNER ACCEPTEDThe result met its intended barThe accountable human confirmed it06NOT EVERY OUTCOME REACHES EVERY STATE
  1. Observed · A source or behaviour was inspectedEvidence has a place and a time
  2. Implemented · The requested change existsThe code or product state changed
  3. Merged · The reviewed change entered its branchThe integrated revision is identifiable
  4. Qualified · Required checks passed on the candidateThe named release gates were satisfied
  5. Production verified · The deployed version was observedThe live system matched the claim
  6. Owner accepted · The result met its intended barThe accountable human confirmed it
Each step is a new claim. A result lower on the ladder does not automatically establish the steps above it.

Why Woodhouse exists

Once the factory had several active products, a public record became another useful system: a place to see what each project is for, what its reviewed status means and which evidence is still missing. Woodhouse is designed for people and for agents that need a machine-readable account with clear limits.

This first release is a dated, operator-supplied portfolio snapshot. It does not connect to private repositories, stream GitHub activity or publish working conversations. Agent Reception is read-only. Those boundaries keep the public record useful without pretending it is live telemetry.

Source and chronology

This article paraphrases the founder's supplied professional account and uses current project examples from the shareable factory report dated 28 September 2026. The account gives a sequence of changes rather than a fully dated timeline; dates and direct conversation quotations have been omitted where they are not part of the public record.

See how the projects currently stand, or read the factory doctrine that governs their evidence.

Record boundary

Some source repositories are private. This publication does not reproduce raw issue text or private conversation transcripts.

Back to the dispatches