ALMA Doc 5.16, ver. 1.0 | March 2017

ALMA Users’ Policies

ALMA, an international astronomy facility, is a partnership of ESO (representing its member states), NSF (USA) and NINS
(Japan), together with NRC (Canada), NSC and ASIAA (Taiwan), and KASI (Republic of Korea), in cooperation with theRepublic of Chile. The Joint ALMA Observatory is operated by ESO, AUI/NRAO and NAOJ.

For further information or to comment on this document, please contact your regional Helpdesk through the ALMA User
Portal at www.almascience.org. Helpdesk tickets will be directed to the appropriate ALMA Regional Center at ESO,NAOJ or NRAO.

Version
1.0

Date

Editors

March 2017

Cox, P., Corder, S., Carpenter, J., Nyman, L., Andreani, P.,
Tatematsu, K., Remijan, A.

In publications, please refer to this document as:
Cox et al. 2017, ALMA Users’ Policies, ALMA Doc. 5.16.v1.0

Table of contents
1 Purpose and Scope ................................................................................................................................ 3
2 ALMA Users .............................................................................................................................................. 3
2.1
2.2

Non-registered ALMA users ....................................................................................................................... 3
Registered ALMA users ................................................................................................................................ 3

3 User Support ........................................................................................................................................... 44 ALMA Proposal Preparation and Submission ............................................................................. 4
4.1
4.2
4.3
4.4

Eligibility and responsibility ..................................................................................................................... 4
Proposal Time Assignment ........................................................................................................................ 5
Science categories ......................................................................................................................................... 5
Proposal submission: Phase 1................................................................................................................... 5

5 ALMA Proposal Selection .................................................................................................................... 6
5.1
5.2
5.3
5.4
5.5

Assessment criteria....................................................................................................................................... 6
Duplications..................................................................................................................................................... 6
Descoping ......................................................................................................................................................... 7
Proposal Assessment.................................................................................................................................... 7
Outcome ............................................................................................................................................................ 8

6 Preparation and Execution of ALMA Observations ................................................................... 8
6.1
6.2
6.3
6.4
6.5

Observation preparation: Phase 2........................................................................................................... 8
Observation scheduling ............................................................................................................................... 9
Quality Assurance, project completion and carry-over ................................................................... 9Time accounting .......................................................................................................................................... 10
PI errors ......................................................................................................................................................... 10

7 Changes to ALMA Proposals............................................................................................................ 11
7.1

Project withdrawal..................................................................................................................................... 12

8 ALMA Data Delivery and Data Rights .......................................................................................... 12
8.1 Data property ............................................................................................................................................... 12
8.2 ALMA proposal data ................................................................................................................................... 12
8.3 Observational metadata ........................................................................................................................... 12
8.4 Observational data ..................................................................................................................................... 13
8.4.1 Observational data access and proprietary periods .............................................................................. 13
8.4.2 Stale Data ................................................................................................................................................................. 13
8.4.3 Problems with delivered data ......................................................................................................................... 14
8.4.4 Extension of Proprietary periods................................................................................................................... 14
8.5 Calibration data ........................................................................................................................................... 15
8.6 ALMA Test and Science Verification Data .......................................................................................... 15

9 Confidentiality of Information ....................................................................................................... 15
10 Publication of ALMA Results ........................................................................................................ 16
10.1

Naming convention of sources discovered by ALMA ................................................................... 16

11 Final Provisions ................................................................................................................................ 16
A. Appendix: Definition of a Duplicate Observation .................................................................. 18

2

1 Purpose and Scope
This document defines the long-term core policies for use of the Atacama Large Millimeter/submillimeter
Array (ALMA) and ALMA data by the science community. Cycle-dependent implementation parameters andprocedures are detailed in the Call for Proposals documents for each cycle: the cycle announcement, theProposer’s Guide, and the Technical Handbook. In case of conflict between the Call documents and theUsers’ Policies, the latter takes precedence, unless explicitly indicated otherwise. All ALMA users are subject
to the Users’ Policies described here and in the Call documents. Violation of these policies by a user may
result in sanctions against scientific project(s) under evaluation or execution in which he/she is involved.

2 ALMA Users
A number of ALMA resources are available to unauthenticated users (unregistered users, or users who are
registered but have not logged in). Registering with ALMA confers authenticated users the privilege toaccess additional documents and services.

2.1 Non-registered ALMA users
Users do not need to be authenticated to access ALMA non-proprietary data, documentation, tools, or the
Helpdesk Knowledgebase articles listing solutions to common questions and problems.

