Bootstrapping the First Automated Software House

Type: kb/articles/types/article.md ยท Status: draft

A research program from human-agent production to human-free internal operation

Draft. This article may change. Comments and counterexamples are welcome on the repository's GitHub Discussions page.

TL;DR. A software house is the complete persistent system that keeps changing software for its users. This bootstrap program starts with a house that includes people and transfers bounded classes of production decisions to computation, one trial at a time. Each trial tests two things separately: whether computation now makes the decisions, and whether production evidence teaches the house to build or revise the machinery that makes them. Transferring the best-supported decisions first should leave people the hardest-to-warrant ones, and what those still need identifies the functions the house must grow.

Commonplace is the starting point: agents use and revise retained project knowledge while people still supply decisive judgments. The target is a witness house meeting the conjecture's four conditions and learning by theory refinement under the fixed-model regime.

The starting point

In a human-agent software house, agents may write and test much of the code while people diagnose shared causes, revise design assumptions, choose among passing candidates, and approve new evaluators. These are internal production roles in the conjecture article's sense: work the house depends on to evolve software, whoever performs it, as distinct from the requirements, facts, outcomes, and acceptance judgments users supply. An automated house performs every internal production role computationally. During a witness run, model weights, adapters, embedding models, parametric routers, and parametric critics all stay fixed. The conjecture's eligibility cutoff for those models is 2026-09-02; the bootstrap may use newer models before witness testing.

Two kinds of transfer

The program measures two kinds of transfer separately. Each trial declares a boundary: the decisions being assessed.

Claim What must be shown
Operational transfer Computation makes the declared production decisions, including hard cases, without human decisions. External outcomes and costs remain acceptable.
Learning transfer Production evidence causes the house to produce or revise the machinery that makes those decisions, and the retained change affects later work.

The difference shows in a simple case. A validator that a person wrote can complete operational transfer: computation now makes the decision. Learning transfer requires the house to have produced or revised the validator's criterion and machinery from its own experience. In the training article's terms, learning transfer is theory refinement turned on the house's own production path: the refined object is a check, evaluator, or procedure rather than the product.

The conjecture allows a human-built seed, provided the house applies its program theory, revises coherently, and continues reliably without human production decisions. The training article asks the further question of whether the house's own process can also produce the project-specific machinery. The bootstrap aims at both transfers.

Commonplace as a seed instance

Commonplace combines retained project knowledge, computational revision, and checks implemented in code. Notes state claims, scope, evidence, and dependencies; agents load and revise them. But governing behaviour-changing writes still depends partly on people in three ways:

These three governing decisions are part of what the bootstrap must transfer. There has been no witness run or demonstrated acquisition of program theory by computation alone.

The bootstrap program

Bounded decision classes make transfer easier to measure. A trial can focus on one class, a bundle of coupled decisions, or a broader redesign when the current division of work is itself the problem. Exploratory trials, run while people remain involved, can expose which functions the house still lacks, and their results should guide which responsibilities to transfer and how to group them. The next section names those functions.

Measure progress by counting the internal decisions people still make, not the people: one operator may stop performing one role while retaining several others. The program needs evidence of transfer without assuming a fixed order or steady progress at every step.

The readiness conditions

A transfer is ready, or warranted, when the deciding process has the premises it needs, a settled acceptance rule or grant of authority, and a check independent enough to reject a plausible harmful candidate. It also needs continuity when the decision or its evidence arrives after the current run.

If the program transfers its best-supported decisions first, people should increasingly be left with the decisions that fail one of these conditions: a missing premise, an unsettled criterion, a weak check, or a delayed consequence. The residue analysis helps identify what those remaining decisions need:

Why a decision stays human Possible response
A needed premise is unavailable Representation, retrieval, or acquisition of that premise
Acceptance lacks a settled criterion or grant of authority A usable rule or represented grant within declared limits
No independent check can reject a wrong candidate Verification, criticism with different failure modes, delayed exposure, or an accepted error tolerance
The decision arises after the automatic process stops Persistent state, scheduling, and later reactivation
Transfer is possible but too expensive Reduce its cost, change the method, or defer it

Among ready transfers, value, cost, risk, and dependencies determine what to try next. The decisions that are not ready each need a different function to grow before they can move: representation for a missing premise, interpretation for an unsettled criterion, verification for a missing check, and continuity for a decision that arrives late. Commonplace currently supplies these functions with notes, models, code, and retained evidence; a final house need not keep them in separate kinds of carrier.

A possible early trial: learning which checks a Markdown edit needs

This trial would test whether computation can decide which checks a Markdown edit needs, and whether experience improves later check selection. The training article's hypothetical release exporter provides a concrete setting: it produces a deployment manifest for an installer, and duplicate service identifiers make that manifest invalid.

A change that challenges the checking policy. Initially, the exporter reads only configuration files. Markdown edits receive syntax checks and are exempt from manifest checks. A retained dependency account relates this exemption to the build's dependencies and assumes its configured input list is exhaustive.

When the exporter starts reading service definitions from named Markdown files, the account should lead the house to extend manifest checks to those files. A further change introduces indirectly included snippets. An edit to one can pass its syntax check yet produce an invalid manifest. Revealing that failure after intervening edits would test whether the house traces the consequence to the incomplete dependency account. Later edits to other affected and unaffected files would test whether it learns more than an exception for the first failing filename.

Evidence and authority. A component trial could supply scripted exporter changes while the house inspects source, build configuration, and prior results, then revises its check selector (the procedure that chooses the checks), along with any supporting tests and the retained account. This bounded trial could begin before a complete automated house exists. Authority over the result is split: an independent manifest check, the reference judgment, can reject a claimed improvement even after the revised selector accepts the edit, and the selector being evaluated must not control that check.

