• 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 ?

• 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

• Not too short (overhead dominated)
• Not too long (unlikely ever to be observed) - one or two hours is about right

• 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)
  

• Whole programme not more strict than TAG SQ allocation?
• Individual MSB SQ requirements not less strict than TAG allocation (not fatal, just not effective)

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).

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.