2.2 Registered ALMA users
Anyone can register for an ALMA user account. Each user may only have a single ALMA account, which is
identified by a unique, user-selected username. This username is permanent: a user may not change his/herusername after he/she has completed the registration process. To register, a user must provide his/her full
name, a valid email address, and the country of his/her affiliation or the country of residence (for users notaffiliated with a scientific institution). The Observatory has experienced that often ALMA official notifications
end up in the spam folder of users’ emails whose addresses belong to commercial servers. The Observatory
reserves the right to refuse any complaint from users entering such email addresses in the user profile.
Users are required to update their ALMA user profile whenever there is a change in their personal details,
such as a new email address or a change of affiliation. Users are responsible for ensuring that their profile iscorrect, and are requested to contact ALMA staff through the Helpdesk if they encounter problems or todelete unnecessary, duplicated, profiles.
By default, all authenticated ALMA users may:
• Access user profile and password management;• Participate as PI, Co-PI, or Co-I on ALMA proposals;• Access project tracking tools to monitor the status of their projects;• Submit Helpdesk tickets;• Access their proprietary data.
In addition, ALMA may assign specific roles to selected registered users that provide additional privileges.
For instance, ALMA Proposal Review Committee (APRC) and ALMA Review Panel (ARP) members are
assigned the role of Science Assessor, which allows them, for the ALMA cycles in which they serve, to run
the Proposal Handling Tool to access and review proposals and submit their proposal assessments.
3

