Schedule the extra help a buff creates, with the team’s access visible.

The model needed a correction before the solver did.

The old flow optimizer was solving its stated arithmetic problem, but that problem credited a selected player’s entire day-specific stock plus their general speedup stock as appointment value. It maximized this number before appointment count, with wishes and scarcity used only afterward. “Filled slots” meant appointments, rather than distinct teammates served. Mathematical exactness did not establish that this represented the best team outcome.

A member who commits to spend resources is trusted to do so. A question asking what they own establishes inventory, while a question asking what they intend to use establishes a plan. Neither answer alone establishes how much a ministry title changes the result. No reliability discount, presumed exaggeration, alliance favoritism or wealth penalty is added.

The audit also found concrete implementation defects: training-day stock was priced like a speedup-spend task; the browser could add crystals to a field already containing final points; every recognizable time range in comments became a positive wish on every day, including “cannot” ranges; raw availability and a hardcoded 48-slot day distorted scarcity outside the default settings; a general-only extra appointment could improve the fill objective without adding any new modeled resource benefit; and browser imports did not preserve accepted appointments.

Mechanics that materially change the answer.

The following evidence distinguishes developer statements, game references and firsthand player observations. Where a fact varies with state progression or has not been verified in the current game interface, the implementation requires explicit configuration or a declared plan.

The rebuilt algorithm.

1. Establish the no-appointment baseline.

Each member has a feasible baseline: what they plan to contribute without consuming a public appointment. A baseline can spend speedups and crystals and finish tasks. A freely available personal president buff belongs in that member’s baseline rather than being treated as a second public seat. Existing successful actions remain history.

2. Build feasible whole-event alternatives.

A plan contains the member’s appointments, actions or validated dependency order, total resource use, preferences and additional benefit over their baseline. Construction, research and training alternatives for one member belong together when they share general speedups or prerequisites. The advanced solver selects exactly one complete alternative for that member; it never adds independently priced days and spends the same pool again.

The mechanics calculators evaluate explicit same-work timers and a bounded fixed-budget training approximation. The advanced optimizer checks supplied plan budgets and declared prerequisite order. These are separate responsibilities: the optimizer does not guess omitted task timings or create every possible game plan from a stock count.

3. Encode actual appointments and commitments.

Use absolute UTC intervals, physical office identities and a minimum 30-minute occupied seat. Construction and research both use the same VP seat. Office intervals can conflict even when their slot IDs differ. One member cannot hold overlapping appointments across offices. Configurable member/day/event caps, cross-position gaps, unavailable intervals and accepted locks remain hard constraints. The browser’s three-day template uses the existing Monday/Tuesday/Thursday categories; the advanced model accepts the event’s actual dates and offices.

4. Choose an explicit team policy.

The browser compares balanced and benefit-first outcomes whenever every eligible request has a benefit estimate. It shows the number of people and measured benefit under each. There is no hidden “sacrifice five percent” rule. If estimates are incomplete, the browser disables benefit ranking for everyone and uses the disclosed team-first order. It still reports measured subtotals with the missing estimates counted. If history is incomplete, rotation is disabled for everyone; an unknown history is never silently treated as zero.

5. Solve at the right level of complexity.

The browser’s independent per-day requests form an exact minimum-cost flow network. A one-unit first-access arc rewards serving a distinct member, with further capacity for additional requested days. Separate member/day nodes enforce one appointment per category. Only available, unlocked seat arcs exist. Dynamic BigInt bounds preserve the policy’s strict priority order. Prior draft placements are soft preferences; accepted appointments are fixed.

Coupled whole-event alternatives require a richer model. The advanced Python solver uses one binary variable per member plan, exactly one plan per member, and office interval conflicts between plans. Resource and prerequisite feasibility is validated before solving. OR-Tools CP-SAT proves one objective stage, fixes its exact integer value and proceeds to the next under one total deadline. An unfinished solve reports FEASIBLE or UNKNOWN, with stage results, rather than claiming an optimal schedule.

For member p and feasible whole-event plan k:
  choose x[p,k] ∈ {0,1}
  Σ_k x[p,k] = 1

For overlapping intervals in the same physical office:
  incompatible plan selections cannot both equal 1

For each candidate plan:
  total consumption of each member resource ≤ that member’s budget
  requested days, availability, caps, prerequisites and locks must fit

Benefit = Σ selected incremental values in ONE declared unit
Coverage = count of distinct members with an appointment
Baseline benefit = 0, even when the baseline contributes resources

Optimize the selected policy’s stages in order.
Never add gross stock, timer savings and event points into one number.

The advanced model allows signed incremental values. For example, a title can reduce the speedup minutes needed for fixed work, and hence reduce a speedup-spend task’s gross points. Benefit-first can choose the baseline instead; a coverage-first policy or fixed appointment can retain the plan and report the negative delta honestly.

What the scheduler needs to know.

The original survey remains usable. The browser does not require resources to establish eligibility. Optional exact headers include “Construction preferred UTC”, “Construction unavailable UTC” and “Construction buff benefit minutes”, with Research and Training equivalents, plus “Prior appointments”. Benefit minutes are additional time saved over the same plan without the title, with shared resources already allocated once. Unknown benefits stay blank. This simplified browser input is additive by requested day; coupled plans belong in the advanced model.

Comments are retained as source context, never automatically converted into constraints or positive wishes. Output remains marked DRAFT until those comments have been reviewed and hard limits are recorded in structured input. Ambiguous or unconverted local times produce concrete input issues. Prior accepted appointments load from a small Day / Start UTC / Player ID CSV; mismatches stop with a reason instead of moving the appointment.

Synthetic survey · Accepted appointment example · Complete advanced plan example · Its verified result · Exact schema and commands

Implementation evidence and limits.

The browser is a working local replacement for the old survey scheduler. Its tests compare policy outcomes with independent exhaustive enumeration on 300 small instances, plus targeted regression cases. A 120-member synthetic case checks the normal 144-slot event capacity. Actual browser testing covers importing the survey, accepted appointments, result rendering and downloading the workbook.

The advanced solver has semantic fixtures, an independent raw-JSON exhaustive oracle and production CP-SAT comparisons. The verification record contains the actual commands, counts and results for this edition. Historical test-count claims from the old README are not used as evidence for v4.

The advanced plan model does not generate a complete personal build tree, simulate alliance helps, infer banked troops, optimize all possible general-speedup splits or verify the active in-game event table. Supplied plans must be game-feasible; the schema says which assumptions it validates and which it cannot. The calculators do not establish missing rates, resource readiness, spending intent or the current state’s rules. A task-derived integration example calculates two new-build benefits, compiles alternative plans and serves both zero-general-speedup members for 1,600 additional timer seconds saved; the flexible member is moved to the later seat. Its generator and complete input are included. The research identifies those additional inputs rather than filling them with invented constants.

Neither route books appointments in the game. The current game’s next-24-hours booking horizon is separate from this external event plan. No reservation, payment, message or game account was changed.

Source register.

Developer release notes receive the greatest weight for interface and cooldown changes. Community-maintained game references and firsthand gameplay support practical mechanics, with uncertainty retained. Some indexed official support articles currently return 404 directly; their retrieval limits are disclosed in the machine-readable record.

Full research record: findings, formulas, evidence status and unresolved configuration