The factory's empty seams are solved scheduling problems

Technical report, 2026-07-10 (revised 2026-07-12). Companion essay: The software factory as an observatory. The literature review here surveys the operations-research literature in the NASA (National Aeronautics and Space Administration) Astrophysics Data System (ADS) corpus, with every source linked to its ADS record.

The entire pool-dispatch policy of Gas City, an agent-fleet orchestrator, is one shell line: fetch ready work routed to a given worker pool, drop the blocked and ineligible rows, take the oldest that survives (workquery.go:127-134, the tier-3 ordering predicate inside a three-tier discovery contract whose earlier tiers handle crash recovery and pre-assigned work). First come, first served (FCFS), with ordering delegated to whatever the query returns. The autoscaler is one line too: desired sessions equals ready-queue length, clamped to a minimum and maximum defined by the autoscaling configuration. Model selection is a static string in a per-agent config file. There is no lookahead, no load balancing across pool instances, no cost model, and no deadline field anywhere in the work-item data structure.

Nearly everything written about software factories is about the quality of the workers: smarter coding models, longer memories, better per-agent planning. The shell line above gets no essays, and it decides more, because it chooses what the fleet touches, in what order, at what tier, and at whose expense, and it makes those choices with less machinery than a thermostat. The position of this report is that a software factory is an online scheduling and resource-allocation system operating under uncertainty, that code generation is one operator inside that optimization loop, and that the loop, not the operator, is where the unsolved engineering lives. The place to see the loop already running in production is a mountaintop.

At 20:47 on Palomar Mountain, the marine layer starts climbing the ridge, and a computer in the dome of the 48-inch Samuel Oschin Telescope throws away its plan for the night. Nobody is alarmed. The Zwicky Transient Facility (ZTF) loses pieces of its plan most nights, to clouds, to seeing (atmospheric blur), to a target-of-opportunity alert from a gravitational-wave detector. The scheduler was built for exactly this: it chops the night into thirty-minute blocks, assigns work to blocks by solving an integer program, an exact optimization over yes-or-no assignments, that maximizes how much sky gets searched per unit time, then inside each block solves a traveling-salesman tour so the telescope wastes as little time as possible slewing (repointing) between targets (2019PASP..131f8003B, 340 citations, still in production). When the clouds come, it re-solves. It has been doing this since 2018, on a problem with the same shape as agent-fleet dispatch: hundreds of tasks with priorities, time windows, precedence, sequence-dependent switching costs, shared serial resources, fairness constraints across competing programs, and an environment that invalidates the plan several times a night.

We keep calling the software systems agent orchestrators. Functionally they are online schedulers, and astronomy has been fielding online schedulers, under harsher constraints and with better bookkeeping, for thirty-five years. The claim of this report: the seams Gas City deliberately left empty, the constants Gas City Packs, its reusable-configuration layer, currently fills with hand-tuned values, and the threshold predicates Agent-Oriented Architecture (AOA), a code-architecture measurement toolkit, uses as gates are, one for one, the slots of that optimization loop, and each slot has a deployed, published mechanism behind it. The corpus survey found zero papers applying any of it to continuous-integration (CI) systems, merge queues, or agent fleets. The transfer is untraveled, the mechanisms are fielded and published in astronomy, and the insertion points already exist as configuration seams that require no Go edits until late in the adoption path.

The observatory mapping is a working dictionary

An observatory is a factory whose raw material is photons and whose product is measurements. It has a backlog of approved observation requests, each with a scientific priority, each waiting for its moment; it has agents, telescopes and instruments, some interchangeable and some specialized, each with a cost to start up and a cost to switch tasks; it has a review committee upstream deciding what deserves time, an unreliable environment that fails jobs through no fault of the work, and, in many facilities, one shared serial resource everybody’s output must eventually pass through. The companion essay develops the scene. The correspondence has to be exact, because the argument leans on it at every seam.

Observatory	Software factory
Telescope with an instrument mounted	Execution agent: one worker session
The sky	The codebase
Observation queue	Work-item backlog
Time-allocation committee	Whoever decides what deserves agent time
Clouds rolling in	Requirements changing under running work
Seeing (atmospheric blur)	Context quality
Slew time between targets	Context switching between tasks
Dark hours, renewed daily, unbankable	Wall-clock compute and token budget
Instrument availability	Tool and environment availability
Weather losing an exposure	A flaky test failing a run the work did not deserve
Target-of-opportunity alert	Customer incident, escalation, interrupt
The one instrument all data must pass through	Human review bandwidth
Night scheduler	The factory optimizer, which mostly does not exist

A dictionary earns its keep when it answers questions it was not built for. Adaptive optics measures atmospheric distortion hundreds of times a second and deforms the mirror to cancel it, an instrument-side correction that restores image quality without touching the schedule; the factory analog is mid-session context repair, compaction and re-retrieval that restores a degrading context window without rescheduling the task, and current agent orchestrators do not treat it as a first-class subsystem. An exposure-time calculator predicts how long an observation needs before the committee commits telescope time; its analog is a per-class, per-tier cost model consulted before dispatch, which is the estimate the tier router maintains and updates from outcomes. Ask the dictionary a new question and it answers; that is the test a metaphor has to pass to be worth building a framework on.

Execution, planning, and optimization are three different jobs

An observatory separates its systems by name: the telescope control system points and tracks, the observation planning tools turn a science case into schedulable requests, and the scheduler decides what happens tonight. The software-factory world runs all three concerns through the one word “agent,” and the conflation hides where the gaps are.

The execution level is a single agent doing a task: a session with a claimed work item, a worktree, a model, a tool budget. The planning level decomposes goals into tasks and orderings; in Gas City this is the formula layer, and the fleet flows (diverge, converge, premortem, stress-test) are planner-level compositions, decisions about how many attempts to run and how to merge them. The optimization level allocates scarce shared resources across everything in flight at once: claim order, pool sizes, model tiers, merge slots, interrupt policy, review bandwidth. Distributed-systems readers can read the hierarchy as data plane, control plane, and the resource manager above both; operations-research readers can read it as job execution, project planning, and the scheduling problem proper.

The field’s attention is stacked almost entirely at the bottom. Execution agents are a crowded, well-funded research area, planning harnesses an active one, and the optimization level, in this factory, is the FCFS line this report opened with, a one-line autoscaler, and a static model string in a config file. When a factory disappoints, though, the failure is rarely that an agent could not produce a diff: the wrong item ran first, two sessions collided in one file set, a dependency chain serialized a week of work, an interrupt drained the pool, or six finished changes sat a day waiting for one human reviewer. Every one of those is an allocation failure, and no amount of worker intelligence repairs an allocation failure.

The whole factory is one control loop

Strip the domain words away and both of the great survey telescopes run the same block diagram: goals in, a planner turning goals into schedulable units, a scheduler assigning units to instruments under budgets, execution, telemetry back from the instruments and the sky, state estimation turning telemetry into what is true now and how confidently it is known, and a replanning rule deciding when the current schedule is stale enough to discard.

The factory exposes a slot for every box, though several sit empty. Goals are epics and roadmaps; the planner is the formula layer; the scheduler is dispatch plus capacity plus tier routing; execution agents produce diffs; telemetry is the event bus and the audit ledgers. State estimation, the middle box, is the one the factory has the raw data for but does not yet compute: per-class duration and success distributions, queue state, in-flight session state, all latent in the ledgers, none currently estimated. Replanning fires the way ZTF’s does, on a state change from the environment (clouds there, queue events here). Drawing it as a loop promotes four things agent frameworks treat as incidental to first-class components: the objective the scheduler maximizes, the state estimate, the uncertainty attached to that estimate, and the replan trigger. A framework with no explicit slot for the four is an open-loop generator with a queue in front of it, not a smaller version of this architecture.

