This kind of work--validation--in the development cycle is greatly simplified if a solution is already available to you. With a known solution in hand, you can check the way that your constraints have been written so that you will be alerted to any errors in interpretation or any bug in translation between the specifications and the implementation. You can also check the global coherence of your initial constraints, their coherence as a set. That is, when you have a known solution already, you can use it as a reference point in testing and verification.

Once you have validated it, your first model itself will play the role of a reference. It will enable you to test new solutions that you get from the implementations you develop.

Since your first model will play this role in verification, you really should not use any idiosyncratic tricks or "dirty" coding practices at this point. Such practices will prove troublesome later when you try to modify this first prototype. Moreover, such tricks diminish confidence in the robustness of any solutions that you get. How do you avoid the sort of programming tricks that we counsel against here? One way is to work in a plain, declarative style. Don't create new, unconventional constraints; instead, use the predefined constraints you'll find ready in Solver.