Skip to main content

42. Main Instance 8-Tournament Schedule

Status: Accepted Date: 2025-07-06

Context​

The "Main" Mercury instance is responsible for running the primary, production-validated trading tournaments. Unlike the ABH experimental instance, its schedule should be simple, stable, and focused only on the proven configurations. We need a clear, deterministic way to schedule these production tournaments.

Decision​

The Main instance will be hardcoded to run exactly 8 tournaments per day. The scheduling logic will be as follows:

  1. There are 8 base tournament configurations defined in the version-controlled TypeScript configuration files. These are the same base configurations used by the ABH instance.
  2. The Main instance will only run the MAIN variant. It will not run A, B, or H variants.
  3. The instance will cycle through the 8 base tournaments, running each one once per day within its allocated time slots.
  4. This logic is hardcoded and is not dependent on any environment variables.

Consequences​

Positive:

  • Stability & Reliability: The production schedule is simple, predictable, and isolated from the complexity of the experimental instance.
  • Deterministic: We know exactly which production tournament is running at any given time.
  • Resource Efficiency: By running only 8 tournaments instead of 24, the Main instance has lower computational overhead compared to the ABH instance.

Negative:

  • Inflexibility: The schedule is rigid. Adding a 9th production tournament would require a code change.

Mitigation:

  • Stability is Key: For the production instance, stability and predictability are far more important than flexibility. Changes to the production schedule should be deliberate and go through a full development cycle (code change, review, deployment), which this approach enforces.
  • Configuration-Driven Details: While the number 8 is hardcoded, the parameters of each of the 8 tournaments are still controlled by the flexible TypeScript configuration files, allowing for tuning and adjustment without changing the core scheduling logic.