The observatories disagree about where to close the loop, and the disagreement is the most useful result in the survey. The Zwicky Transient Facility is the planning monastery: a deterministic integer program solved fresh whenever conditions change, the whole night laid out block by block, provably good against its objective. Rubin Observatory’s Legacy Survey of Space and Time (LSST) proposes the opposite: a scheduler framework built around a memoryless feature-based policy that scores every candidate as a weighted sum of handcrafted features and re-decides at every step, absorbing weather loss for free because any state is a valid restart point (2019AJ....157..151N describes that framework). Read across the survey, the comparative record leans the same way: the deployed systems that faced the most quantifiable uncertainty chose deterministic re-solve or memoryless policies over scenario-tree stochastic planning (optimizing against an explicit branching tree of possible futures), which appears in this literature only as a 2025 preprint (2025arXiv250403666R). Seen clearly, neither monastery is really a planner; both are closed-loop controllers that watch the sky, decide the next thing, and watch again, one closing the loop at the block boundary and the other after every exposure. The architecture either one settles on is a plausible template for an agent fleet once it stops treating a plan as a commitment and starts treating it as the current output of a control loop over live state. Across these deployments cheap re-decision on current state outperformed explicit uncertainty modeling. The upgrade a software factory should chase is a better-informed re-decision; a stochastic planner is not where the leverage sits.

What the optimizer is actually optimizing

The factory runs two optimization mechanisms at different stages, and keeping them apart resolves what otherwise reads as a contradiction. The scheduler optimizes an objective over an epoch. The acceptance gate, a later stage, judges finished candidates on a vector without collapsing it. This section is about the first; the acceptance section is about the second.

Written down, the scheduler’s objective is short. Over an epoch, choose the assignments, orderings, tiers, pool sizes, and preemption holds that maximize the expected value of work that merges and survives, minus everything the schedule itself costs: token and compute spend at the chosen tiers, human attention consumed as review load and interruptions, coordination losses from context switches and merge-conflict rework, and a fairness penalty for the programs the schedule starves. The constraints are the factory’s physical facts: seats per pool, one merge-integration slot, CI runner count, a daily token budget that renews and cannot be banked, and the review bandwidth of the humans in the loop, the shared serial instrument from the dictionary above.

Every term is measurable from telemetry this factory already records. Value enters today as declared priority, and should eventually enter as something better calibrated. The merge-and-survive probability per task class and tier is what replayed traces measure and what a router’s posterior estimate (its running belief, updated from each outcome) approximates online. Token spend per invocation already comes out of the pricing module. Review latency and interruptions sit in the audit ledgers. Context-switch cost is observable as the spin-up tax between a session’s start and its first useful action. Fairness has a worked formulation in the scheduling model of the Deep Space Network (DSN), NASA’s shared antenna array for deep-space missions, discussed below, where a schedule that starves a small program pays for it in the objective, visibly.

One discipline from the survey applies to the coefficients that weight these terms: treat every coefficient as versioned policy, because in the one published head-to-head where a genetic algorithm and a tuned local search tied, the scientific policy encoded in the fitness function decided the outcome (2003A&A...403..357G), so the weights get reviewed and diffed like code. What Gas City runs today is this objective with almost every term deleted: value collapsed to arrival order, costs unpriced, fairness unstated, the constraint set a hand-tuned list of constants. The seam sections that follow reinstate the terms one at a time.

The toolkit has had a name for fifty years

Every mechanism this report borrows has a standing name in operations research (OR), and reciting the names matters because the names are search keys into a literature that already did the work. The claim-ordering problem is online scheduling, committing to decisions before future arrivals are known. The work-item dependency graph is job-shop scheduling, the classic problem of ordering jobs across shared machines, generalized to the resource-constrained project scheduling problem (RCPSP); model tiers are the multi-mode variant’s modes, and duration blowups are the territory of stochastic and robust optimization, hedging against modeled randomness or bounded worst cases, with budgeted uncertainty guarding the makespan, the schedule’s total length (2022arXiv220306983B). Sequence-dependent switching cost, the warm-worktree and loaded-context tax, is the routing structure at the heart of dynamic vehicle routing, re-planning a fleet’s tours as new stops arrive, and the observatories literally solve tours: ZTF runs a traveling-salesman solve inside every block (2019PASP..131f8003B) and Handley named the sequencing version the Traveling Telescope Problem (2024AJ....167...33H). Re-solving each epoch with in-flight work frozen is receding-horizon optimization, optimizing over a rolling future window and committing only the first step, known as model predictive control (MPC) when an explicit model of the controlled system is available, and the MIPcc23 reoptimization competition (a benchmark series scoring re-solves of a fixed model under perturbed data) defines and scores that regime (2023arXiv231114834B). Hard time caps with shipped schedules are the mark of anytime algorithms, stoppable at any moment while returning the best solution found so far (2022ApJ...935...87P). Tier choice under a token budget belongs to the multi-armed bandit family of sequential decisions, where every pull both earns reward and reveals information: the general theory in Slivkins (2019arXiv190407272S), the budget-constrained variant in Cayci et al. (2020arXiv200300365C). Both are scored by regret, the gap between what a policy earned and what the best fixed choice in hindsight would have, whose general theory for online decision-making Hazan’s online-convex-optimization treatment lays out with its comparator assumptions spelled out (2019arXiv190905207H); the central trade the bandit names is exploration versus exploitation, spending on uncertain options versus repeating known-good ones. Fair division and resource allocation close the list, fielded as coefficients in the DSN’s scheduling objective (2021arXiv211111628C).

The observatory papers matter to this report because they are what those names look like fielded: not the theory but the operational residue, time caps chosen, optimality gaps tolerated, stability scored, fairness coefficients validated against a real week of operations. Observatories are only physical instances of what operations research has worked on for the better part of a century, and almost none of that work has been within arm’s reach of the people building orchestrators. The astronomers reached for it because a night is finite and expensive and they had no other option; a software factory has the same structure and, so far, less of an excuse. The right reading list for someone building a software factory is the same thirty-five years of scheduling papers the astronomers already read.

Literature review

The corpus and how it was surveyed

The evidence base is a survey of NASA’s Science Explorer (SciX), the discovery interface built on ADS, run as six parallel research agents, one per operations-research facet: linear and mixed-integer programming, network optimization, stochastic and dynamic programming, nonlinear programming with duality and optimality theory, modeling languages and solvers, and metaheuristics with search-based software engineering. The agents made roughly 195 corpus tool calls in total and anchored every finding to a bibcode, ADS’s persistent record identifier. The question was narrow: what does the optimization literature in this corpus teach about running an automated software factory, meaning a fleet of coding agents plus the deterministic systems that manage a codebase and its architecture?

Thirty-five years of observatory scheduling

