Software Factory
A software factory is a programmable production system for a decision factory.
The decision factory names the valuable output: a consequential choice that changes what happens next. The software factory makes the path to that choice explicit, routable, observable, and easier to improve. Its product is not code volume, documents, meetings, or AI answers. Its product is a better decision with an owner, a reason, an action, an outcome, and a reusable trace.
PROBLEM → QUESTION → DECISION → ROUTE → ACTION → RECEIPT → LEARNING
↑ |
└──────────────────── next valuable problem ────────────────────┘
This is a reusable inference from the lived telco routing system, not a claim that every organisation already operates this way or that software automatically improves judgment.
Why Build One?
Most knowledge-work systems optimise work in process: tickets closed, documents produced, meetings held, code shipped, or model tokens consumed. Those measures can rise while the important decision remains late, ownerless, unsupported, or unchanged.
A factory begins with its output and designs backward. For knowledge work, that means naming the decision before commissioning the analysis.
| Activity system asks | Decision factory asks |
|---|---|
| What work should everyone do? | What exact choice must be made? |
| Which department owns the task? | Which decision owner and capabilities does this need? |
| How quickly did we produce the deliverable? | Did the decision arrive in time and change the outcome? |
| Can AI automate this workflow? | Which parts are understood enough to encode safely? |
| Did the project finish? | What receipt, variance, and reusable lesson did it leave? |
The commercial case is throughput with memory. The human case is better allocation of scarce attention. Encode repeatable work so judgment can move to the next mystery; retain the evidence so the next decision begins from earned knowledge rather than organisational amnesia.
The Production Line
| Station | Product question | Public instrument |
|---|---|---|
| Problem | What valuable gap deserves attention? | Problems |
| Question | What must become clearer before choosing? | Questioning System |
| Decision | What exact choice, owner, deadline, and proof signal exist? | Decisions |
| Route | Which human, agent, tool, data, approval, and sequence fit? | Essential Algorithm |
| Action | What is the smallest bounded move that can change reality? | Plans |
| Receipt | What did the beneficiary and independent evidence observe? | MEV Benchmark |
| Learning | What should be retained, challenged, encoded, or retired? | Decision Journal |
Software connects these stations. It preserves identity across handoffs, blocks action when a required contract is missing, routes capability to the decision, captures the result, and returns the lesson to the next problem. AI can help at every station, but it does not own the beneficiary's values or the accountable human's authority.
When the factory crosses into a customer's live environment, a Forward Deployed Engineer carries the human boundary: co-discover the real problem, co-build the production change, prove and transfer the capability, then return only authorised reusable learning to the platform.
The Decision Contract
Before broad analysis or automation begins, specify:
| Field | Question |
|---|---|
| Problem | What observed gap makes this decision necessary? |
| Decision | What exact choice will exist when the work is done? |
| Owner | Who has authority and accountability to make it? |
| Beneficiary | Whose reality should improve? |
| Inputs | What must be known, and what is merely interesting? |
| Constraints | Which values, approvals, boundaries, or prior commitments must hold? |
| Options | What credible routes, including doing nothing, remain open? |
| Capabilities | Which humans, agents, tools, and relationships are needed, and when? |
| Deadline | When does more analysis cease to be worth its cost? |
| Gauge | What frozen signal will judge the outcome without moving the standard? |
| Kill signal | What evidence should stop or reverse the route? |
| Learning | What reusable heuristic should remain after review? |
Do not automate a process until you can name the decision it serves. Otherwise the factory makes ambiguity faster.
Route Judgment, Not Just Tasks
Classify the work before deciding what software should do:
| Knowledge state | Nature of the work | Factory treatment |
|---|---|---|
| Mystery | The problem or relevant questions are not yet clear | Protect human exploration; use software to expose context and dissent |
| Heuristic | A guiding rule exists but context still matters | Assist judgment; show precedent, alternatives, uncertainty, and limits |
| Algorithm | The rule is explicit and repeatable enough to test | Encode, observe, and delegate within declared thresholds |
The strategic loop is:
solve a mystery
→ earn a heuristic
→ test and encode an algorithm
→ release attention
→ reinvest it in the next mystery
A software factory should move understood work down this funnel without forcing uncertain work to pretend it is understood. The failure mode is loving the algorithm: optimising an aging answer while customer reality has already changed the question.
Telco Is the Precedent
A telco routing system already behaved like a factory. An intent entered. Reference data and constraints narrowed the routes. Capacity and quality thresholds selected a carrier. Settlement recorded the commercial result. Performance data returned to the next routing cycle.
The same architecture can route a knowledge decision:
| Telco routing | Decision production |
|---|---|
| Call intent | Valuable problem and exact decision |
| Destination reference data | Context, beliefs, constraints, and authority |
| Carrier routing table | Available humans, agents, tools, and workflows |
| Capacity and QoS gates | Allocation, standards, approvals, and kill signals |
| Call detail record | Decision trace and action receipt |
| Quality and margin review | Outcome variance, beneficiary evidence, and learned rule |
That analogy is the reason to build—not proof that the new system works. The telecom case demonstrates routing discipline. A software factory for decisions still needs forward-tested evidence that it improves decision lead time, outcome quality, agency, or learning.
Govern It With MEV
The factory needs a setpoint or it will optimise whatever is easiest to count. Use Maximum Enablement Value: maximise enabled worthwhile value without allowing throughput to hide lost agency, preventable harm, extraction, or false claims.
Measure the factory at three levels:
| Level | Useful signals |
|---|---|
| Flow | Contract completeness, decision lead time, late constraints, approval rework |
| Outcome | Frozen gauge met, beneficiary receipt, causal claim supported or falsified |
| Learning | Heuristic reused and tested, algorithm promoted or retired, next mystery funded |
Faster tasks are not sufficient evidence of better decision productivity. More decisions are not necessarily better either. The aim is the smallest number of timely decisions that enable the most worthwhile change.
Minimum Viable Factory
Start with one recurring decision, not an enterprise platform.
- Name its owner, beneficiary, deadline, options, constraints, Gauge, and kill signal.
- Draw the current route across people, data, tools, approvals, and handoffs.
- Find one repeated algorithmic step and one point where human judgment must remain explicit.
- Connect the artifacts with a stable identifier so context survives every handoff.
- Run three to five decisions without silently changing the Gauge.
- Compare lead time, rework, outcome evidence, agency, and retained learning with the prior route.
- Encode only the rule that survived review; reinvest released attention in the next mystery.
Expand only when an independent or beneficiary receipt shows a meaningful improvement. A deployed workflow proves build capability, not customer value.
Failure Modes
- Software factory as code factory — shipping components becomes the output again.
- Decision theatre — the contract is filled in after the choice to justify it.
- Automated authority — a model makes a consequential value judgment nobody explicitly delegated.
- Moving Gauge — new information silently lowers the success standard during execution.
- Modal strategy — AI's conventional answer is accepted as distinctive contextual judgment.
- Trace inventory — lessons accumulate but no later decision cites or tests them.
- Efficiency extraction — automation savings disappear instead of funding the next mystery.
- Factory totalism — every conversation is forced into a workflow, destroying useful exploration.
Context
- Telco MEV Algorithm — lived routing precedent and the bridge from routes to decisions.
- Forward Deployed Engineer — the accountable human interface between the factory and customer reality.
- Essential Algorithms — the universal
INTENT → ROUTE → INFRASTRUCTURE → SETTLE → FEEDBACKpattern. - Problems — choose the valuable gap before producing a decision.
- Questioning System — make uncertainty and possibility explicit.
- Decisions — the public decision protocol.
- Decision Journal — retain prediction, reason, result, and review.
- MEV Benchmark — non-compensatory enablement gates and outcome evidence.
- Golden MEV Journey — run the setpoint from dream through receipt.
Questions
Which recurring decision currently consumes the most attention without leaving reusable intelligence?
- What decision does your busiest workflow actually serve?
- Which step is a mystery, which is a heuristic, and which has genuinely become an algorithm?
- Where does judgment need better context rather than automation?
- What beneficiary receipt would justify expanding your minimum viable factory?