Comparisons depend on the claim. Operational transfer requires useful check selection within declared outcome and cost limits, without people making the transferred decisions. Always running the full suite is the baseline: it omits no available check, so a selector must match its measured outcomes at lower total cost. The suite itself can still miss defects. Learning transfer additionally requires evidence that retained changes improve later decisions. One way to isolate that contribution is to run two copies of the house from identical product snapshots, one keeping the revised state and one with its earlier version restored, on cases the failure did not touch, while holding fixed every other place the learned information could be carried.

The trial could also support the training article's comparison of explicit project theory with raw records, a descriptive summary, and a plausible wrong theory. Changes that preserve the initial dependency account and changes that break it test different predictions: the first should favour the theory treatment, while the second may cancel or reverse that advantage until the account is revised. Record initial errors separately from recovery after feedback, because rapid recovery can hide the initial loss in a whole-run score. Targeted interventions on retained theory can help distinguish the account's contribution from that of a revised selector.

What to settle for an actual trial. Choose the workload size, feedback timing, resource limits, repetitions, and decision thresholds for the claim being tested, before using results to judge it. Report failed and incomplete runs, variation across repetitions, and the uncertainty of any treatment difference. Keep operating cost separate from reference-evaluation cost, while reporting both. Fewer checks can still cost more overall once selection and learning are included.

People may prepare the workload and provide outcome evidence. Human diagnosis or policy repair within the transferred role would defeat a claim of autonomous operation for that run, while still informing the next trial.

How each trial is specified and evaluated

The example makes explicit what every trial needs before it runs: its decision class, workload, boundary, objective, horizon, current human contributions, missing functions, separate transfer claims, and measures of outcomes, costs, interventions, and reopened roles. Retain failures and reversals as well as successes so they can inform the next transfer.

Record who made each decision, for which request, and when. A person who fixes three hard failures each month still holds the diagnosis role. Such interventions are allowed and recorded during bootstrapping. After a witness run begins, an internal human decision ends that run: the conjecture's continuation condition allows none, and the changes retained from then on no longer form an autonomous training lineage, a history of changes made while the models stay pinned and no person decides.

Transfers can reopen when a new request exceeds a rule's scope or creates a new human review role. Record the reopened responsibility and test a response: narrowing its scope, revising the machinery, or restoring human involvement. Measure change over declared windows rather than assuming each step is permanent.

Usefulness, autonomy, warrant, and power are separate dimensions, and a transfer can raise one while another falls. A self-approving evaluator, for example, raises autonomy while hiding declining quality. So state which dimension changed, and retain independent measures of later success, missed failures, and total cost.

The declared boundary also determines what a comparison can establish. A benchmark that treats the house as a worker and holds the client fixed, the party that chooses the task, writes the brief, and accepts the result, does not test the decisions it leaves with the client. Which of those decisions matter depends on their kind. Requirements and judgments about visible behaviour remain external inputs, so a client may keep supplying them. Design, diagnosis, or successor selection supplied by the client is internal production work that the bootstrap must record and transfer.

What the house's training must produce

Learning transfer, the result the house's training must produce, requires evidence that experience produces or revises the house's project-specific machinery. The seed is outgrown when learning displaces repeated human construction of project-specific knowledge as new work arises. This may show up in new theories, checks, decompositions, or evaluators, depending on what later work requires.

Not all machinery must be outgrown. General tools such as version control, a test runner, or a model client may stay fixed while their scope remains warranted. They become revision targets when new requests exceed what they can supply.

The current approach uses a proposal-selection loop: it produces candidates, evaluates them with a real chance of rejection, and makes an accepted change take effect. In that loop, admission itself can transfer in parts, from formatting and routine updates to revisions of the admission machinery. The endpoint requires all of these decisions to be computational without fixing the order in which they transfer. The loop is not the only option. Other update architectures let reward, error, gradients, or a viability filter (a change stays if the system still works) drive changes without a separate admission event. What the endpoint requires of any architecture is the same: an evidence-caused change that takes effect.

Stop or redirect conditions

Repeated failures under reported test conditions should guide what to repair, compare, or stop. Different findings challenge different parts of the approach:

  • The proposed retained account makes no causal difference. Interventions on the account still fail to change later decisions in the predicted way, even after ruling out the house rebuilding the same understanding from other records (the conjecture article's equivalent reconstruction).
  • Human production work does not decrease. Across comparable workloads, interventions persist, transferred roles repeatedly reopen, or each transfer creates equal or harder human work elsewhere.
  • Each new request class needs new human design. A person must supply a new ontology, evaluator, or decomposition as the house takes on new kinds of work.
  • Evaluation becomes self-confirming. The house's approval is the only evidence of quality, while external outcomes stop tracking it.
  • A more direct method performs better at comparable total cost. Reconstruction from raw records, direct search, or model adaptation reaches the same result more cheaply, or reaches it more reliably at comparable total cost.

These results alone do not refute the conjecture that a house can exist. They show that this approach, under the tested conditions, is not working or is not the best use of resources. The records that count as evidence for a transfer must be able to show these failures too; a history that can only confirm success is the self-confirming evaluation above.

Where this leaves the series

The conjecture supplies the witness conditions; the training proposal supplies the learning target. This program tests a route toward both by measuring changes in the production decisions and project-specific machinery supplied by people. Failed and reopened transfers determine where that route needs repair. The transition-closure supplement defines continuation reliability for a house that is already adequate; how human-agent production can lead to such a house is this article's separate question.