The corpus’s production optimization domain is observatory and spacecraft scheduling, and it is structurally the same problem as agent-fleet dispatch. The arc runs from SPIKE’s constraint satisfaction for the Hubble Space Telescope (1990aisi.conf....5J) through the first production integer linear program (ILP) telescope-network scheduler at Las Cumbres Observatory, a globally distributed network of robotic telescopes (2015arXiv150307170L), ZTF’s ILP (2019PASP..131f8003B, 340 citations, in production since 2018), and the 2021 to 2025 wave of mixed-integer programs, models mixing whole-number and continuous decisions: the DSN scheduling antenna time with setup and teardown brackets and cross-mission fairness terms (2021arXiv211111628C), the Atacama Large Millimeter/submillimeter Array (ALMA) re-solving 5,000 to 10,000 scheduling blocks to optimality under dynamic conditions (2016A&C....15...90S), ZTF target-of-opportunity handling (2022ApJ...935...87P), and the UVEX ultraviolet space telescope and M4OPT multi-mission scheduling framework (2025PASP..137g4501S). Taken together, these systems demonstrate the union of constraints a factory scheduler needs, no single one carrying all of them: priorities, time windows, precedence, sequence-dependent switching costs, shared serial resources, fairness across competing programs, an environment that invalidates the plan without warning (weather, which plays the role that agent nondeterminism plays for a software fleet), and continuous replanning. Every element of the factory-scheduling problem has a deployed, published treatment somewhere in this literature.

What a decade of operations settled

The survey’s most transferable results are negative and comparative, the kind worth having before a line of code is written. The first is the two-monasteries result already stated above as the control loop’s closure rule: across these deployments cheap re-decision outperformed scenario-tree stochastic planning. Two more constrain any build. Bold and Goerigk’s compact robust resource-constrained project-scheduling formulation solves 93.1% of benchmark instances to proven optimality against 65.0% for an improved Benders decomposition, the classical split of a large model into a master problem and subproblems, at 100 to 200 times the speed (2022arXiv220306983B); price-based Lagrangian decomposition, which coordinates subproblems through prices (2022NatSR..1222417B), only pays off at genuinely large separable scale. Those results support a working hypothesis, to be checked on the real formulation rather than assumed: a work queue of 100 to 10,000 items, at the modeling density this report proposes, should fit in one open-source solver process. And the production target-of-opportunity schedulers run anytime, taking a hard time limit, shipping the incumbent (the best solution in hand when the clock stops), and treating the optimality proof as a luxury. The ZTF target-of-opportunity scheduler MUSHROOMS caps at 500 seconds and accepts 2 to 11% optimality gaps (the proven distance from optimal) where proofs do not close (2022ApJ...935...87P). The plan will be stale before the proof lands; these schedulers stopped paying for proofs years ago.

Two results push toward a vector objective at the gate. Chen, Li, and Yao showed, on their search-based-software-engineering benchmarks, a weighted-sum genetic algorithm converging to points that Pareto search (the frontier of mutually non-dominated candidates) dominates (2020arXiv200108236C), and Dunbar showed even dual bounds for multi-objective integer programs must be bound sets rather than scalars (2023arXiv230908801D). Read together they argue that any single “architecture health score” risks repeating a documented failure, which is the reasoning behind this report’s dominance-based acceptance rule rather than a proof that scalars always lose. And Goodhart’s law, the metric gamed as soon as it becomes the target, is documented here with its fix attached: at the payments company Adyen, across 5.5M lines of code, search operators learned to game the modularity metric monotonically by moving single classes into fresh modules, metric improvement did not predict developer acceptance, and human review had to be the real gate (2021arXiv210200701S). Deterministic metric gates select candidates; an independent judge that was not the optimization target accepts them.

A reference architecture the deployed systems imply

Read together, the deployed systems imply a four-layer architecture, each layer grounded in a system from the survey. The four layers are the three levels drawn earlier at finer grain: the declarative constraint core and the epoch scheduler are the optimization level, the dispatch policy is the seam where optimization hands off to execution, and the mutation-selection loop is execution and planning fused around a gate. It is the same hierarchy, not a competing one.

The first layer is a declarative constraint core, the algebraic-modeling-language pattern, an optimization model written declaratively and kept separate from the data it runs on, that Pyomo in Python (2009orci.book....3H) and JuMP in Julia (2015arXiv150801982D) exist to provide, with a solver-agnostic intermediate representation between model and solver (2020arXiv200203447L). Rules and scheduling policy live in a declarative model; queue and repository state is the data instance; agents regenerate the data every cycle and touch the model rarely. MCP-Solver (2025arXiv250100539S), a constraint-solving server a language model drives through an editing protocol, shows the write path working: the model edits a MiniZinc model, MiniZinc being a solver-independent constraint-modeling language, item by item, every edit validated before acceptance, solve strictly separated from edit, model state held server-side. On infeasibility, solvers that support it can emit an irreducible infeasible subsystem, an inclusion-minimal set of constraints that cannot all hold at once, meaning dropping any one restores feasibility, though it need not be the smallest such set; the agent’s job then reduces to proposing which rule to relax. Solver logs of bounds, gaps, and timing are the audit trail a model’s judgment cannot provide: reproducible and appealable.

The second layer is epoch scheduling by a compact anytime mixed-integer program, warm-started (seeded with the previous solve so the solver starts near the answer): re-solve when accumulated state changes trip a cooldown-coalesced controller, accept the incumbent under a hard time limit, freeze in-flight agent sessions as fixed constraints the way ALMA treats a scheduling block as atomic. The reoptimization regime is literally “same formulation, perturbed data every tick,” which MIPcc23 (2023arXiv231114834B) defines and scores with schedule stability as a first-class quantity rather than a hope. Several observatory formulation pieces lift over with almost no translation; the epoch-scheduling section below itemizes them with their sources.

The third layer is dispatch between epochs by a memoryless feature policy. Naghib’s LSST scheduler (2019AJ....157..151N) scores each ready task as a weighted sum of handcrafted features (age, expected cost, retry count, dependency criticality, historical success by task-type and tier) and tunes the weights by black-box optimization (tuning against outcomes without a gradient) over replayed traces. Any state is a valid restart point, so the same memorylessness that made the policy robust to weather loss makes it robust to agent crashes. Deadline-sensitive queues get a Whittle index, a single near-optimal priority scalar per task trading urgency against completion probability (2016arXiv161000399Y).

The fourth layer treats agents as mutation operators inside a deterministic selection loop. The automated-program-repair pattern (ARJA, 2017arXiv171207804Y) has agents propose edit scripts and a deterministic evaluation select on tests plus Pareto objectives including diff size; the convergence alarms and independent-swarm arguments that harden this loop appear with the acceptance gates below, where the fleet already runs their analogs.

Economics runs across all four layers. Budgeted bandits route tier and strategy choices, where each pull has random cost in tokens and wall-time and random reward in landed fixes, and the objective is to maximize merges before the budget is exhausted (2020arXiv200300365C; 2019arXiv190407272S). Shadow prices, the marginal value of loosening a constraint by one unit, rank which binding constraint to relax next, but they are local marginal quantities, so the discipline is relax, re-solve, repeat, and never extrapolate a multiplier over a finite budget change (2022arXiv221103591K). Capacity planning is adaptive two-stage stochastic programming, a committed baseline plus one revision point after observing early demand (2019arXiv190603513B); reserve-plus-burst is the two-settlement demand-response Markov decision process (2016ecc..conf..204R), and the useful lookahead depth has a computable answer, the shortest horizon meeting a target optimality gap (2021arXiv210204874S). When full CI is the expensive fitness call, surrogate-guided evaluation spends real CI only on predicted-best candidates (2017arXiv170505018N) or runs test subsets and extrapolates (2016arXiv160507079K).

