Software Factory

When is a software factory actually closed?

Only when shipped work teaches the next decision.

Code, agents, tests, and deployment pipelines can increase output without improving anything a beneficiary values. A complete factory begins with a worthwhile consequence, carries it through bounded execution, and returns evidence that changes what the system does next.

SIGNAL → DECISION → CONTRACT → EXECUTE → VERIFY → RELEASE
   ↑                                                ↓
   └──── changed control ← LEARN ← APPRECIATE ← CONSEQUENCE

This is a method for designing and testing such a system. It is not a claim that automation owns human judgment or that every workflow needs agents.

The Closure Test

Trace one completed unit of work through these seven questions:

Station	Question	Required evidence
Signal	What observed problem or opportunity deserves attention?	Source, intended beneficiary, and current state
Decision	What exact choice must a named owner make?	Options, constraints, authority, and rejection reason
Contract	What consequence, proof, horizon, and stop condition are frozen?	Executable criteria plus an outcome Gauge
Execute	What is the smallest reversible action?	Bounded route, budget, permissions, and rollback
Verify	Did the change satisfy its contract?	Fast checks that can reject known-bad output
Appreciate	Did the beneficiary experience the intended difference?	worked, partial, failed, or no-signal, with rationale
Learn	What changes in the next route?	A control, criterion, precedent, or autonomy boundary updated or retired

If a link is missing, the factory is open at that point. Do not hide the gap with more agents, a stronger model, or a larger context window.

Two Proof Loops

Use two proof loops:

1. Execution proof: Did the work meet its specification and safety constraints?
2. Outcome proof: Did the released change improve the beneficiary state it was meant to change?

Keep them separate. A green test suite cannot prove that the right feature was chosen. Positive telemetry cannot prove that the implementation is correct. The work is an executed hypothesis until its consequence is due and judged.

The verifier must also be tested. Seed a known-bad output and confirm that the check fails for the right reason. When risk matters, separate creator and verifier context so the worker cannot weaken its own proof.

Human Authority

AI can gather signals, draft contracts, execute bounded work, run checks, and summarise evidence. It does not inherit authority over values, risk acceptance, or the beneficiary's verdict.

A human remains accountable for:

• choosing which consequence is worthwhile;
• accepting conflicts, irreversible risk, and exceptions;
• judging taste, strategy, and ambiguous beneficiary evidence; and
• deciding which lesson becomes a reusable rule.

Software should preserve that authority across handoffs. When work enters a customer environment, a Forward Deployed Engineer also owns the trust boundary, capability transfer, and authorised return of learning.

Earn Autonomy

Autonomy is not a global maturity level. Grant it to a recurring class of work only when:

• the desired outcome and executable criteria are stable;
• the action has bounded blast radius and a tested rollback;
• an independent verifier rejects representative bad outputs;
• retries, time, tokens, and money have hard ceilings;
• side effects are safe to replay or deduplicated; and
• observed consequences remain inside a declared loss budget.

Start with low-risk, reversible, familiar, measurable work. Expand the boundary only after repeated receipts. Contract it after an escaped defect, authority violation, untraceable action, or material disagreement between proxy telemetry and beneficiary judgment.

Start Small

Choose one recurring decision, not an enterprise platform.

1. Freeze its owner, beneficiary, intended consequence, Gauge, review horizon, and kill signal.
2. Draw the route across people, agents, data, tools, approvals, and handoffs.
3. Mark each step as a mystery, heuristic, or algorithm.
4. Protect mysteries for human exploration, assist heuristics with context, and automate only algorithms that can be tested.
5. Challenge the verifier with known-bad output.
6. Run three to five real cycles and capture beneficiary verdicts.
7. Encode only the rule that survived review.

Judge progress by accepted consequences per unit of time, money, and human attention—not by code volume, agent count, benchmark score, or model price.

Failure Modes

• Code factory — shipped components become the output.
• Signal bypass — a prompt becomes a diff before anyone chooses the worthwhile consequence.
• Self-authored proof — the worker writes or weakens the test that judges its own work.
• Green but unwanted — local correctness automates the wrong priority.
• Proxy success — telemetry rises while the beneficiary reports no value.
• Trace inventory — receipts accumulate but never alter a later decision.
• Benchmark fossil — a saturated measure continues to govern the system.
• Prestige routing — an expensive model substitutes for a better harness, clearer contract, or faster feedback.
• Factory totalism — uncertain work is forced into a workflow before it is understood.

Proof

Select one recently shipped change and ask a cold reviewer to reconstruct:

beneficiary → intended consequence → decision owner → execution contract
→ independent proof → released outcome → verdict → changed next control

The factory is not closed if the reviewer must infer an edge, if the verifier accepts a seeded defect, or if the outcome leaves the next decision unchanged.

Context

• depends-on Decisions — name the consequential choice and its owner before commissioning work.
• applies-to Essential Algorithm — route intent through infrastructure, settlement, and feedback.
• proved-by Commissioning — distinguish a working implementation from an accepted capability.
• risk-governed-by MEV Benchmark — stop throughput from hiding lost agency, harm, or false value.
• pairs-with Forward Deployed Engineer — carry the factory into customer reality without leaking authority or knowledge.
• depends-on Problems and Questioning System — find the worthwhile gap before making its route efficient.
• applies-to Plans and the Decision Journal — carry intent into action and retain the result.
• proved-by Telco MEV Algorithm — a lived routing precedent, not proof of every factory claim.
• pairs-with Golden MEV Journey — run the wider setpoint, action, receipt, and learning route.

Questions

Where does your current software flow stop returning evidence?

• Can its verifier reject a representative bad result?
• Who judges the consequence when telemetry and human experience disagree?
• Which later decision has changed because of a completed work receipt?
• What evidence would expand—or contract—the autonomy boundary?

Changes my mind: Repeated evidence that this method adds ceremony without improving decision quality, beneficiary outcomes, recovery, or safe autonomy.

Next question: Which missing edge can you restore in one real work cycle?