Policies for the Telescope Time Review Board

The JWST Telescope Time Review Board (TTRB) reviews requests to change accepted JWST programs, duplicate observations,  repeat observations, and other program alterations. This page also describes process for Operation Problem Reports (OPRs), Program Change Requests (PCRs), and requests for Resolution of Data Duplications (RDDs).



Process for Reviewing Program Changes

Changes to approved JWST programs are evaluated, discussed, and reviewed by the Telescope Time Review Board (TTRB), which is composed of staff members from the STScI divisions that schedule the telescope and support science observations.

The TTRB makes recommendations based on the policies in this document, and in the JWST Observing Program Modification Policy. The TTRB exists to maximize the science return of JWST within approved policy, but has limited latitude to deviate from established precedent. TTRB recommendations are forwarded to the Head of the Science Policies Group (HSPG) for approval. Following this review, the TTRB acts to carry out the final decision that has been made. 

The Domain of the TTRB

Observing time on JWST is allocated by the Director of STScI. Ordinarily this is done in one of three ways:

  1. Through a Call for Proposals, with review by a TAC;
  2. Following a submitted proposal for Director's Discretionary Time, after suitable scientific review;
  3. Through an internal review of calibrations that are requested and defined by the instrument teams.

Each of the above three ways leads from a submitted proposal to an approved program, with a specific allocation of JWST time, ordinarily in units of hours. Also, specific programs are approved to observe specific targets with particular instrument modes and parameters. 

Inevitably changes must be made in some programs after they are accepted, and the TTRB exists to review these and make recommendations to the HSPG, who may approve on behalf of the Director’s Office. Some of the reasons for changes include:

  1. Failure of an observation. The failure or anomaly may have occurred during program implementation, in the ground system, or as a problem on the spacecraft.
  2. Alteration of a program to use a different filter, grating, or even a different instrument.
  3. Addition of a new target to a program or changing one target for another.
  4. Changes that result from knowledge of the SI or telescope that was not available at the time the proposal was written, requiring, possibly, additional telescope time to achieve the approved science goals.

Some of these changes are minor and need only the approval of the program coordinator or Contact Scientist (CS), but major alterations to a program require formal approval. Full details are given in the JWST Program Modification Policy.



Types of Program Alterations Treated

Reporting Mechanisms and Procedures

Matters come to the attention of the TTRB through a formal reporting mechanism that is invoked using a web form. The program Principal Investigator (PI), or designee, enters basic program information, an explanation of the nature of the action requested, and the reasons for the action. The web submission software adds additional program information from a database, and the members of the TTRB are notified that a new request has been submitted through automatic e-mail. 

The Chair of the TTRB, in collaboration with the other members of the TTRB, reviews the request and prepares a recommendation. A CS, Program Coordinator (PC), or other STScI experts may be consulted as needed during this review. After the appropriate consultation has taken place, the Chair may, if necessary, request further information or clarification from the PI. The recommendation of the TTRB that was reached through this process is communicated by the Chair to the HSPG for concurrence. In some cases, the HSPG may modify the recommendation. Upon concurrence, the Chair of the TTRB notifies the PI of the outcome. 

Types of Issues Treated

All the issues treated by the TTRB are reported with the same mechanism, and at the time it is submitted it is assigned a tracking number through the STScI Problem Reporting System, of the form WOPR Number 12345, Duplication Report Number 12345, or Change Request Number 12345. A different form exists for each type of request. 

Webb Operations Problem Report (WOPR)

Proper documentation of WOPRs is vital for follow-on studies that enable us to reduce causes of failed observations. Policies and procedures for WOPRs are well established and are described in WOPR Procedures below.

Program Change Request (PCR)