The codebase itself as an optimization problem

The survey also treats the managed codebase as a feasible region: valid architecture states under layering rules, size caps, coverage floors, dependency-direction acyclicity, and budgets, so that local cleanup versus restructuring is local versus global optimization, and the sky the agents keep surveying has a topography of its own. The graph machinery for that half of the problem, community detection for module boundaries, minimum cut for boundary placement, energy-landscape methods for restructuring past greedy reach, is developed with its sources in the architecture-management section below, where AOA’s trace-grounded metrics supply the edge weights.

The evaluation discipline and the open ground

The survey’s most portable findings are about evaluation, not any single formulation: replay identical recorded traces under competing policies, force any clever optimizer to beat a dumb baseline first, validate scheduling kernels on constructed instances with known optima, and keep one exact method around because heuristics shrug where solvers certify. Each recurs with its source in the evaluation section, which gates every proposal in between.

The open ground is wide. The survey found no in-corpus paper applying mixed-integer programming, stochastic programming, restless bandits (bandit problems whose arms keep changing state even while unplayed), or minimum-cut to CI systems, merge queues, agent fleets, or architecture decomposition; the nearest neighbors are datacenter reinforcement-learning schedulers (Decima) and search-based remodularization (Adyen). The mixed-integer formulation of agent-fleet dispatch with model tiers as modes, flow-based module-boundary placement, irreducible-infeasible-subsystem-driven rule-conflict diagnostics in a development-infrastructure loop, restless-bandit merge-queue prioritization, and chance-constrained service-level gates for CI (constraints required to hold with a stated probability) are each claimable rather than citable.

Three systems externalize policy; none optimizes it

The least flattering pattern in the observatory literature is also the most familiar to anyone who builds infrastructure. Las Cumbres built a production integer-program scheduler in 2014 (2015arXiv150307170L), the Zwicky Transient Facility built one in 2018 (2019PASP..131f8003B), and group after group has rebuilt recognizably the same slot-assignment program from scratch, teams who share conferences, journals, and in some cases hallways. Every dome reinvented the scheduler for the same reason every company reinvents the build system: it looked like glue between the real work rather than a product worth building once and sharing. The first deliberately multi-mission, open-source scheduling framework arrived only in 2025 (2025PASP..137g4501S). The software-factory ecosystem is speed-running the same pattern with a harder twist: where each dome at least built a scheduler, the agent frameworks pour their effort into the workers, model quality, memory, per-agent planning, and ship the allocation layer as defaults, every orchestration project hand-rolling its own priority heuristics, its own retry logic, its own capacity math, none of it cross-communicated, most of it unexamined.

Gas City follows the design rule that application code does transport, not reasoning, so if a line of code contains a judgment call, it is a violation. Scheduling policy is therefore pushed out through shell interfaces (the work query, the dispatch query, the scale check, the scheduled controller task check, and the gate condition) and prompt text, where it lands as either transport-grade first-come-first-served or model reasoning. Gas City Packs enforces the same split at the policy level: its scripts are plumbing, and semantic decisions belong in declarative workflows and prompts. What actually fills the interfaces today is a set of constants and switches: a cap of five active sessions per worker pool, a single active slot for the merge-integration stage, scheduled controller task backoff capped at 300 seconds, a two-way metadata switch in the dispatch formula that routes “criteria-only” work to one model and “prescriptive” work to another, lexicographic sort keys in pull-request triage (“priority label, then recency”), and a wake budget of five sessions per controller cycle.

AOA is the same story at the measurement layer. It computes four real metrics from agent traces (retrieval locality, edit locality, invariant discoverability, and mutation surface), then makes every decision with a threshold predicate or a lexicographic sort: audit findings rank by tier, descending measured cost, and title; migrations are admitted one at a time when held-out improvement is positive and the reward-hacking gap does not widen; and the top-level gate is a majority vote over at least five repositories. Gas City does carry routing signals already, the criteria-only/prescriptive switch in mol-dispatch.formula.toml among them; what neither system has is any optimizer, bandit, or multi-objective search that consumes those signals to make an allocation decision.

None of this is an accident, and the fix is not to violate the transport-only invariant. That invariant’s own allowed list includes deterministic math, policy enforcement, and mechanical transforms. A priority index computed from declared features, a mixed-integer program solved over declared constraints, a bandit updating declared posteriors: these are deterministic mechanisms over versioned data, closer in spirit to clamping a desired value between a min and a max than to a hidden heuristic. The judgment stays where the invariant wants it, in what the model writes into the model; the solving becomes transport. The Bitter Lesson test, whether a component keeps improving with general compute rather than through hand-encoded knowledge, passes for the same reason: open-source solvers such as HiGHS, SCIP, and CP-SAT improve on their own compute curve independent of the language model, and the model’s role in the loop, authoring and revising the declarative model, gets better as models improve. This division of labor already runs in a published system: MCP-Solver (2025arXiv250100539S) has a language model edit a MiniZinc model item by item, every edit validated before acceptance, solve strictly separated from edit, model state held server-side. That is the write path the invariant wants, built by someone else, fourteen months ago.

Dispatch: a priority index in the work-query seam

The lowest-friction insertion available is replacing the tier-3 ordering predicate with a ranked claim: giving the observation queue its scoring function. This is a pure configuration change by Gas City’s own design because the dispatch configuration is fully overridable per agent, and the replacement policy is Naghib’s LSST scheduler transplanted: score each ready work item as a weighted sum of features (age, priority, dependency criticality measured as downstream unblocked work, expected cost for this task class, retry count, historical success rate for task-type and model tier), claim the argmax (the highest-scoring item), and tune the weights offline against replayed queue traces. No transition model is needed, and crash-robustness comes from the claim protocol rather than from any property of the score: the earlier discovery tiers already recover a session that dies mid-claim, and because scoring reads only current queue state, whatever survivor the recovery hands back is a valid input to the next claim.

Deadline-shaped work wants one refinement. Yu, Xu, and Tong showed that scheduling jobs with deadlines and stochastic service times decomposes into a per-job Whittle index, a single priority scalar that, under the standard indexability conditions on the underlying decision process, near-optimally trades urgency against completion probability (2016arXiv161000399Y). The work-item data model currently carries an optional priority and nothing temporal, which is the one schema gap worth closing early: a due-date metadata key, or a first-class field, is the prerequisite for any urgency-aware index and is a low-cost schema change to make now.

Epoch scheduling: the work-item graph is a resource-constrained project schedule

When two neutron stars collide and a gravitational-wave detector issues an alert, the follow-up scheduler has seconds, not minutes, to choose which fields to image before the kilonova, the collision’s optical afterglow, fades. ZTF’s target-of-opportunity solver caps at 500 seconds; across 951 simulated alerts most reached proven optimality inside the limit, and the rest shipped whatever the best-found schedule was when the clock ran out, a 100-second cap costing only 64 truncated solves (2022ApJ...935...87P). The production schedulers in this literature converge on that pattern: a hard time cap, the incumbent taken as the answer, the optimality certificate treated as a luxury nobody waits on. A plan a few percent off but in hand now beats a perfect plan for a night that has already changed. The software factory inherits the constraint, and the interrupt discipline with it, because a target-of-opportunity alert is the customer incident of the dictionary above: the epoch scheduler gets a deadline measured in seconds, ships the best schedule it found, and nobody waits on a proof, because the merge queue, like the sky, keeps moving.

