Your observing programme will consist of MSBs – Minimum Schedulable Blocks – and it is the responsibility of your support scientist to vet these blocks on various criteria. The following tables outline these; they will be used for reference by your support scientist and so if you ensure that your MSBs pass this test before submission, you will have avoided one time-wasting iteration and your observations will be avialable for execution  at the telescope sooner.

Short list for Support Scientists’ Reference

Functionality	Do the MSBs actually work ? (Spot checks within 20% of submitted MSBs) –suitable standard stars are included -enough/not too many flats and arcs for spectroscopy –exposure times and arc/flat settings are Defaulted, – slit PAs match between object, standard -UIST spec acquisition – only use image acquisition for K>10 –offset pattern is sensible (i.e. along slit, not across it if that’s the intention) -does the program Validate ok ?
Target lists	-Check for consistency with PATT Proposal -Spot check of guide stars: correct location and no corrupted coords -Spot check of guide stars: offsets to sky (if present) large enough to drop the guide star and thus avoid overhead of crosshead offsetting
MSB Length	–Not too short (overhead dominated) –Not too long (unlikely ever to be observed) – one or two hours is about right
Documentation	MSB Observer notes -include the required information in the four detail boxes (position accuracy etc.) -complement the Project summary page -include important info for observers on techniques (e.g. acquisition) -state clearly whether S/N or execution time is most important -leave no room for doubt as to what is required -nothing has been left in non-show-to-observer notes which should have been made public (e.g. instructions to do offsets at the telescope)
Site Quality	-Whole programme not more strict than TAG SQ allocation? -Individual MSB SQ requirements not less strict than TAG allocation (not fatal, just not effective)
Scheduling	Not too restrictive (don’t preclude observation before PI reaches summit (in relevant cases))

Full descriptions where appropriate

Item	Comment
Length	The most appropriate total time for an MSB will depend on both the science you need to achieve and on the way MSBs  are selected at the telescope. The QT selects on the basis of science priority, from a list of MSBs whose site quality and scheduling constraints are met at the time, and which can be observed in their entirety in the time remaining in the night. You will have been told in which quartile you fell in your TAG feedback. Whether or not you have been granted summit occupancy, one or two hours is a sensible average length for an MSB, all else being equal and as long as this is consistent with your science: MSBs which are needlessly long will have their earliest chance of execution later in the semester than it need have been. Similarly a single target requiring eight hours of on-source integration is best split into few-hour MSBs as long as there is no science-driven reason (variability etc.) to keep it together. If you have a large sample of objects which are observable quickly, it is perfectly sensible to include a few in each MSB (for example to ensure the sharing of a standard star), but we suggest keeping the total length of each MSB to within a few hours for the reasons stated above. MSBs which are too short (ten minutes, say) will result in a considerable observing overhead (and your programme will be charged for this).
Documentation	Your support astronomer will check that the comments attached to your MSBs give adequate guidance to the summit observer; please put yourself in the astronomer’s place and consider whether your notes will be useful, before submitting. Some specific notes follow: Observers will be told to assume that your MSBs are logically separate – so if there’s a desire to combine (say) JHK with L from separate MSBs if this is possible, they should be told so. This could be put in the programme’s logic (using AND and OR folders) but you may wish to keep it informal, as a “wish” rather than a “need” in the case where your programme’s internal priorities are all equal. Don’t overuse this but notes are a possible way to communicate this sort of information to observers. Each “Show to Observer” note comes with four boxes, in which you must detail your positional accuracy, appearance of the target (in the infrared in the case of UIST programmes), etc. Notes in MSBs should be complementary to those in the project summary page. The latter are an important first filter (observers should not be spending time fetching MSBs only to find that they don’t feel comfortable with the observing – so they should be given as good an understanding of what’s involved as we can in the web page). Support astronomer will occasionally ask you to add certain things to your MSB observer notes. These will in most cases be specific to the observing mode, acquisition method etc., and you would not be expected to know them (but they will be useful for the observer at the summit). By default the observer is not going to make decisions for you on signal-to-noise – so if they get to the end of an MSB and the required s/n has not been reached, they will move on and do something else. This might miss you a chance of completing a key observation, so if you want to control things at this level, please make sure that your comments are clear.
Site quality constraints	You can specify site quality more strict than the TAG has allocated you, but if this is done for your whole programme, it will be picked up by our check and the programme will not be allowed into the queue. Specifying constraints looser than the TAG allocation will not work; the QT knows the TAG requirements independently of your MSB site quality information.
Scheduling constraints	Constraints which are too restrictive will be vetoed (for example, we will not accept constraints placed such that the MSBs only become available when you reach the summit).