3 User Support
User support is provided by the ALMA Regional Centers (ARCs) and ARC nodes.
The country specified in the user’s profile constrains which ARC will provide his/her support. Users from acountry within the three Executives (EA, EU or NA, see Sect. 4.4) are automatically and compulsorily
assigned the ARC of their Executive for support. Users from Taiwan may elect either the EA ARC or the NA
ARC as their support ARC. Users outside the three ALMA Executives, including Chilean users, may choose any
Executive ARC as their support ARC.
Questions should be submitted to the corresponding ARC through the ALMA Helpdesk. Any potentiallysensitive information communicated to ARC staff or submitted to the Helpdesk regarding the user or
proprietary project details are held in the strictest confidence. Information submitted through the Helpdesk
can only be accessed through a secured database by ARC-affiliated staff.
ARC-affiliated staff are the interface between ALMA users and the Observatory for all communications.
Users are prohibited from contacting the Joint ALMA Observatory (JAO) or telescope operations staff – Array
Operators or Astronomers on Duty – for issues related to any project, including project execution, proposal
submissions, change requests, etc.
An exception to this rule is allowed for Target of Opportunity (ToO, see http://almascience.org/documentsand-tools/latest/alma-proposal-review-process for a definition of proposal types) projects or special
observing campaigns (e.g. Solar, VLBI), for which the Astronomer on Duty (AoD) may contact the PI if there
are important questions regarding the execution of the observations. In this case the communication
proceeds via Helpdesk at a dedicated department continously staffed.

4 ALMA Proposal Preparation and Submission
This section details policies that govern proposal preparation and submission and time assignment.
4.1

Eligibility and responsibility

Registered users of any professional background, nationality, or affiliation may submit ALMA proposals:
students, postdoctoral researchers, professionals, and non-professionals. Each proposal must identify asingle individual 1 who will serve as Principal Investigator (PI). The PI will act as the official contact between
ALMA and the proposing team for all proposal correspondence. Proposals may include any number of CoInvestigators (Co-Is) and, for Large Programs and VLBI Proposals (see http://almascience.org/documentsand-tools/latest/alma-proposal-review-process), Co-Principal Investigators (Co-PIs). Additional rules,
described at http://www.das.uchile.cl/das_alma_crc.html, apply for qualification to use the Chilean share of
the time. Proposals submitted by a proposer with a Chilean affiliation that do not qualify to use the Chilean
share of time will be eligible as Open Skies proposals (see Sect. 6.4).
1 Single individual is understood as a single person, i.e. proposals submitted by a consortium are not valid. Instead, aperson within the consortium should submit the proposal and act as PI and any other consortium members will act as
co-Is or co-PIs (if the proposal type allows them).

4By submitting a proposal, the PI takes full responsibility for its contents, in particular with regard to the Co-PI
and Co-I names, and agrees to act according to the ALMA policies and procedures, as defined in thisdocument and in Proposal Call documentation. In particular, the PI accepts the limitations of the observing
capabilities and operational restrictions applicable for the cycle for which he/she submits a proposal.
Co-I and/or Co-PI names cannot be added to or be withdrawn from the proposal after the proposal deadline.
PI responsibilities include proposal submission and, for approved projects, submission of Phase 2 products(see Sect. 6.1) and proposal change requests (see Sect. 7). These responsibilities may only be transferred to
Co-PIs or Co-Is in the case of emergencies (e.g. sickness) or status change (e.g. retirement). They may not betransferred for non-urgent circumstances (e.g., sabbatical or science leave, vacations). Requests to transfer
PI responsibility should be sent to the ALMA Helpdesk.
The project PI may delegate the following PI privileges on a project basis to one or more ALMA registeredusers:• Access to proprietary data (see Section 8.4);• Email notification of state changes to an approved project.
These privileges are delegated through the Science Portal (SP) user profile “Project Delegation” interface.
PIs, Co-PIs, and Co-Is may all track the progress of their proposals via the Snooping Project Interface (SnooPI)
and are entitled to receive help from or discuss project details with ARC staff.

4.2 Proposal Time Assignment
Proposal types and the policies related to the time allocation are described in a document approved by the
ALMA Board which is publicly available in the ALMA Science Portal (http://almascience.org/documents-andtools/cycle4/alma-proposal-review-process). There may be cycle-dependent limits on the time allocated for
proposals of different types (e.g. using non-standard modes, Large Programs, stand-alone ACA). These will
be described in the Proposer’s Guide for each cycle.

4.3 Science categories
For each cycle, ALMA will define a limited number of broad categories and keywords for the scientificcharacterization of each proposal. These are used to facilitate the proposal review process. The relevantscience categories and keywords are announced in the Proposer’s Guide for each cycle. The PI must select a
relevant category before submitting a proposal. The JAO may re-assign a proposal to a different categorythat it deems more appropriate.

4.4 Proposal submission: Phase 1
Proposals are generated and submitted using the ALMA Observing Tool (OT). This is known as the “Phase 1”
process. The capabilities and most of the observing mode restrictions in the proposal call documentation are
designed into the OT. If inconsistencies exist, the Proposer’s Guide takes precedence.
Only proposals that conform to the prescribed format, that are submitted through the proper OT version,that comply with the advertised technical constraints and restrictions, and that are received before thesubmission deadline will be considered.

5

The final proposal submission deadline is firm – proposals submitted after this deadline will not be accepted.
Proposals for Directors Discretionary Time (DDT) do not have a specific deadline.
Except for DDT proposals, a submitted proposal can be resubmitted any number of times until thesubmission deadline. When a proposal is resubmitted, the previous version is overwritten. DDT proposal
submission is final; DDT proposals cannot be resubmitted.
Multiple submissions of the same proposal using different regional affiliations (see Sect. 6.4) are notallowed. If such proposals are detected, the first submitted version will be considered, and the remaining
proposals will be ignored.
Proposals accepted in the previous cycle for which observations have not been completed by the proposal
deadline can be resubmitted in the new cycle. If accepted and some SGs were successfully completed in theprevious cycle, the relevant portion of the new cycle proposal will be cancelled.

5 ALMA Proposal Selection
ALMA proposals other than DDT are subject to international peer review by the ALMA Review Panels (ARP)and the ALMA Proposal Review Committee (APRC). Panel members are appointed by the ALMA Director
with the approval of the Directors Council and a designated representative of the Chilean astronomicalcommunity. These appointments will strive to ensure appropriate representation of the ALMA regions.
JAO and ARC staff cannot be members of the APRC or ARP. Further, the APRC chair may not also be amember of any ALMA science advisory committee or the ALMA Board.

5.1 Assessment criteria
ALMA proposals are assessed on the basis of the overall scientific merit of the proposed investigation and its
potential contribution to the advancement of scientific knowledge, as well as on the extent to which theplanned observations exploit the advertised ALMA capabilities. Review panels will be instructed not toconsider voluntary waivers of the proprietary period in ranking the proposals. ALMA will not reduce the
proprietary period in the archive even if an approved proposal requests it. The above holds for all proposals,
including Large Programs. The ALMA Director can waive the proprietary period for a proposal in exceptional
circumstances.
Further description of this process can be found in the Principles of Proposal Review Process document in
the ALMA Science Portal (http://almascience.org/documents-and-tools/latest/alma-proposal-reviewprocess).

5.2 Duplications
In order to ensure the most efficient use of ALMA, duplicate observations of the same location on the sky
with similar observing parameters (frequency, angular resolution, coverage, and sensitivity) are notpermitted unless scientifically justified. Archival data should be used whenever possible to accomplish thescience goals of a proposed investigation. Detailed criteria of what constitutes a duplicated observation are
specified in Appendix A of this document.
It is the responsibility of the proposers to check the proposed observations against the previously executed
programs in the Archive and accepted grade A programs to avoid duplicate observations. Proposers cannot
6be penalized for proposing duplications of previous Cycle observations if they had no way to know about
them by the proposal deadline. Any proposed duplicate observation must be justified within the Scientific
Justification of the proposal. PIs are also advised to justify their proposed observations in cases where they
are similar to previously executed or accepted programs but are not formal duplicates. The ALMA Review
Panels will determine if the requested duplicate observation is scientifically justified.
Duplicate observations may result among proposals submitted within the same Cycle. In these cases, the
ALMA Proposal Review Committee (APRC) will determine if the duplicate observations are scientificallynecessary. If not, the APRC will determine which proposal has priority. In general, the higher ranked
proposal will be given priority, but regional shares may be considered for closely ranked proposals. The
final decision of which proposal is awarded time will be determined when the observing queue is formed,
which factors in the share of time available to each region.
Examples of duplicate observations that may be approved include:• Synoptic observations of time-variable phenomena.
• A large-area survey where cutting out a smaller area to avoid overlap with a previous observation
will make the observation inefficient and increase the overall execution time.
• Spectral scan surveys where excluding a frequency range covered by a previous observation will
make the observation inefficient and increase the overall execution time.
For proposals within the same cycle, the proposal that stands to lose the proposed duplicate observation
will normally not have access to the data from the other proposal until the proprietary period has expired.

5.3 Descoping
Projects may be descoped as a result of the review process by the APRC. Descopes will be made only forcompelling scientific or technical reasons. This includes duplications with existing data or with a higherranked project from the same cycle. If any part of a project should be descoped because of duplication, thismust be clearly stated by the panel review committee and included in the consensus report sent to PIs.
Project descoping must be done without adding science goals to a proposal. Proposal descoping will only bedone on entire SGs. However, parameters will not be changed for a subset of targets within a science goal
(e.g. remove one spectral window or change the correlator setup or requested resolution and sensitivity fora subset of targets in a science goal).

5.4 Proposal Assessment
Each proposal is assigned a letter grade as a result of the proposal review process as described in the
Principles
ofProposalReview
Process
document
in
the
ALMA
Science
Portal(http://almascience.org/documents-and-tools/latest/alma-proposal-review-process). Grades A, B and C will
be assigned based on scientific rank, Executive balance, and scheduling feasibility. Proposal grades affectscheduling priority, with proposals with A grades having the highest priority and proposals with C grades
having the lowest. All other proposals will not have Phase 2 (see Sect. 6.1) SBs prepared and not be
considered for scheduling at the telescope. Specific details of grade assignments will be given in the
Proposer’s Guide for each cycle (Section 6.5.3).
Technical assessments will be done on a subset of the submitted proposals before the proposal review
meetings. The ALMA Observatory may declare any type of observation that does not conform to the7advertised capabilities technically infeasible at any stage of the Proposal Review Process or during “Phase 2”(Scheduling Block preparation; see Sect. 6.1). The final decision on project infeasibility will be taken by the
ALMA Director, based on the advice from a small standing committee consisting of senior staff at the JAO,
and cannot be appealed. PIs of proposals found to be infeasible will be notified by email with a descriptionof the technical issue.

5.5 Outcome
An email notification will be sent to the PIs that will include the consensus report from the ALMA review andthe assigned letter grade. The outcome of the proposal selection process is final.
In case of questions about details in the consensus report, the PI may submit a request for clarification
through the ALMA Helpdesk. However, in no case will such a request lead to a revision of the grade assigned
to the proposal.

6 Preparation and Execution of ALMA Observations
This section details policies that govern the preparation, execution, and quality assessment of approved
projects.

6.1 Observation preparation: Phase 2
Once a project has been approved for execution, it passes into Phase 2.
The PI will retrieve the project from the archive with the OT, and use the OT to check and approve the Phase
2 material following the guidelines provided through the SP (see Phase 2 QuickStart Guide and User's Guide
to ALMA Scheduling Blocks). These guidelines describe any allowed changes that may be made by PIs withrespect to the submitted proposal before the Phase 2 material is generated. Any changes to a project
mandated by the proposal review process (as described in the consensus report) or motivated by technicalconsiderations will be made by ALMA staff. PIs may contact ALMA staff at any time for questions or
recommendations regarding checking and generating Phase 2 material.
Once the SBs are prepared and reviewed, the PI has the responsibility to submit them through the OT to the
ALMA archive. This submission constitutes the PI approval that the SBs are valid for scheduling on thetelescope. ALMA staff may modify submitted projects for technical reasons (e.g. to improve the efficiency ofthe observational setup). If such technical modifications may affect by any means the scientific output (e.g.
moving slightly the spectral windows from the band edge) of the project, the PI will be contacted to approvethe modified SBs.
Non-minor changes to a project that are not mandated by the proposal review process or technicalconsiderations may only be made after the approval of a PI-initiated Change Request (Section 7).
If the PI does not approve the Phase 2 products within the given deadline as indicated in the email
notification, the project may be downgraded to the next lower grade (from A to B, from B to C, from C to U).

86.2 Observation scheduling
Science observations will be executed by ALMA operations staff, taking into account the weather conditions,the array configuration, target elevation and other practical constraints, the project grades and the
Executive balance. All other things being equal, the highest grade proposal will be observed first.
The individual Scheduling Blocks (SBs) of projects with grades A-C will be observed until one of the following
three criteria are met:
1. The data are determined to meet the user specified criteria (see Sect. 6.3)
2. The potential scheduling period has ended (one observing season for grade B and C projects, twoobserving seasons for grade A projects)
3. There are no more 12-m Array configurations planned for the rest of the scheduling period thatmatch the Scheduling Block angular resolution requirements or time constraints have expired.
If a project has been observed for more than twice the originally estimated time, further executions may be
deprioritized.

6.3 Quality Assurance, project completion and carry-overData acquired with ALMA are subject to a near real-time verification of data quality for each individual
execution (Quality Assurance level 0 or QA0), and again after an SB has run to completion or been
terminated (QA2) 2. The quality assurance criteria and outcomes (Pass, Fail, SemiPass) are described in the
Quality Assurance chapter of the Technical Handbook. Data that have no scientific value (e.g. no valid dataor cannot be calibrated or exported) are marked “QA0 Fail”. These data do not count against projectcompletion or regional time shares, are not available to PIs, and do not show up in archival searches. Data
that are not useful for the proposed science goal but which are worthy of archiving (e.g. because they
contain useful calibrator data) are marked “QA0 SemiPass”. These data will not be used in the generation of
PI science products, and do not count against the PI or regional time shares, but the raw data follow thesame access rules and proprietary periods as “QA0 Pass” data (Sect. 8.4.1) and do show up in archival
searches.
QA2 is performed on the data that result from all executions of an SB (called an ObsUnitSet or OUS). Data
that meet the PI-specified goals within cycle-specific tolerances (as published in the Technical Handbook foreach cycle) are marked “QA2 Pass” and are made available to the PI. Data that do not pass QA2 have twooutcomes: if there is still the chance to obtain more observations in the current cycle then the data aremarked “QA2 Fail” and the corresponding SB is re-inserted into the observation queue; otherwise they aremarked “QA2 SemiPass” and delivered to the PI. QA2 SemiPass data have the same proprietary period asother data deliveries (Sect. 8.4), and do count against regional shares (Sect. 6.4).
SBs from Grade B and C projects that have not been started or completed by the end of the cycle and havenot been accepted as a resubmission in the new cycle will be “TimedOut” and removed from the observing
queue. Grade A proposals that have not been completed at the end of the cycle in which they were
submitted will be carried over to the next cycle. Grade A proposals that have been in the observing queue
Quality assurance level 1 (QA1) deals with the overall performance of the array. See the ALMA Technical Handbook
for details.
29for two consecutive cycles or more will be subject to APRC review to establish if they should be carried overfor one more cycle or if they should be terminated at the end of the on-going cycle.
Projects which are considered resubmission approved in the new Cycle but completed in the previous cycle
before the end of that cycle will be QA2-ed and delivered with the code of the past cycle.
A project is deemed completed if all associated QA0 Pass data have been assessed and delivered and all its
OUS have been assessed and delivered as QA2 Pass.
A project is deemed terminated if not all of its OUS have been delivered as QA2 Pass but there is no further
opportunity to observe the project in the current cycle (e.g. because the requested configuration is nolonger available) or to roll it forward into the next cycle.

6.4 Time accounting
The policies of time accounting are described in the Principles of Proposal Review Process document in the
ALMA SP (http://almascience.org/documents-and-tools/latest/alma-proposal-review-process).
During each observing season, balancing across regions will be based on the actual execution time of the 12m Array observations. The final evaluation will be done shortly after the observing season is over, and will bebased on the time associated with valid 12-m Array data delivered to PIs (i.e., data that passed QA0).
Executive shares will be calculated separately for observations of A and B graded projects, C graded projects,
and DDT projects. These will be published in an Observing Summary at the end of each cycle. In steady state
operations, Executive balance will be computed over a two years period, although large year-to-year
variations should be avoided.
Regular, ToO and DDT projects will have their observing time assigned to the region of the PI. As long as it
does not exceed 5% of the total observation time of the cycle, observation time for PIs unaffiliated with an
ALMA partner (Open Skies projects) will be accounted to the regions, proportionally to their regional share,i.e., 10% for Chile, 22.5% for EA, and 33.75% for each of EU and NA. Any additional time required by Open
Skies observations will be assigned to NA.
The observing time of Large Programs and VLBI Proposals will be assigned to the regions of the PI and of the
Co-PIs, proportionally to the fraction that are affiliated with each region.
For calculation of the Executive balance, the affiliation of a PI – or of a Co-PI, in the case of Large Programs
and VLBI Proposals – is the affiliation in his/her ALMA user profile at the time of the proposal’s firstsubmission. For EA/NA affiliation, 50% of the time is accounted to EA and 50% to NA.

6.5 PI errors
The Observatory is not responsible for errors in tuning or pointing due to incorrect information included in agiven project by the PI. All ALMA time allocations charged to observations that are flawed due to user error
will be charged to the relevant region as if the observation had been completed without errors.
Should a PI realize after observations of his/her project have been made that, due to an error on his/herpart, they do not actually produce the expected scientific outcome, then the observations will not be
repeated. Any remaining unexecuted Scheduling Blocks from the same project without errors may beretained in the observing queue at the discretion of the Observatory. If unexecuted parts of the project are
10

found to contain similar (or any other) errors before the project execution has been completed, the PI
should immediately submit a change request to correct those errors. This change request will be handled
through the standard procedure (see Section 7).

7 Changes to ALMA Proposals
After the proposal deadline, submitted proposals may not be changed prior to the completion of the review
process.
All changes made to projects after completion of the review process will be logged in the project, along with
the name of the ALMA staff member who implemented the change. Only authorized ALMA science staff canwrite these change logs, though they are viewable by the project PI and are an integral part of a project file.
Changes to a project mandated by the proposal review process (and included in the feedback to the PI) or
motivated by technical considerations will be implemented during Phase 2. Changes to a project that are notmandated by the proposal review process or technical considerations may only be made after the approvalof a PI-initiated change request (see below).
Changes to a project for which Phase 2 has been finalized and accepted for admission to the ALMA
observing queue will only be permitted in exceptional circumstances and only if the pertinent Scheduling
Block has not been observed and had some data pass QA0. An exception is the correction of errors
introduced by the Observatory (either by ALMA staff or ALMA tools) in the generation of a Scheduling Blockand identified after it is admitted to the observing queue. Consultation with the PI, if required, will behandled via the respective support ARC. Any time spent executing such erroneous SBs will not be charged
against the PI observing time.
A PI may request a change to a project – e.g. to correct a mistake in a field source list, or in response to
information obtained later that may seriously affect a project’s scientific case – via a standard change
request via the Helpdesk. Such change requests must include a clear description of the proposed change anda substantive justification for the change. A description of criteria followed by the Observatory to approve or
reject a change request can be found in the Proposer’s Guide and Phase 2 QuickStart Guide. Changes that
may be made by PIs without a change request are described in the Phase 2 OT documentation.
Change requests initiated during Phase 2 that are not resolved before the deadline for generation andapproval of Phase 2 products will result in generation of the Phase 2 products by ALMA staff once thechange request resolution is announced. For change requests initiated after the Phase 2 products have been
submitted to the observing queue, these products will be immediately removed from the queue until thechange request status is resolved.
Change requests leading to duplications against current or past ALMA proposals are not allowed.
Approval of major change requests is the responsibility of the ALMA Director, who may delegate this
responsibility to the ALMA Science Operations Department Head or ARC managers. The decision of the
ALMA Director, or of his/her delegate, is final. The Director or his/her delegate consults the Change Request
Standing Committee (CRSC) on these decisions. This Committee consists of several JAO senior astronomers
and one ARC manager selected on a rotating basis between the ALMA Executives. The Observatory’s
decision on the requested change will be communicated to the PI via the Helpdesk system. Approved
changes will be implemented by ARC staff, in consultation with the PI.
117.1 Project withdrawal
A PI may withdraw a submitted project at any time. If a PI withdraws a project prior to completion, aHelpdesk ticket should be filed so that no further observations are acquired for the project.

8 ALMA Data Delivery and Data Rights
This section details policies that govern ALMA data, including proprietary times.

8.1 Data property
All data taken by ALMA shall be jointly owned by the Parties 3. Ownership shall not impact the free access tothe data for use by observers and the astronomical community, according to the policies described in thisdocument.

8.2 ALMA proposal data
Proposal data includes: the Phase 1 materials submitted by the PI (proposal title, abstract, scientific andtechnical justification, and the names, institutions, and regions of PIs Co-PIs and Co-Is); the APRC grades andreviews; and the Phase 2 content prior to execution, including target positions, frequency settings, andspectral window parameters.
For proposals assigned grade A or B, the project code, proposal title and abstract, and the names of the PI,
Co-PIs and Co-Is will be made public soon after PIs are informed of the outcome of the proposal review
process. For proposals assigned grade C, the corresponding information will be made public when the firstdata pass QA0.
Proposal metadata (for example the source positions, observation frequencies, and integration times) for
Grade A, B and C proposals will be made public as soon as the first data are archived. The metadata forunaccepted proposals or unobserved proposals will remain confidential.
The scientific and technical justification, figures, references, and panel review rankings and reviews arenever made public for any proposal.

8.3 Observational metadata
Observational metadata describe the observations and the bulk data (excluding proposal data). They include
positional and sky coverage information; frequency settings, frequency coverage and resolution; angularresolution, uv-coverage, and antenna lists; source and calibrator names; polarization; observation date(s)and start/end times; time on source and sampling rate; basic weather; and PI name.
Observational metadata will be made available without restrictions when an observation that passes QA0 is
archived, regardless of its grade.
3 ’Parties’ are defined in the ALMA Trilateral Agreement and it means the NSF (National Science Foundation of theUnited States), ESO (European Organisation for Astronomical Research in the Southern Hemisphere) and NINS
(National Institutes of Natural Sciences of Japan).

128.4 Observational data
Observational data (also called ‘instrumental data’) include visibility data and all resulting products andimages.

8.4.1 Observational data access and proprietary periods
All OUSs that do not fail QA2 (see Sect. 6.3) will be made available to the PI, and any ALMA users delegatedby the PI (see Sect. 4.1). These data are subject to a 12 month proprietary period that begins when the ARC
sends an email notification to the PI that the data are available. Under no circumstances will a waiving ofproprietary period be considered during the proposal review process for proposals submitted to the regularobserving cycle (Section 5.1). For DDT Projects, this proprietary period is reduced to 6 months. The ALMA
Director may exceptionally grant a different proprietary period.
Successful proposers will have exclusive access to their project’s observational data for the proprietary
period, after which the data will become publicly accessible.
ALMA staff will have access to observational data at all times, as necessary for technical analysis andperformance tuning. In addition, ALMA staff members formally assigned to perform project Quality
Assurance (stage 2, QA2) can download and reduce project data for this purpose.
Until the proprietary period expires, ALMA staff may not disclose or scientifically use ALMA observational
data from projects for which they are not PI, including projects they support, without explicit PI permission
registered on a Helpdesk ticket. Similarly, ALMA staff performing QA2 may not disclose any intermediate or
final data reduction products of PI observations to anyone outside the ALMA/ARC network, including the
project PI, co-PIs and Co-Is, prior to data delivery. Any exceptions to this policy must be approved by the
Head of Science Operations and the associated ARC Manager.

8.4.2 Stale Data
SBs that have been started but not completed and have no opportunity to be completed for some time (e.g.
due to observing conditions or configuration schedule) result in partially completed OUSs. These OUSs are
said to be in “stale” state if they satisfy the following set of conditions:• No new data for the given OUS is expected to be taken for a period of at least 90 days since the last
QA0 Pass execution;• The SB remains “active” (it is not TimedOut, e.g. due to no further observing opportunities for theremainder of the observing season);• The fraction of QA0 Pass data indicates that the OUS is at least 25% complete, but not completeenough to be expected to meet the QA2 Pass criteria.
Data that are considered stale are eligible for “intermediate data delivery”, which means that the raw (QA0
Pass) data may be made available to the PI or PI delegates (see Section 4.1). Intermediate data delivery will
only be done if triggered by the Principle Investigator (PI). In each case the possibility and consequences ofdelivering the data partially to the PI will be assessed by ALMA staff. Considerations must include the benefit
provided to the PI, the burden on the Observatory, and the probability of additional data to be collected.
As a minimum, raw (uncalibrated) visibilities will be made available. The details of the delivery products may
evolve with time as the pipeline becomes more mature, and are left to the discretion of the Integrated
13

Science Operations Team. The data will be made available without undergoing the full set of quality
assurance checks, and will be delivered without further support from the ARCs.
Intermediate data delivery does not initiate the proprietary period. The normal proprietary period
restrictions and extension request processes apply once calibrated products are delivered.

8.4.3 Problems with delivered data
If users discover problems with the calibration or imaging data products that they believe require theproject to be re-observed, they should submit a Helpdesk ticket to their supporting ARC. These problems
may include incorrect observing procedures, calibration, or observing parameters (e.g. target positions,mosaic spacing, different than those approved by the PI during Phase 2 or anything else that may reflect anunderlying data validity problem.
The supporting ARC will submit a “QA3” ticket to the JAO if there is no known solution or re-observing or reprocessing is required. The JAO will evaluate the problem and whether it affects just the reporting user’s
data or similarly observed data. All active project components that might be affected by the reported issue
and have not yet been delivered will be put on hold. For delivered data, public release of the archival data
will be suspended until the corrected data have been re-delivered to the PIs.
For issues that have little to no impact to the affected projects’ Science Goals, the solution or work-aroundwill be communicated to the PI, and the original proprietary period will be reinstated (see Sect. 8.4.1).
If all or part of the project needs to be re-observed, the relevant Scheduling Blocks will be placed back in theobserving queue with the original priority. If necessary, corrected Phase 2 products will be produced andresubmitted. The part of the data that requires re-observing will be flagged in the Archive as “QA0 FAIL”.
When re-observed, the data will be processed through QA2 and re-delivered to the PI with thecorresponding proprietary period (see Sect. 8.4.1).
Re-observation will only be possible within the same Cycle, except for grade A proposals that are carriedover to one subsequent cycle. If the data need to be corrected rather than re-observed, this corrected data
will replace the original data in the archive.
The QA3 procedure will be not activated if the reported case is due to a mistake or incorrect interpretationof the data by the users.

8.4.4 Extension of Proprietary periods
Projects that need to have their data corrected but which do not need to be re-observed will have theirproprietary period extended if the proposal Science Goals are affected by the correction. To encourage PIs
to check the data they receive as soon as possible, the extension of the proprietary period is granted basedon the rapidity of the problem report.
•

Problems reported within two months of original delivery: The full proprietary period will be reset
based on the delivery date of the corrected data.

•

Problems reported more than two months from the original delivery: The affected PIs will only
receive an extension equal to the elapsed time between the posting of the reporting Helpdesk ticket
and the delivery date of the corrected data.
148.5 Calibration data
Standard calibration data are observations of calibrators needed to perform the correct calibration of thescientific data. They include the bandpass, amplitude, phase and polarization observations taken during PI
observations as well as grid survey observations run by the Joint ALMA Observatory.
All standard calibration data that have passed QA2, whether generated from Joint ALMA Observatory
observations or PI observations, have no proprietary period and will in the future be accessible separatelyfrom the ALMA archive.

8.6 ALMA Test and Science Verification Data
Data obtained during commissioning or engineering tests or science verification (SV) activities that have notbeen publicly released will be used only for the purposes of characterization and development of the ALMA
system, including hardware and software. The release of intermediate or final data reduction products or
test images from these data to anyone who is not an ALMA staff member, including use in ALMA publicity,requires the authorization of the ALMA Director or Deputy Director. Any plots or figures shown must havean appropriate watermark identifying them as test or commissioning data, and will not have axis labels thatallow them to be used for scientific purposes.
No personnel granted access to ALMA test or SV data may use these data for any scientific purpose unlessand until the data are offered at the ALMA Science Portal for public release. Any ALMA registered user may
then request such data by opening a Helpdesk ticket at the corresponding ARC. Users are advised tocarefully check the characteristics of a given offered dataset at the Science Portal before requesting the raw
data since often test data do not fulfil the requirements of scientific data regarding calibration.
Science Verification projects may not duplicate any PI proposal approved with A, B, C grades nor any DDT
approved proposal while unexecuted or during their proprietary period. If any DDT or PI proposal isapproved that duplicates a planned SV observation, the corresponding SV project must be changed to avoid
duplication.

9 Confidentiality of Information
Through the Observing Tool, any authenticated ALMA user has access to the following information: first andlast name, email address, affiliation, Executive, and ALMA username of registered users. All other ALMA user
information is confidential.
ALMA records the IP address and browser information of registered users logging in to the Science Portal.
This information is used exclusively to track download parameters such as download speed and file size.
ALMA also records the IP address and browser information of authenticated and non-authenticatedHelpdesk users. Access to this information, as well as to the contents of Helpdesk tickets, is restricted toauthorized ALMA staff.
Helpdesk Knowledgebase articles will not contain any information which would identify users or reveal
confidential proposal information.

15

10 Publication of ALMA Results
The following statement must be included in the acknowledgment of papers that use ALMA data:“This paper makes use of the following ALMA data: ADS/JAO.ALMA#YYYY.C.NNNNN.Z. ALMA is a partnershipof ESO (representing its member states), NSF (USA) and NINS (Japan), together with NRC (Canada), NSC andASIAA (Taiwan), and KASI (Republic of Korea), in cooperation with the Republic of Chile. The Joint ALMA
Observatory is operated by ESO, AUI/NRAO and NAOJ."
In this statement, YYYY.C.NNNNN.Z must be replaced by the actual project code. Here, “YYYY” denotes theyear when the CfP for a given cycle is issued, “C” identifies the cycle ID during that year 4, “NNNNN” is a fivedigit running number and “Z” denotes the proposal type (S: Regular, V: VLBI, L: Large, T: ToO, C: Calibration,
E: Engineering, SV: Science Verification).
In addition, publications from NA authors must include the standard NRAO acknowledgement:"The National Radio Astronomy Observatory is a facility of the National Science Foundation operated undercooperative agreement by Associated Universities, Inc."

10.1 Naming convention of sources discovered by ALMA
If referring to sources detected for the first time in ALMA fields one should follow the naming convention
ALMA JHHMMSS.s+/-DDMMSS (approved by IAU "Clearing House" of Commission 5 Working Group on
Designations), where J indicates J2000 coordinates.
The coordinates should be truncated according to the precision in the position of the source. Typically, thisshould be approximately 1/10th of the size of the synthesized beam used in the discovery observation (seethe ALMA Technical Handbook for details on ALMA astrometric precision), e.g. for a 1" beam, declination
should be given to a precision of 0.1" of arc and RA to 0.01s of time (ALMA JHHMMSS.ss+/-DDMMSS.s), for a0.1" beam declination to 0.01" of arc and RA to 0.001s of time (ALMA JHHMMSS.sss+/-DDMMSS.ss) etc.
For example, ALMA J123456.7890-123456.789 designates a new source with RA 12:34:56.7890 and
Declination 12:34:56.789 detected in a field observed in Band 9 with a long-baseline configuration with anangular resolution of 0.04 arcsec. ALMA J123456.789-123456.789 designates a new source with RA
12:34:56.789 and Declination 12:34:56.789 detected in a field observed in Band 3 with a compact
configuration with an angular resolution of 3.4 arcsec.

11 Final Provisions
Any situation that is unforeseen or for which ambiguity exists in this Users’ Policies document and in theassociated Call for Proposals material will be referred to the ALMA Director, whose decision is final.
ALMA reserves the right to change the policies defined in this document at any time. Barring unforeseen
emergencies, such changes will apply at the start of the observing cycle following the date of their
4

The “C” is used to identify both regular cycles (using a single digit), and DDT cycles (using a single letter). C=1 for the
first regular cycle of the considered year, C=2 for the second (if any), etc. C=A for the DDT cycle coinciding with theregular C=1 observation period, C=B for the DDT cycle corresponding to the C=2 observing period, and so on.

16introduction. These changes will be published in the users’ policy document at the call for each cycle and the
proposers should review the policies with each proposing cycle.

17

A. Appendix: Definition of a Duplicate Observation
A proposed observation is considered a duplicate of another observation if all of the following conditions
are met:Target field location••

For single-field interferometry, the proposed position coincides within the half-power beam width ofthe other observation. Moving objects (e.g., Solar System objects) will be identified by name.
For mosaic observations, more than 50% of the proposed pointings are within the half power beamwidth area covered by the other observation.

Angular Resolution•

The proposed angular resolution differs by a factor of ≤2 from the other observation.

Spectral windows▪

Continuum: The requested sensitivity (rms) for the aggregate bandwidth is better by a factor of ≤ 2from the other observation and the requested frequency is within a factor of 1.3.
- or –▪

Spectral line: If the central frequency in any requested correlator window observed in Frequency
Division Mode (FDM) mode is encompassed by the other observation observed in FDM mode andthe sensitivity per spectral channel, after smoothing to the same spectral resolution, is better by afactor of ≤ 2.

To be considered a “continuum” observation, the proposed correlator setup must contain 2 or more
windows with a bandwidth > 1.8 GHz.
Solar observations will not be checked for duplications.

18