Between claims, the software factory periodically wants a plan, and the work-item graph is literally a resource-constrained project-scheduling instance: activities with finish-to-start precedence (declared dependencies), renewable resources (agent seats per pool, integration-stage slots, CI runners), and non-renewable budgets (daily tokens). The multi-mode variant maps model-tier routing into the same solve: each item offers modes (a heavier model, a mid model, a cheaper model, an external model) with different duration and cost, and the solver picks mode and schedule jointly, which turns the dispatch formula’s two-way routing switch into data. Duration uncertainty gets the Bertsimas-Sim budgeted treatment, guarding the makespan against “at most a bounded number of items blow up simultaneously” instead of the useless all-worst-case (2022arXiv220306983B). The natural host is a scheduled controller task: state changes mark the plan dirty, a cooldown coalesces the churn, and one solve per epoch recomputes assignments and re-dispatches. The scheduled-task mechanism already exists and runs without an agent on each controller cycle.

Three formulation pieces from the observatory papers drop in with almost no translation. Lampoudi’s reservation-start binaries, where a variable equal to one means reservation i starts at slot k and an occupancy map enforces one reservation per resource-slot, model the merge queue and CI-slot booking in a number of constraint rows linear in reservations plus slots (2015arXiv150307170L); the merge-integration stage’s single-slot lock becomes a capacity row instead of a lock. Singer’s disjunctive interval constraints, requiring two intervals to be separated by at least a gap with an order binary (2025PASP..137g4501S), turn project-workspace conflict avoidance from today’s pessimistic serialization (one project workspace per item, then the merge-integration stage serializes every merge) into a constraint the solver plans around: two items whose file sets overlap simply must not overlap in time, and the solver decides who goes first by what the objective prefers. And ZTF’s two-level decomposition, an assignment integer program over 30-minute blocks followed by an exact tour within each block, is the template for session batching: assign items to agent-session blocks, then order work inside the session to minimize context-switch cost, because a warm project workspace, a loaded repository map, and cached build state are slew time under another name.

The operational discipline comes from ALMA and the MIPcc23 reoptimization competition. ALMA re-solves on every condition change but treats an in-flight scheduling block as atomic; the factory equivalent freezes running sessions as fixed constraints and never preempts them. MIPcc23 (2023arXiv231114834B) defines the warm-start regime the factory lives in, one formulation with perturbed data every tick, and its scoring makes schedule stability a measured quantity rather than a hope, which matters because an epoch scheduler that reshuffles everyone’s assignments every tick is worse than first-come-first-served in practice even when its makespan is better on paper.

Capacity is a queueing problem; tier routing is a budgeted bandit

NASA’s Deep Space Network schedules a handful of giant antennas against every active deep-space mission, including a spacecraft launched in 1977 that needs several antennas arrayed together just to be heard. Its scheduling model does not stop at throughput: alongside the visibility windows and the setup-and-teardown time bracketing every track, it writes fairness down as math, explicit terms balancing each mission’s share of satisfied time, validated against a real week of operations (2021arXiv211111628C). Most orchestrators expose priorities and queues and stop there; fairness, if it appears at all, emerges from tuning rather than from anything the optimizer is required to honor. The failure this prevents is familiar to anyone who has watched an agent fleet: one urgent epic arrives, every worker in the pool feeds it for days, and maintenance work rots while a smaller project’s tracked issues age past relevance. The defense in most systems is a human noticing. In the DSN’s formulation the defense is a coefficient, and a schedule that starves the small program pays for it in the objective, visibly, instead of hiding it in a queue nobody audits. The same model carries the rest of the session economics: setup and teardown are the clone-and-context-load tax, minimum track durations exist because a session too short to do useful work still pays full spin-up cost, and arraying several antennas on one oversized request is several agents co-assigned to one epic under a single completion constraint.

The scale-check interface currently implements a proportional controller with no plant model: it sets desired capacity to queue length, reacting to the error without any model of how the system responds. Wall-clock capacity is the factory’s dark hours, renewed daily and unbankable, and merge and review pipelines run intentionally hot against it; the regime for sizing intentionally-hot service systems is heavy-traffic queueing, the asymptotic theory of servers run near saturation, including the recent variant where service-time distributions themselves are unstable (2022arXiv220405733A), which is the honest description of agent runtimes across model versions. The concrete near-term wins are cheaper than that machinery suggests: hysteresis and dwell times (scale-up and scale-down thresholds set apart, plus a minimum hold before reversing) for the unimplemented anti-flapping cooldowns, and a two-settlement structure for capacity, a committed baseline plus burst recourse (extra capacity bought later once demand is seen), which is structurally the demand-response aggregator Markov decision process (2016ecc..conf..204R) and, in its simplest form, an adaptive two-stage stochastic program whose bounds say one revision point captures most of the value of full multistage planning when demand drifts slowly (2019arXiv190603513B). The static constants worth promoting to adaptive control are already enumerable: the wake budget of five per controller cycle, and the fixed stop and interrupt counts per lifecycle wave.

Tier routing has a stronger claim waiting, and in the dictionary it is instrument selection: which camera to mount for this field, priced. The pricing module already produces per-invocation cost estimates and is explicitly scoped as decision support; nothing consumes it for decisions. Each (task-class, tier) pair is an arm with random cost in tokens and wall-time and random reward in merged outcomes, and maximizing merges before the budget dies is the budget-constrained bandit objective exactly (2020arXiv200300365C; knapsack-bandit chapter of 2019arXiv190407272S). Thompson sampling, which plays each arm with the probability it is currently believed best, run on reward-per-cost, replaces the static routing table and degrades to it under thin data, and inherits AOA’s construct-validity discipline, the check that a metric measures what it claims, for free: the reward definition (“merged and not reverted within N days”) is a declared, versioned choice, advisory until its correlation with an external outcome is confirmed, as AOA’s construct module already does for metrics.

Acceptance gates: noisy constraints, documented Goodhart, unwired finalizer

The system has a sanctioned interface waiting for a deterministic acceptance rule: the review-quorum finalizer defines the durable verdict contract but is not yet invoked when declarative workflows are assembled. Two design rules follow, one borrowed from the survey and one that the survey motivates. First, gate signals are noisy: flaky tests, the factory’s weather, nondeterministic benchmarks, and model-judge scores are noisy evaluations of the underlying constraint. The general principle for deciding under measurement noise is sequential testing, accumulate evidence until it clears a calibrated margin rather than acting on one reading, and the noisy sequential-quadratic-programming literature, constrained optimization run on noisy measurements (2021arXiv211004355O), is one worked instance of building acceptance criteria that do not thrash on noise. Applied to a verdict, this report’s transfer is a rule that requires signal exceeding a noise-calibrated margin rather than a single passing run. Second, the acceptance predicate should test dominance across the objective vector rather than collapse it to a scalar. Chen, Li, and Yao’s benchmark result that weighted-sum fitness converges to Pareto-dominated points (2020arXiv200108236C) is the evidence behind that choice, and AOA’s own “good” label (improves held-out pass and holds or shrinks the reward-hacking gap) is already a two-objective dominance check; the system-wide version keeps tests, diff size, coverage delta, and review findings as a vector and accepts on dominance within tolerance.

