Short answer
An infeasible HiMCM model means no assignment satisfies all your constraints at the same time. On Day 6, do not start deleting constraints to make the solver stop complaining. First prove which constraint set conflicts, then relax in this order: repair data and units, examine hard feasibility boundaries, relax one soft operational target, and only then change the decision scope. Record every change so the final paper shows a defensible model revision rather than a quiet rescue.
COMAP’s contest page for the 2026 HiMCM lists a November 4-17, 2026 contest window and describes a 14-day window in which teams download, choose, model, and submit; teams are not required to use the full window (COMAP, ‘The High School Mathematical Contest in Modeling (HiMCM) and The Middle Mathematical Contest in Modeling (MidMCM)’, accessed November 2, 2026). Day 6 is our planning checkpoint, not a COMAP rule. Around the sixth day of a 14-day window, a team should know whether its core model can produce a feasible recommendation and what must be documented if it cannot.
What infeasible does and does not mean
Infeasibility is information. It says your current model, with its current constraints and data, has an empty feasible set. It does not automatically mean the real-world problem is impossible, the team chose the wrong model family, or the paper is doomed. It may mean that one unit is wrong, one constraint was copied from a different time scale, or one service target cannot coexist with a capacity limit.
The dangerous response is to relax constraints by intuition until the solver returns an answer. That produces a number, not a model. A reader of your paper should be able to reconstruct which constraint was changed, why, what evidence justified the change, and what trade-off the change created. If that trail is missing, the recommendation looks manufactured even when the mathematics is correct.
A constraint-relaxation order for Day 6
- Repair data and units first. Check whether capacity is per trip, per day, or per team; whether demand is in vehicles, people, or trips; and whether the time index is hourly or daily. Use HiMCM Dimensional Analysis: Catching Unit Errors Before Running the Model as a pre-solver audit. If a unit repair removes infeasibility, record it as a correction, not as a sensitivity result.
- Keep hard feasibility boundaries unless you have evidence. Budget ceilings, physical capacity, legal limits, and minimum safety requirements are not decorative. If one of these is wrong, fix it with a sourced reason. Otherwise keep it. A useful assumption register helps separate a modelling simplification from a policy choice; see HiMCM Assumptions: Justify One Simplifying Choice Before You Model.
- Relax soft targets one at a time. Service floors, comfort levels, coverage goals, and convenience targets are often negotiable in a real decision. Change one target by the smallest defensible amount, re-solve, and report the shortfall and who bears it. Then test nearby values so the paper shows a boundary rather than a single convenient number. This is the practical role of HiMCM Sensitivity Analysis: Change One Assumption Without Losing the Decision.
- Change decision scope only with a named trade-off. If the model remains infeasible, the team may need to add a resource, extend the horizon, split the population, or phase the plan. That is a scope change, not a cosmetic repair. Do not relax the objective to fix infeasibility: changing the objective changes the ranking of feasible points, not the feasible set itself.
| Order | Question to ask | Illustrative change | Evidence to record |
|---|---|---|---|
| 1. Data and units | Is this constraint on the same time and unit basis as the variables? | Capacity per trip becomes capacity per day after two trips are scheduled. | Original unit, corrected unit, source of correction. |
| 2. Hard boundary | Is this a physical, legal, or safety limit? | Keep the limit unless a source shows the limit is different. | Why the limit is hard and who owns it. |
| 3. Soft target | Which service goal can move slightly? | Lower one coverage floor from 20 to 15 units. | Shortfall size, affected group, nearby tested values. |
| 4. Decision scope | Can the team add capacity, time, or phasing? | Add a second delivery trip or split the plan by week. | Cost, feasibility, and comparison with the original scope. |
Worked teaching illustration: bike-share delivery
Teaching illustration, not an actual HiMCM problem. A team plans one daily delivery of bicycles to two zones. Let x1 be bicycles sent to Zone A and x2 be bicycles sent to Zone B. Under the single-trip premise, the truck carries at most 40 bicycles, Zone A requires at least 25, Zone B requires at least 20, and both quantities are nonnegative integers. The constraints are:
x1 + x2 ≤ 40; x1 ≥ 25; x2 ≥ 20.
The model is infeasible. Adding the two minimum requirements gives x1 + x2 ≥ 45, but capacity requires x1 + x2 ≤ 40. No nonnegative pair can satisfy both. This is a complete infeasibility check under the stated premises, not a guess.
Now apply the order. First, audit the data. If the 40-bicycle limit is per trip and the team can schedule two trips, the daily capacity is 80, and the original minimums are feasible, for example x1 = 25 and x2 = 20. If two trips were already part of the original plan, this is a data-boundary correction; if the second trip is newly added, it is a scope change (see the diagnostic below). If the single-trip premise is correct, keep the capacity limit and move to a soft target. Suppose Zone B’s 20-bicycle floor is an operational target rather than a safety rule. Relax it to 15. Then x1 = 25, x2 = 15 gives x1 + x2 = 40, so the model is feasible. Zone B receives 5 fewer bicycles than its original target. The paper should report that shortfall, not hide it.
A quick sensitivity check strengthens the example. With x1 fixed at its minimum of 25, the largest possible x2 is 15. A Zone B floor of 12 is feasible, while a floor of 18 remains infeasible. That tells the reader where the boundary lies under the single-trip premise. If the team later adds a second trip, the boundary changes, and the paper should show the new capacity and cost rather than simply replacing the old number.
What to write in the paper after a relaxation
Add a short model-revision subsection. State the original constraint, the infeasibility evidence, the change made, the reason, and the effect on the recommendation. If the team relaxed a service target, include a table or sentence showing the shortfall. If the team changed the scope, compare the original scope with the revised one. Do not present only the final feasible model as if the first model never existed. A transparent revision is stronger than a polished but unexplained number.
Keep the language precise. Write ‘the single-trip model is infeasible because the minimum demands sum to 45 while capacity is 40’ rather than ‘the model failed.’ Write ‘we relaxed the Zone B service floor from 20 to 15 and accepted a 5-bicycle shortfall’ rather than ‘we adjusted the target.’ The first versions tell the reader what was proved and what trade-off was chosen.
Day 6 team decision aid
Run a 45-minute triage. First, freeze the current model: save inputs, code, solver settings, and the exact infeasibility message. Second, name the conflicting constraints in plain language. Third, classify each one as data, hard boundary, soft target, or scope. Fourth, choose the earliest applicable level in the order above. Fifth, assign one owner to record the change and one owner to test a nearby value. Do not let the team split into separate rescue attempts with different spreadsheets; that creates two models and no audit trail.
If the team cannot identify the conflict, reduce the model to a smaller test case. Remove one constraint at a time in a copy of the model, not in the master file. The goal is diagnosis, not publication of the stripped model. Once the conflicting set is found, return to the master file and apply the chosen relaxation there. This keeps the final paper tied to one version history.
Common failure modes
The first failure is deleting a hard constraint because it is inconvenient. The second is relaxing several soft targets at once, which makes the effect impossible to interpret. The third is changing the objective and claiming the model is now feasible. The fourth is reporting only the final feasible run without the original conflict. Each of these makes the paper harder to defend, even if the final recommendation looks reasonable.
Hanlin is an independent coaching provider and is not COMAP. Our teaching advice is to treat Day 6 as a documentation checkpoint: prove the conflict, relax in order, and leave a trace. That habit helps prospective students and parents judge preparation support by whether it produces auditable modelling decisions, not just polished final answers.
Diagnostic: Was the Second Trip a Unit Repair or a Scope Change?
The bike-share case hides a common labeling error. Suppose the team replaces the single-trip capacity of 40 with a daily capacity of 80 because it can schedule two trips. If the original decision already included two trips and the only mistake was writing per trip where the model needed per day, record a data/unit correction. If the second trip is newly added to escape infeasibility, record a scope change: the feasible set moved because the team added capacity, not because the old number was wrong.
Diagnostic question: Was the second trip part of the original plan? Answer: If no, do not call the change a unit repair. Keep the single-trip boundary visible: with x1 fixed at 25, the largest x2 is 15; a Zone B floor of 18 remains infeasible. Then compare the two-trip plan against that baseline and report the added cost or operational burden.
Next practice task: Rewrite the bike-share ledger twice—once with the second trip pre-authorized, once with it newly added. For each version, state the original constraint, the evidence, the affected group, and whether the change is a correction, relaxation, or scope change. This drill trains the exact sentence a reader will use to audit your Day 6 revision.
General event background is available at Event background.
This is an independent preparation guide, not affiliated with, endorsed by, or sponsored by COMAP.
Frequently Asked Questions
What does an infeasible HiMCM model mean?
It means no solution satisfies all current constraints at once. That is a diagnostic signal, not automatically a failed project. On Day 6, identify whether the conflict comes from data, units, a hard boundary, a soft target, or the decision scope before changing anything.
Should we relax the objective to make an infeasible model feasible?
No. Changing the objective changes how feasible solutions are ranked; it does not create feasible solutions. To address infeasibility, repair data and units, reconsider a soft constraint with evidence, or change the decision scope and report the trade-off.
How many constraints should a team relax at once?
Relax one constraint at a time. If two constraints are definitionally linked, treat that single linked change as one step. Record the original value, the new value, the reason, and the effect on the recommendation. Testing nearby values shows whether the decision is stable or sits on a narrow boundary.