Most changes to programs that are made after submission and acceptance are minor alterations, such as changing an exposure time, using a different filter, or adding certain Special Requirements. As described in the JWST Observing Program Modification Policy, these types of minor modifications may be approved by an CS without further review, and some may be implemented by the PC. For those PCRs involving minor instrument technical issues, the relevant instrument team will be consulted and may provide a recommendation to the TTRB on the resolution of the PCR. Procedures for are described in PCR Procedures below.

For program changes that are clearly significant, as defined in JWST Observing Program Modification Policy, the PI must initiate a formal Program Change Request. These types of alterations ordinarily require a PCR: 

  1. Increasing the allocation of primary or parallel time above the numbers allocated by the Director. Requests for increases in primary hours will be rare and will require strong scientific justification.
  2. Contesting a mandatory comment made by the TAC.
  3. Adding a target to a program. Reallocation of time among an already-approved list of targets (i.e., if they were specified in the proposal) may also require TTRB approval if the reallocation might have a significant impact on schedulability.
  4. Changing instruments or a significant change of instrument mode.
  5. Adding limited-resource Special Requirements that were not indicated in the proposal. These include CVZ, TOO, SHADOW, and LOW SKY.
  6. Adding other options, parameters, or Special Requirements that substantially increase the constraints on scheduling a program.
  7. Any change that requires an observation to be made outside of the nominal start or end times of the Cycle for which it is approved, or any request by a PI to start a program before the start, or after the end, of the Cycle. Multi-year programs are, by definition, pre-approved to extend beyond a single Cycle boundary. 

STScI’s concerns are in two areas. First, we wish to understand if a change significantly alters our ability to schedule an observation. Second, the Institute needs to ensure that a change does not go beyond the scope of the program originally proposed and does not infringe on the science of another program. 

Resolution of Data Duplication (RDD)

A GO, CS, or PC can file an RDD whenever they feel that two separate observations in separate programs may duplicate one another, or if there are conflicts in data rights that arise.

We will expect GOs to investigate for other current-Cycle programs that may conflict with their own, and the RDD is the mechanism for adjudicating these. 



WOPR Procedures

A WOPR  is ordinarily submitted by an observer, but may also be submitted by an Instrument Scientist (IS) or Program Coordinator (PC), or, possibly, a Co-I, especially one who happens to be an STScI staff member. In any of these cases the WOPR will be considered to have been effectively submitted by the PI. A WOPR is submitted when a problem is found with the observation, either in the way the observation was (or was not) executed, or in the data received. 

WOPRs are submitted by navigating to the JWST Program Information webpage, searching for the appropriate program, and selecting Report an Observing Problem link in the Request section of the program page.

Automatic Repeats

A WOPR generally requests that an observation be repeated, but some failures are of a nature which makes a WOPR unnecessary. Such errors are identified immediately after the observation fails and are automatically rescheduled. However, an automatic rescheduling only occurs if the visit had no science data at all obtained and no guide star acquisition was attempted. Failed observations that have been automatically rescheduled are made known to the TTRB for nominal review.

Failures which are eligible for automatic repeat are

  1. Visits affected by a spacecraft or instrument safing event, as long as the entire visit was lost and as long as the program itself did not cause the safing.
  2. Visits lost due to other spacecraft malfunctions, as long as the entire visit was lost and as long as the program itself did not cause the malfunction. 

Policies for Granting Requested Repeats of Observations

Type of Observation

Repeats are not normally granted if the failed observation was a SNAP observation

Completeness of program

Repeats are not ordinarily granted if a program is already 90% complete. “Complete” here means that 90% or more the observing time allocated to the program has been successfully executed at the time the OPR is evaluated. Scheduled observations that have not yet executed are not ordinarily counted as “complete,” although they may be in some circumstances as, for example, when the lifetime of an instrument is near an end and the remaining schedulable time is highly constrained.

The failure of less than 10% of a program’s orbits is not grounds for automatic rejection of an OPR. However, an OPR that requests more than 90% completion needs to indicate clearly why the repeated observations are essential to achieving the scientific goals outlined in the original proposal. 