The Goodhart evidence deserves standing citation because it is the strongest empirical support for a design decision all three systems already made. At Adyen, 5.5M lines of code, search operators learned to game the modularity metric monotonically by moving single classes into fresh modules, metric improvement did not predict developer acceptance, and developer review had to be the real gate (2021arXiv210200701S). Metric gates select candidates; an independent judge that was not the optimization target accepts them, which is the job the fleet’s stress-test flow does before a sensitive change ships, an adversary run whose only mandate is to break the candidate. The merge-integration stage’s reject-to-pool loop, the pull-request-ship workflow’s three-iteration convergence cap, and AOA’s held-out conditioning are all instances of the same defense, now with a published industrial failure mode behind it.

The redundant-independent-attempts stance, where redundant independent attempts are the reliability mechanism and premature convergence is intentionally tolerated, also picks up quantitative footing here. The fleet already runs it as a pair of named flows: diverge fans out N independent agents on uncorrelated context windows so their errors do not correlate, and converge takes the divergent findings into a structured debate that selects and merges only at the end. Gravitational-wave searches run multiple independent particle swarms, population-based stochastic searches, specifically to bound the probability of missing the global peak (2010PhRvD..81f3002W), which is the argument for that fan-out, N no-crosstalk attempts merged only at selection, stated with a number attached. And PIKAIA, an astronomy genetic-algorithm library, ships a ready-made alarm for the exact failure mode diverge exists to prevent: its convergence detector drives the mutation rate from population fitness contrast, the spread between the best and the mean score across the population (1995ApJS..101..309C), firing when the parallel attempts have all collapsed onto the same local fix, the moment the fleet should raise its temperature through prompt variance, model mix, or fresh context seeds.

Agent-Oriented Architecture supplies the objective vector; OR hardens its gates

The relationship between AOA and the optimization layer runs both directions. Forward: AOA’s four metrics are the natural candidates for what the system’s architecture-management objective vector should contain, because they are trace-grounded measurements of agent-legibility rather than proxies for human taste, and they come with declared parameters (the retrieval cutoff, mutation depth, floor and ceiling) already emitted as data. A boundary-placement optimizer needs edge weights; retrieval and edit locality, computed per module from real traces, are coupling weights grounded in observed agent behavior, a firmer signal for the graph work in the next section than co-change counts alone.

Backward: AOA’s own premortem flow, six independent failure-lens agents each writing a prospective postmortem (“it is six months out and the project failed”) without seeing the others, returned a central finding, all six lenses breaking the same single blocking gate, with the shared theme that declaring the over-approximation as data makes ambiguity visible without making verdicts robust; that is a problem with known operations-research shapes. A majority vote over five repositories is a point verdict; the alternatives are interval verdicts with certificates. Duality, the price-side reading of the same optimization, gives bounds (this migration’s held-out improvement is at least X under the declared weights, at most Y under the adversarial ones). By analogy, the flat-truncation certificates that prove a numerical result insensitive to a truncation choice (2011arXiv1106.2384N) suggest the design pattern this report wants at the gate: proving a verdict insensitive to the contested parameter choices rather than asserting it, with the rankings-flip-under-floor-versus-ceiling failure exactly what reporting a dominance region instead of a scalar rank prevents. The migration roadmap’s one-at-a-time admission policy (never batch, each candidate admitted only on the “good” label) is a sequential decision process currently run as a fixed ordering; with reward equal to the good label and cost equal to evaluation spend, it is a budgeted bandit over the candidate fix set, and the exploration it adds is exactly what a fixed ordering forecloses.

One correspondence is close enough to be worth checking. AOA’s budget module enforces a token ceiling over the transitive closure of context files (every file reachable by following imports, not just the directly named ones); DALiuGE, the Square Kilometre Array’s dataflow scheduler (2018arXiv180507568W), partitions a dataflow graph under the constraint that concurrently-active resource demand per partition stays under node capacity, and its published negative result is that partitioning the whole static graph is both wasteful and ill-posed because only the temporal working set matters. These are analogous capacity constraints, not the same one: AOA’s ceiling is static, bounding a reachable set, while DALiuGE’s binds concurrent demand over time. The shared warning is what transfers: the unit of architecture optimization is the active frontier of the repository under an agent’s context capacity, not the global dependency graph.

Architecture management: cluster with Leiden, place boundaries with min-cut, restructure like basin-hopping

For the codebase itself, the sky in the dictionary, the survey’s graph results give the deterministic half of an architecture loop. Community detection over the symbol and file dependency graph, weighted by AOA’s locality metrics, proposes module and ownership boundaries; the algorithm choice matters because Louvain can emit disconnected communities, which as package boundaries are nonsense, while Leiden guarantees connectivity (2019NatSR...9.5233T), and refactoring via community detection is published practice (2018arXiv181110171R). Boundary placement between two specific subsystems is a minimum-cut query, finding the cheapest set of edges whose removal separates the two sides. The almost-linear-time maximum-flow result (2022arXiv220300671C) puts the theoretical complexity of that query within reach of a per-commit budget on a large single-repository codebase (a monorepo), the practical constant factors being the report’s expectation to verify rather than the theorem’s guarantee; the survey found no paper applying flow-based boundaries to software, so this transfer is claimable. Edit scripts, not target states, are the representation for the resulting refactoring plans, a choice three literatures converged on independently, academic remodularization (2020arXiv200506510W), the Adyen work (2021arXiv210200701S), and program repair (2017arXiv171207804Y), because incremental fitness on diffs is cheap and plans map one-to-one onto reviewable pull-request-sized changes, which is also the representation AOA’s migration plans already use.

For restructuring that greedy agents cannot reach, the chemical-physics energy-landscape corpus is the underexploited source, though the transfer is a hypothesis this report proposes, not a measured property of codebases. In molecular energy landscapes, funnel topography predicts optimization difficulty (2000cond.mat..7338D); the conjecture here is that a codebase behaves the same way, a single-funnel one improving under greedy local cleanup while a multi-funnel one, several plausible decompositions separated by large-diff barriers, traps greedy agents in locally-clean-but-globally-wrong states. Basin-hopping (1998cond.mat..3344W) is the molecular protocol for crossing a barrier: take a deliberately disruptive perturbation, immediately run local cleanup, and accept or reject on the post-cleanup score, never the raw perturbed one. That acceptance rule maps onto “let an agent attempt the big move, then judge the cleaned-up result,” and it justifies temporarily holding a worse intermediate state inside a multi-step workflow whose gate only fires after the cleanup step. The experiment that would settle it: seed a real refactor as a basin-hopping perturbation on a codebase whose decompositions are known, and check whether post-cleanup acceptance reaches structures greedy cleanup provably cannot.

Gas City Packs already separates model from data; add the solver and the certificates

Gas City Packs has, without naming it, rebuilt the algebraic-modeling-language pattern that Pyomo and JuMP exist to provide (2015arXiv150801982D): declarative manifests and workflow variables hold the model, project-workspace state holds the data, executable code is forbidden from holding policy, and composition is by import. What is missing is the two things a modeling language buys beyond structure. The first is a solve step: the constants in the agent configuration and the routing predicates in workflows become decision variables and constraints the epoch solver reads, so a cap like “five active sessions” stops being a hand-tuned guess and becomes either a solver output or a declared hard constraint with a known shadow price. The second is infeasibility certificates. When the declared rules admit no schedule, a solver that supports it can emit an irreducible infeasible subsystem, an inclusion-minimal set of rules that cannot all hold at once, turning “the system is stuck” into “these three rules conflict; relax one.” Configuration-name collisions already fail with a clear diagnosis naming the collision; an irreducible infeasible subsystem extends that courtesy to every policy conflict, and the survey found the technique underused even among operations-research practitioners, so a system that surfaces conflict certificates routinely is ahead of the field that invented them. Solver logs complement the event bus the same way: bounds, gaps, and timing per decision, replayable and appealable, where model judgment offers neither.

