Key takeaways
- Fix critical static data errors before optimisation.
- Pass dynamic analysis before trusting the solver.
- Use feasibility checks such as block build, combing chart, and what-if.
- Run at least two test migrations: one to find gaps, one to confirm fixes.
What should happen before optimisation?
Fix critical static data errors first. Then pass dynamic analysis. The verified rule is clear: critical issues block a feasible result.
This protects solver time and avoids treating data errors as timetable design problems.
Which checks are grounded for this guide?
Keep the pre-solver gate focused on the checks named in the source material.
- Critical static data error checks
- Dynamic analysis
- Block build feasibility check
- Combing chart feasibility check
- What-if feasibility check
- At least two test migrations
How should planners sequence the pre-solver gate?
The gate should prove that the structure is fit for an automatic solve.
- Run the first test migration.
- Fix mapping and data-quality gaps found by that test.
- Run the second test migration to confirm the fixes.
- Fix all critical static data errors.
- Pass dynamic analysis.
- Run feasibility checks before starting optimisation.
Why use block build, combing chart, and what-if?
These feasibility checks help prove that the timetable structure can schedule before planners trust the automatic solve. They are not decoration around the solver. They are part of proving the model is feasible enough to try.
If these checks show structural problems, fix the structure before optimisation.
Why run two test migrations?
The first test migration reveals mapping and data-quality gaps. The second confirms that the gaps have been fixed. Skipping the second test can leave planners unsure whether the repair worked.
Use the findings with data cleanup before the solver run.
What question does this guide answer?
This guide answers one question: what must be validated before planners trust an automatic solve?
It does not cover solver comparison. The grounded scope is critical static data, dynamic analysis, feasibility checks, and repeated test migration.
Questions planners ask before running the solver
What should block a solver run?
Critical static data errors should block the run because critical issues can prevent a feasible result.
What checks prove the structure can schedule?
Use feasibility checks such as block build, combing chart, and what-if before trusting an automatic solve.
How many test migrations should we run?
Run at least two. The first exposes mapping and data-quality gaps. The second confirms those gaps have been fixed.