Incorrect target coordinates

A program’s PI is responsible for generating target coordinate charts in APT so that the PI may verify the coordinates of the target being observed. Some targets (especially bright ones) may be difficult to evaluate on these charts, but in all cases the PI remains responsible for supplying complete and correct target coordinates in the proper units, and the source of those coordinates must be included as well. In the case of targets with significant proper motion, the PI is responsible for providing both the epoch of the coordinates and the proper motion values in the correct units. Therefore, WOPR requests that involve incorrect target coordinates or proper motion values are not ordinarily approved.

Program error by STScI

If the observation failed due to an error originating within STScI, or an operational problem with the telescope, repeats are ordinarily granted. In some cases, such as instrument failures or other hardware problems, repeats may be undertaken automatically.

Program error by PI

If the failure was caused by an error that can be shown to originate with the PI (or designee), then a repeat will not be granted. STScI attempts to detect observer error on a best- efforts basis, but errors nevertheless remain the PI’s responsibility.

High-risk observations

Some accepted programs are unusually difficult to implement or may face a higher-than-normal chance of failure. In these cases the PI will be notified before the observations are obtained, and the observations are then executed on a shared-risk basis. This means that repeats will not ordinarily be granted if an observation fails. In some cases, high-risk programs may be brought before the TTRB before they are implemented. 

Release of Data

Under most circumstances, if a repeat is granted then the original (“failed”) observations will be made immediately available to the public in the archive. If a repeat is granted for an entire program, then all of the data acquired so far are released. The intent is that if the observations are good enough to do the science that the PI proposed then they should not be repeated, and that a PI should not be given preferential access to duplicate observations. Thus if a repeat is given, the data are acknowledged to be inadequate for the original purposes and may therefore be made freely available without impairing the PI’s science goals. The PI may request a repeat with no release of the original data, but supporting arguments must be provided. 

Deadlines for WOPR Submission and Program Resubmission

OPRs must be filed within 90 days of the date when the affected observations failed. A repeat will not be granted if this period is exceeded unless the PI can provide clear evidence of why it was impossible to file the WOPR within the 90 days. In cases where the end of an operating mode is imminent, a specific WOPR deadline may be imposed beyond which no WOPRs whatsoever for that instrument will be accepted simply because repeats cannot be scheduled.

If a repeat has been granted, the PI has six weeks in which to supply a revised program. If no changes to the original observation are needed, a new submission is not necessary, but the PI must still contact the PC to so indicate. 

Change Request Within WOPRs

A request to repeat an observation may also include a request to change the way in which the observation was obtained or the target observed. Such change requests after the fact are unlikely to be granted unless convincing arguments are presented that require the changes to be made to the observing plan (as opposed to changes that improve the observing plan). In other words, Change Requests should be filed well before observations are taken. 



Program Change Requests (PCRs)

A formal PCR should be filed whenever an alteration to a program significantly changes its ability to be scheduled, if a limited resource is requested, or if a change might result in a data conflict or duplication issue.

PCRs are submitted by navigating to the JWST Program Information webpage, searching for the appropriate program, and selecting Request an Observing Change link in the Request section of the program page. See JWST Observing Program Modification Policy for further details.

Late change requests

A Change Request to a program must reach STScI at least four weeks before the first day of the planning window for that proposal. If a Change Request is received after this date and the observations then fail because the change was not implemented, no repeat will be given. Even if STScI agrees to attempt a late implementation of a Change Request, it is done on a best-efforts basis and the PI is still responsible for the error if problems arise. 



Duplication or Data Conflict Resolution

An RDD is the mechanism for bringing a duplication to the attention of the TTRB. The grounds for declaring a potential duplication are established elsewhere (see the most recent JWST Call for Proposals). 



References

Adopted from Policies for Telescope Review Board, rev. January 28, 2015, Taylor and Soderblom. Available on the HST Changing Programs & Resolving Problems site.