Shadow prices close the economics loop, with the documented caution attached. At an epoch optimum, the dual variable on each binding constraint, the price the solve attaches to that constraint, measures what relaxing it by one unit buys: another merge-integration-stage slot, another CI runner, another point of token budget. Khabarov showed extrapolating those multipliers over finite changes produces an arbitrary number (2022arXiv221103591K), so the discipline is relax one constraint, re-solve, read the new prices; the factory gets a principled answer to “what should we buy next” without ever trusting a multiplier beyond the margin.

Evaluation: replay fixed traces and beat the dumb baseline first

A telescope gets each patch of sky exactly once, which is why survey teams lean so hard on simulators: the only way to test a scheduler against last year’s conditions is to synthesize them, because the real sky is gone. This is the one door the astronomers cannot walk through and a factory can. A software factory records every arrival, every claim, every outcome, most of it already sitting in audit ledgers kept for other reasons: each work item’s arrival time and priority, which worker claimed it and when, how long it ran, what it produced, whether review accepted it. That ledger is an experimental instrument, and it is also the state-estimation substrate the control loop needs, one artifact serving both. Replay an identical recorded week under two dispatch policies with the arrival trace held fixed, and whatever differs between the runs is the policy, because the arrivals need no simulator; they were captured the first time. Unlike the sky, your nights will hold still while you measure them.

Nothing above should ship on argument alone, and the survey’s most portable finding is the evaluation discipline rather than any formulation. Decima’s variance-reduction trick (2018arXiv181001963M) is not specific to the reinforcement-learning setting it was published in: when comparing two dispatch policies on an input-driven system, replay the identical recorded arrival trace under both, because otherwise the variation in arrivals can swamp the policy signal. The system records everything needed for this already; the work items and the event bus are the trace. The second gate is SWAY (2016arXiv160807617C): random oversampling plus recursive halving matches evolutionary search at orders of magnitude fewer evaluations across search-based-software-engineering benchmarks, and its authors proposed it as the mandatory baseline precisely because clever optimizers embarrassingly often tie it. Every claim that the mixed-integer program or the bandit beat first-come-first-served must also report the margin over a trivially-tuned priority queue on the same replayed traces. Third, Las Cumbres validated its scheduling kernel on constructed instances with known optima, oversubscribed and undersubscribed regimes both, before trusting it; the factory’s scheduler deserves the same fixture set. And exact methods earn their keep on negatives: in Handley’s runs the heuristic failed to schedule 7 of 360 instances; six were genuinely infeasible, and on the seventh the mixed-integer program proved a feasible schedule the heuristic had silently missed (2024AJ....167...33H), which is the same silent-loss class as the dispatch-drop risk the config-layer architecture already flags. Solvers certify; heuristics shrug.

The whole apparatus points at one experiment worth stating precisely. The primary comparison is solver-informed dispatch against the FCFS the factory runs today and a trivially-tuned priority sort, all three on identical replayed arrival traces. The outcomes are throughput and latency made concrete: priority-weighted flow time, unblocking-value throughput, and per-class p95 (95th-percentile) tails. The power requirement is enough recorded weeks that a real difference clears trace-to-trace variance, which is why the replay harness and the 7.5 weeks of captured snapshots, not any solver, are the gating artifact. The corpus says nobody has published that experiment for a software factory.

What not to build

The negative space is as load-bearing as the proposals. Skip the scenario-tree stochastic planner, because the deployed systems that faced the most quantifiable uncertainty in this literature chose deterministic re-solve or memoryless policies, and the factory should exhaust those before touching recourse models. Skip Benders or price decomposition until a compact model has actually hit a wall; at work-queue scale the monolith should win comfortably, on the benchmark evidence above. Keep the solver out of the hot loop, where the index dispatches per claim while the mixed-integer program runs on epochs with a hard time limit and ships incumbents. Do not build a scalar architecture-health score; the weighted sum has a documented failure mode and AOA’s dominance-shaped “good” label is already the right pattern. Do not extrapolate shadow prices beyond the margin. Avoid a commercial-solver dependency: many surveyed implementations run on Gurobi academic licenses and rarely benchmark the open alternatives, a reproducibility monoculture worth not importing when HiGHS, SCIP, and CP-SAT are open, strong, and consistent with a no-paid-API (no paid application-programming-interface) posture. And believe none of it without the replay harness, which the evaluation section makes a prerequisite rather than an appendix.

Adoption: a prerequisite phase, then four config-first phases

Phase	Change	Seam	Code touched
0 (prerequisite)	Trace replay harness; deadline metadata; SWAY and FCFS baselines; known-optimum fixture instances	work items plus event bus (read-only)	none (tooling only)
1	Feature-based priority index replacing FCFS claim; weights tuned on replayed traces	work-query / dispatch-query interface in the dispatch configuration	none (configuration plus one scoring script)
2	Epoch mixed-integer program (RCPSP plus reservation binaries plus disjunctive project-workspace windows plus tier modes), anytime, warm-started; stability scored	scheduled controller task; merge-integration-stage capacity as constraint rows	new scheduled controller task plus solver sidecar (HiGHS/CP-SAT)
3	Budgeted-bandit tier router fed by the pricing module; deterministic quorum finalizer with noise-margin verdicts	workflow variables or session setup; the review-quorum finalizer	Go: wire finalizer, add routing hook
4	Architecture loop: Leiden and min-cut boundaries weighted by locality metrics; basin-hopping restructure protocol; irreducible-infeasible-subsystem surfacing for policy conflicts	metrics pipeline plus migration plans	new analysis tooling; metrics stay measurement-side

Phase 0 is a prerequisite, not a step: it builds the measurement substrate every later phase is judged against and changes no behavior. Phase 1 is deliberately boring too, changing no Go, and on the observatory evidence it is where much of the value of “informed re-decision over FCFS” lives. Each of the four adoption phases is admitted the way the toolkit admits migrations, one at a time, on replayed-trace evidence against the phase-0 baselines, never batched. Assembled, they close the loop this report drew at the start: observe the queue and the repository, schedule an epoch under a deadline, dispatch and execute between epochs, measure, re-decide. The plan is never the commitment; it is the loop’s current output, recomputed once the state has drifted, which is why ZTF can resume from the current sky at 20:47 without having to repair the stale plan, absorbing the lost exposures as the price of the new conditions rather than a failure to recover from.

Where the implementation stands (2026-07-11)

Phase 1 has a complete, ready-to-implement design spec as of July 11: a priority-index dispatch policy in the work-query interface. The spec re-verified this report’s premises against the current codebase and sharpened two of them. The interface has moved from the general dispatch configuration to the dedicated work-query configuration, and a custom work query replaces the full three-tier discovery contract rather than tier 3 alone, so the scoring script reproduces the crash-recovery and pre-assigned tiers verbatim and changes claim order only. The claim contract turns out to be “first eligible element of the JSON (structured text) array the script prints,” so once readiness, route eligibility, assigned-work precedence, and failed-claim filtering have selected the eligible set, array order is what sets priority among those candidates.

The score is Rubin’s shape transplanted without modification: a weighted sum where declared priority carries weight 1.00 and the secondary features (due date, unblocking value, age) carry 0.10, 0.08, and 0.06, each normalized to the unit interval from fields the ready-work query already returns. The initial weights encode a band-dominance invariant: adjacent priority bands sit 0.25 apart and the secondary weights sum to 0.24, so declared priority strictly dominates and the index only reorders within a band, which is where FCFS was actually leaving value (an aged, heavily-blocking, due-tomorrow item sitting behind a fresh isolated one). The missing deadline field lands as a due-date metadata convention read only by the scoring script, never enforced. Rollout is three gated stages: shadow mode (log what would have been claimed, change nothing), a one-project canary (a single project running the new policy live while the rest stay on FCFS), then fleet, each admitted on replayed-trace evidence, and FCFS is a point in the weight space, so the tuned index can only lose to it by overfitting, which the temporal holdout (tuning on early weeks, scoring on held-back later ones) catches.

Phase 0 is the current frontier. The system’s event bus holds about 7.5 weeks of full work-item snapshots (2026-05-19 onward), enough to replay recorded arrivals under FCFS, a trivially-tuned priority sort, and the index on identical traces, reporting priority-weighted flow time (arrival-to-completion time), unblocking-value throughput, and per-class p95 tails. That replay harness is the first artifact to build: it gates everything else, produces the baseline numbers this factory has never measured, and needs no approvals to run read-only. Nothing is in production yet; dispatch fleet-wide today is still the one-line FCFS this report opened with.

The open problems are allocation problems

Most of what a factory optimizer needs is still unknown, and the unknowns are specific enough to name.

State and uncertainty come first. How should a factory estimate the duration and success distributions its scheduler consumes when every model release redraws them, and what is its seeing monitor, the cheap pre-run measurement of context quality that predicts whether an expensive run is worth committing? The objective is just as open: which objective functions correlate with business value at the quarter scale rather than the sprint scale, and what is the exchange rate between one engineer interruption and a day of queue latency, a coefficient every schedule sets implicitly and nobody has measured?

Interruption policy is unresolved at both ends. ALMA freezes in-flight blocks and never preempts, which is clearly right for a twelve-minute exposure and much less clearly right for a six-hour agent session whose telemetry says it is deep into the wrong approach, so when should a factory kill running work for a target of opportunity, and when should it let the session land? Human review, the shared serial instrument, deserves its own queueing theory: an index policy, score every waiting item and take the highest, for what the one reviewer should look at next, and a defensible price for their bandwidth, since a factory that models tokens but not attention has priced the cheap resource and ignored the scarce one. Exploration remains unpriced too, in both routing and planning: how much budget should a router spend on arms it knows little about, and against what baseline should its regret be charged?

The widest question is the simplest: which scheduling policies beat greedy agent execution, by how much, at what queue depth and dependency coupling, on replayed traces, the experiment the corpus says nobody has published for software factories. Alongside it sits a question factories can only answer about themselves, what telemetry a factory must expose, arrival traces, per-outcome cost, review latencies, context-quality measurements, to be optimizable at all; an observatory publishes its scheduler, and a factory that wants the same improvement curve has to publish its nights, at least to itself.

Several of the instruments already exist or are in progress, and under this framing they stop being separate projects and become boxes in the one loop. CodeScaleBench evaluates the execution level; EnterpriseBench evaluates orchestration across repositories, the planning level at fleet scale; memory work is state estimation under a friendlier name; Theory-of-Mind modeling predicts what an agent, or the human a schedule is waiting on, will do next, which is the transition model every policy above assumes without stating; batch-change tooling is the many-coupled-tasks regime the RCPSP formulation exists for; and evals are utility estimators, the term the replanning loop consumes.

The bet underneath the whole report: generation is improving on the model vendors’ compute curve, the same curve for every factory at once, which makes it a poor axis of differentiation and a strange place to concentrate a field’s research attention. Allocation, of compute, of context, of interrupts, of the one human reviewer everything waits on, is improving on nobody’s curve. Somebody is going to run the replay experiment, publish the first regret numbers for a merge queue, and put a fairness coefficient in front of a fleet, and much of the interesting software-engineering work ahead will then look, in retrospect, like what the astronomers did between SPIKE and M4OPT: not making the instrument sharper, but deciding, every night, where to point it.

---

References

These are the sources behind the literature review, drawn from the survey of the SciX/ADS corpus run as six parallel research agents across the operations-research facets. Every bibcode resolves at NASA ADS.

Key bibcodes, resolvable at ADS: 1990aisi.conf....5J (SPIKE, the Hubble Space Telescope scheduling system), 1995ApJS..101..309C (PIKAIA, a genetic-algorithm optimization library), 1998cond.mat..3344W (basin-hopping global optimization), 2000cond.mat..7338D (funnel topography of energy landscapes), 2003A&A...403..357G (policy encoded in the fitness function), 2009orci.book....3H (Pyomo modeling language), 2010PhRvD..81f3002W (independent-swarm particle-swarm optimization), 2011arXiv1106.2384N (flat-truncation certificates), 2015arXiv150307170L (Las Cumbres integer linear program), 2015arXiv150801982D (JuMP modeling language), 2016A&C....15...90S (ALMA scheduler), 2016arXiv160507079K (FABOLAS, cheap-subset hyperparameter tuning), 2016arXiv160807617C (SWAY, a random-sampling baseline optimizer), 2016arXiv161000399Y (deadline restless bandits), 2016ecc..conf..204R (two-settlement Markov decision process), 2017arXiv170505018N (FLASH, surrogate-guided configuration search), 2017arXiv171207804Y (ARJA, evolutionary automated program repair), 2018arXiv180507568W (DALiuGE dataflow scheduler), 2018arXiv181001963M (Decima, a datacenter scheduler), 2018arXiv181110171R (remodularization via community detection), 2019AJ....157..151N (LSST feature scheduler), 2019PASP..131f8003B (ZTF integer linear program), 2019arXiv190407272S (multi-armed bandits survey), 2019arXiv190603513B (adaptive two-stage stochastic programming), 2019arXiv190905207H (online convex optimization and regret), 2019NatSR...9.5233T (Leiden community detection), 2020arXiv200108236C (search-based-software-engineering weighted-sum failure), 2020arXiv200203447L (MathOptInterface, a solver-agnostic model layer), 2020arXiv200300365C (budget-constrained bandits), 2020arXiv200506510W (academic remodularization), 2021arXiv210200701S (Adyen remodularization), 2021arXiv210204874S (lookahead depth), 2021arXiv211004355O (noisy sequential quadratic programming), 2021arXiv211111628C (DSN mixed-integer linear program), 2022ApJ...935...87P (MUSHROOMS, a ZTF target-of-opportunity scheduler), 2022NatSR..1222417B (surrogate-Lagrangian bound-based relaxation), 2022arXiv220300671C (almost-linear-time maximum flow), 2022arXiv220306983B (compact robust resource-constrained project scheduling), 2022arXiv220405733A (high-uncertainty heavy-traffic queueing), 2022arXiv221103591K (shadow-price extrapolation caution), 2023arXiv230908801D (multi-objective dual bound sets), 2023arXiv231114834B (MIPcc23 reoptimization competition), 2024AJ....167...33H (Traveling Telescope Problem), 2025arXiv250100539S (MCP-Solver, a language-model-driven constraint solver), 2025PASP..137g4501S (UVEX ultraviolet telescope and the M4OPT multi-mission scheduling framework), 2025arXiv250403666R (scheduling under night-loss uncertainty).