ALMA Doc 8.16, ver.0.8 | March 2021

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), MOST 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

0.8

Date

Editors

March 2021

Liz Humphreys, Misato Fukagawa, Anthony Remijan, Martin Zwaan,
Evanthia Hatziminaoglou, Catherine Vlahakis

In publications, please refer to this document as:
ISOpT 2021, ALMA Users’ Policies, ALMA Doc. 8.16 v0.8

1

PURPOSE AND SCOPE .......................................................................................................................................... 2

2

ALMA USERS ........................................................................................................................................................ 2
2.1

REGISTERING WITH ALMA ........................................................................................................................................ 2

3

USER SUPPORT .................................................................................................................................................... 2

4

ALMA PROPOSAL PREPARATION AND SUBMISSION ............................................................................................ 3
4.1
4.2
4.3

5

ALMA PROPOSAL SELECTION ............................................................................................................................... 5
5.1
5.2
5.3
5.4

6

OBSERVATION PREPARATION: PHASE 2 ........................................................................................................................ 7
OBSERVATION SCHEDULING ....................................................................................................................................... 7
QUALITY ASSURANCE, PROJECT COMPLETION AND CARRY-OVER ........................................................................................ 7
TIME ACCOUNTING................................................................................................................................................... 8
PI ERRORS .............................................................................................................................................................. 8

CHANGES TO ALMA PROPOSALS .......................................................................................................................... 8
7.1

8

DUPLICATIONS ........................................................................................................................................................ 5
DESCOPING ............................................................................................................................................................ 5
PROPOSAL ASSESSMENT............................................................................................................................................ 6
OUTCOME .............................................................................................................................................................. 6

PREPARATION AND EXECUTION OF ALMA OBSERVATIONS ................................................................................. 6
6.1
6.2
6.3
6.4
6.5

7

ELIGIBILITY AND RESPONSIBILITY.................................................................................................................................. 3
PROPOSAL TIME ASSIGNMENT ................................................................................................................................... 4
PROPOSAL SUBMISSION: PHASE 1 ............................................................................................................................... 4

PROJECT WITHDRAWAL ............................................................................................................................................. 9

ALMA DATA DELIVERY AND DATA RIGHTS ........................................................................................................... 9
8.1
DATA PROPERTY ...................................................................................................................................................... 9
8.2
ALMA PROPOSAL DATA ............................................................................................................................................ 9
8.3
OBSERVATIONAL METADATA .................................................................................................................................... 10
8.4
OBSERVATIONAL DATA ............................................................................................................................................ 10
8.4.1 Observational data access and proprietary periods: QA2 access ................................................................. 10
8.4.2 Observational data access: QA0 access........................................................................................................ 10
8.4.3 Problems with delivered data ....................................................................................................................... 11
8.4.4 Extension of Proprietary periods .................................................................................................................. 11
8.5
CALIBRATION DATA ................................................................................................................................................ 12
8.6
ALMA TEST AND SCIENCE VERIFICATION DATA ........................................................................................................... 12

9

CONFIDENTIALITY OF INFORMATION ..................................................................................................................12

10

PUBLICATION OF ALMA RESULTS ....................................................................................................................13
10.1

NAMING CONVENTION OF SOURCES DISCOVERED BY ALMA ........................................................................................... 13

11

FINAL PROVISIONS..........................................................................................................................................13A.

APPENDIX: DEFINITION OF A DUPLICATE OBSERVATION ....................................................................................14

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 the Users’
Policies, the latter takes precedence, unless explicitly indicated otherwise. All ALMA users are subject to theUsers’ Policies described here and in the Call documents. Violation of these policies by a user may result insanctions against scientific project(s) under evaluation or execution in which they are involved.

2 ALMA Users
Unauthenticated users (unregistered users, or users who are registered but have not logged in) have accessto ALMA non-proprietary data, documentation, tools, and the ALMA Helpdesk Knowledgebase articles listing
solutions to common questions and problems.
Registering with ALMA confers all authenticated users additional privileges such as participating in ALMA
proposals , accessing their proprietary data, following up the progress of their projects and accessing theHelpdesk.

2.1 Registering with ALMA
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 theirusername after completing the registration process. To prevent the accidental creation of two accounts witha different username by a single user, the Science Portal issues a warning if it detects such an attempt.
To register, a user must provide their full name, a valid email address, and the country of their affiliation or
the country of residence (for users not affiliated with a scientific institution). The Observatory has experienced
that often ALMA official notifications end up in the spam folder of users’ emails that belong to commercial
servers, such as Gmail or Yahoo!. The Joint ALMA Observatory (JAO) reserves the right to refuse any complaint
about not receiving email notifications from users entering such email addresses in their user profile.
Users are responsible for ensuring that their profile is correct (e.g., email address, affiliation) and arerequested to contact ALMA staff through the ALMA Helpdesk if they encounter problems or to de-activate
duplicate profiles.

3 User Support
The ALMA Regional Centers (ARCs) and ARC nodes provide user support. For further information, see theassociated Guides to the ALMA Regional Centers available at the ALMA Science Portal:
https://almascience.org/proposing/documents-and-tools/#section-2.
The country specified in the user’s profile defines which ARC will provide support as follows. Users from acountry within the three Executives (EA, EU or NA) are automatically and compulsorily assigned to the ARCof their Executive for support. Users from Taiwan may elect either the EA ARC or the NA ARC as their ARC forsupport. Users outside the three ALMA Executives, including Chilean users, may choose any Executive ARC
2

as their ARC for support. In the case of Large Programs, the supporting ARC may change from the Principal
Investigator (PI) to one of the Co-Principal Investigators (Co-PIs) under mutual agreement between the PI,
Co-PIs and the ARC Managers. If a PI changes affiliation between Executives, the supporting ARC forobserving programs that have yet to be started will be transferred to the new Executive.
Questions should be submitted to the supporting ARC through the ALMA Helpdesk. Any potentially sensitive
information communicated to ALMA staff submitted to the ALMA Helpdesk regarding the user or proprietary
project details can only be accessed through a secured database accessible by the user themselves, ARCaffiliated or JAO staff.
ARC-affiliated staff are the interface between ALMA users and the JAO for all communications. Users should
always contact the supporting ARC for issues related to any project, including project execution, proposal
submissions or change requests.
Only in case of urgent questions regarding the execution of Target of Opportunity (ToO, see the Principles of
the ALMA Proposal Review Process for a definition of proposal types) projects or special observing campaigns(e.g., VLBI) may the PI be in contact with designated JAO staff. In this case, the communication proceeds via
the ALMA Helpdesk at a dedicated department continuously 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

Any registered user may submit ALMA proposals. All registered users agree to act according to the ALMA
policies and procedures, as defined in this document and in the Proposal Call documentation. In particular, allusers accept the limitations of the observing capabilities and operational restrictions applicable for the cycle
for which they submit a proposal.
Each proposal must identify a single individual who will serve as PI. A single individual is understood as a single
person. Proposals submitted by a consortium are not valid. Instead, a person within the consortium should
submit the proposal and act as PI and any other consortium members will act as Co-Investigators (Co-Is) or
Co-PIs (if the proposal type allows them). The PI (or their designee in some cases - see below) is the official
contact between ALMA and the proposing team for all proposal correspondence. The PI(s) and all Co-Is are
responsible for ensuring that their respective profiles registered for the ALMA user account are correct (e.g.,email address, affiliation). Proposals may include any number of Co-Is and, for Large Programs and VLBI
Proposals, Co-PIs. Additional rules, described at http://www.das.uchile.cl/alma_crc/das_alma_crc.html, apply
for qualification to use the Chilean share of ALMA time.
By submitting a proposal, the PI takes full responsibility of its contents. The PI is responsible to ensure that all
Co-Is and Co-PIs have agreed to be included on a proposal. Including an ALMA user as Co-I or Co-PI in a
proposal without their consent may lead to the proposal being canceled. Co-I and/or Co-PI names cannot be
added to or be withdrawn from the proposal after the proposal deadline.
The PI responsibilities as described above may only be transferred to Co-PIs or Co-Is in the case of emergencies(e.g., sickness), status change (e.g., retirement) and approved leave (e.g., parental, military, see Section 8.4.4).
3

These responsibilities may not be transferred for non-urgent circumstances (e.g., sabbatical or science leave,
vacations). Requests to transfer PI responsibility should be sent to the ALMA Helpdesk.
The PI may grant the following privileges on a project basis to one or more ALMA registered users:● Access to proprietary data (see Section 8.4);● Triggering of ToO proposals;● Email notification of state changes to an approved project.
These privileges are granted through the user profile “Project Delegation” interface accessible through the
ALMA Science Portal.
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 the Principles of the Proposal
Review Process, available through the ALMA Science Portal. There may be cycle-dependent limits on the time
allocated for proposals of different types (e.g., Large Programs). These are described in the Proposer’s Guidefor each cycle.

4.3 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. If a user finds such aninconsistency, it should be reported though the ALMA Helpdesk. ARC and JAO staff will take the appropriate
actions to resolve the inconsistency.
Only proposals that conform to the prescribed format, that are submitted through the distributed OT for the
specific cycle, that comply with the advertised technical constraints and restrictions (including proposal
anonymity), and that are received before the submission deadline will be considered. It is strongly discouraged
to intentionally modify the source coordinates in the OT at Phase 1 with the purpose of obscuring the true
positions of target sources. The JAO reserves the right to reject proposals that do not comply with theguidelines to anonymise the proposals for the dual-anonymous review process (see the Proposer’s Guide).
The final proposal submission deadline is firm. It is the responsibility of the PI to ensure that their proposal
has been successfully submitted by the deadline. Proposals submitted after this deadline will not be accepted
except for Director’s Discretionary Time (DDT) proposals as described below. A proposal can be submitted any
number of times to the ALMA Archive until the submission deadline. When a proposal is submitted multiple
times, previous versions are overwritten. Multiple submissions of the same proposal using different regional
affiliations (see Section 6.4) are not allowed. 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 for consideration in the current cycle call for proposals. If the resubmitted

4

proposal is accepted and one or more Science Goals (SGs) were successfully completed (i.e., successful QA2)
in the ongoing cycle, the relevant SGs of the resubmitted proposal will be cancelled.
DDT proposals do not have a specific submission deadline and can be submitted at any time. Accepted DDT
proposals shall remain in the observing queue for 12 months from the date of proposal acceptance,
irrespective of ALMA Cycle. DDT proposals are not overwritten when resubmitted. As such they can only besubmitted once.

5 ALMA Proposal Selection
ALMA proposals other than DDTs are subject to international peer review. Reviewers are either appointed by
the JAO, or automatically selected in the case of the distributed peer review.

5.1 Duplications
Duplicate observations of the same location on the sky with similar observing parameters (frequency, angularresolution, coverage, and sensitivity) are not permitted unless scientifically justified. Detailed criteria of what
constitutes a duplicated observation are specified in Appendix A.
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. It is allowed topropose observations that duplicate previous Cycle observations if there is no way to know about them by
the proposal deadline. Any proposed duplicate observation must be justified in the proposal. The proposal
reviewers or the JAO will determine if the justification for the requested duplicate observation is sufficient.
Duplicate observations may result among proposals submitted within the same cycle. 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.
The JAO may consider the amount of time duplicated between the two proposals when determining whether
or not a proposal is descoped. The proposal that stands to lose the proposed duplicate observation will nothave access to the data from the other proposal until the proprietary period has expired.
There may be cases where more than one DDT, Time Critical or ToO programs are triggered on the same
object nearly simultaneously. Should such a situation arise, the ALMA Head of the Department of Science
Operations (DSO) will take the final decision on which program will be observed. Typically, the program withthe better grade will have higher priority in the queue. Other factors will also be considered, including therequested observing frequency and the prevalent weather conditions, and which project triggered theobservation first. In these cases, all relevant PIs will be notified of their priority in the queue. If multiple
proposals trigger on a time-variable object, duplication rules will not apply.

5.2 Descoping
Projects may be descoped only for compelling scientific or technical reasons. This includes duplications withexisting data or metadata available at the time of proposal deadline or with a higher-ranked project from thesame cycle. A project descoping based on duplication can only be made if this request is clearly stated in theconsensus report sent to PIs. Descoping cannot add Science Goals (SGs) to a proposal. The observatory will5not change parameters for a subset of targets within a SG (e.g., removal of one spectral window or changing
the correlator setup or requested resolution and sensitivity for a subset of targets within a SG). If a change
request is submitted to change the coordinates of a target, and in the subsequent duplication checking theobservation is then found to duplicate any portion of another active project in the same cycle, then the change
request will be denied and target will be descoped from the project making the change request. The descoping
will take place irrespective of the relative rankings of the projects.

5.3 Proposal Assessment
Each proposal is assigned a letter grade as a result of the proposal review process as described in the Principlesof the ALMA Proposal Review Process. Grades A, B and C will be assigned based on scientific rank, Executive
balance, and scheduling feasibility. Proposal grades indicate the scheduling priority, with proposals with A
grades having the highest priority and proposals with C grades having the lowest. All other proposals will nothave Phase 2 Scheduling Blocks (SBs) prepared (see Section 6.1) and may not be considered for scheduling at
the telescope.
The ALMA Observatory may declare any type of observation that does not conform to the advertised
capabilities technically infeasible at any stage of the Proposal Review Process or during “Phase 2” (see Section
6.1). The final decision on project feasibility will be taken by the ALMA Head of DSO based on the advice froma small standing committee consisting of staff at the JAO. PIs of proposals found to be infeasible will be
notified by email with a description of the technical issue.
PIs or designated reviewers of proposals that are assessed through the distributed peer review process haveto submit their ranks and reviews by the time of the Stage 1 review deadline. If this deadline is not met, theproposal on which the reviewer is acting as the designated reviewer will be rejected.

5.4 Outcome
An email notification will be sent to the PIs that will include the consensus report from the ALMA panel review
or the complete reviews from the ALMA distributed peer review process, and the assigned letter grade. The
outcome of the proposal selection process is final.
In case of questions about details in the ALMA review report(s), 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 based on the scientific assessment.

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

66.1 Observation preparation: Phase 2
Phase 2 material is now generated automatically by the ALMA Observatory i.e., PIs no longer need to submit
Phase 2 SGs. PIs should therefore be particularly careful when submitting their Phase 1 projects. In case ofchanges needed to scheduled projects, PIs should consult with their CS who will determine whether the Phase
2 Group can implement the change directly or whether a change request is needed (see Section 7).
There is no deadline by which changes can be made to scheduled projects via the CS, however it remains the
responsibility of the PI to ensure that all user-supplied information is correct by the time of project execution.
ALMA staff may modify submitted projects for technical reasons (e.g., to improve the efficiency of theobservational setup). If such technical modifications (e.g., moving slightly the spectral windows from the bandedge) affect the scientific output of the project in any way, the PI will be contacted to approve the changes.

6.2 Observation scheduling
Science observations will be scheduled taking into account many factors including, for example, weather,
proposal grade and executive balance (see Section 6.4), and will be executed by ALMA operations staff. The
individual SBs of approved projects will be observed until one of the following three criteria are met:
1. The data are determined to meet the user specified criteria (see Section 6.3).
2. The potential scheduling period has ended (one observing season for grade B and C projects, twoobserving seasons for grade A projects, and 12 months for DDT projects).
3. There are no more 12-m Array configurations planned for the rest of the scheduling period that matchthe SB 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 (see Section 6.3).

6.3 Quality Assurance, project completion and carry-overThe quality assurance criteria and outcomes (Pass, Fail, Semi-pass) are described in the Quality Assurance
chapter of the Technical Handbook. Data that have no scientific value (e.g., no valid data or cannot becalibrated or exported) are marked QA0 Fail. Data that do not pass the QA0 criteria do not count against
project completion or regional time shares, are not available to PIs, and do not show up in archival searches.
Data marked as QA0 Semi-pass will not be used in the generation of PI science products and do not countagainst the PI or regional time shares, but the raw data follow the same access rules and proprietary periods
as QA0 Pass data (see Section 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). A special
case is constituted by an OUS that has been already observed for more than twice the originally estimatedtime and still does not pass QA2. In this case, the region where the QA2 assessment was performed will reporton how much time was already spent, how much additional time is anticipated to be needed to complete theOUS, and whether the additional time is thought to be useful for that OUS. Based on this, the ARC manager
at each region will take the decision to mark the corresponding OUS as QA2 Fail and have it placed back into
the observing queue or as QA2 Semi-pass and have the data products delivered to the PI. QA2 Semi-pass data
have the same proprietary period as other data deliveries (see Section 8.4) and count against regional shares(see Section 6.4).
7

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 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 carriedover to the next cycle. At the end of the second cycle in the observing queue, Grade A proposals will also be
removed from the observing queue unless a resubmission has been accepted for the upcoming cycle.
If not all of the project’s OUS have been delivered as QA2 Pass or Semi-pass and there is no further opportunity
to observe the project in the current cycle (e.g., because the requested configuration is no longer available)or to roll it forward into the next cycle (e.g., resubmission, Grade A), the project is terminated. If there are
executions of an SB that are insufficient to pass QA2 at the termination, the QA2 state is changed from QA2Fail to QA2 Semi-pass and the OUS is delivered to the PI.

6.4 Time accounting
The policies of time accounting are described in the Principles of the ALMA Proposal Review Process1. Principles
of Proposal Review Process document.
The ALMA Observatory strives to balance the observing time among the regions over two-year periods.
Balance across regions is based on the actual execution time of valid 12-m Array observations; i.e., data thatare QA0 Pass and have been delivered to PIs (see Section 6.3).
All proposals will have their observing time assigned proportionally to the regions of the PI and Co-PIs (in caseof Large Programs and VLBI proposals). As long as it does not exceed 5% of the total observation time of thecycle, observation time for PIs and Co-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 affiliation in the ALMA user profile at the time of the proposal’s last submission is used. 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 (e.g., wrong or outdated ephemerides) due
to incorrect information provided 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 their project have been made that, due to an error on their part, thedata do not produce the expected scientific outcome, then the observations will not be repeated. If
unexecuted parts of the project are 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. After the PIs have been notified of the results of the proposal review process, PIs of accepted
proposals may request changes to their project. Any major change may be made only after the approval of a8

PI-initiated change request, which may be motivated by recommendations made by the proposal review panel
or other technical considerations for implementation during Phase 2.
A PI-initiated change request is not necessary to correct errors introduced by the Observatory (either by ALMA
staff or ALMA tools) in the generation of a Scheduling Block and identified after it is submitted to the observing
queue. Consultation with the PI, if required, will be handled via the respective ARC for support. Any time spentexecuting such erroneous SBs will not be charged against the PI observing time.
During the time the change request is under consideration, these projects will be immediately removed fromthe queue until the change request status is resolved.
Change requests leading to duplications against ALMA proposals in the observing queue or archival
observations are not allowed.
The Observatory’s decision on the requested change will be communicated to the PI via the Helpdesk.
Approved changes will be implemented by ARC staff in consultation with the PI.

7.1 Project withdrawal
A PI may withdraw a submitted project at any time. If a PI withdraws a project prior to completion, a Helpdesk
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 are jointly owned by the Parties 1. Ownership shall not impact the free access to thedata for use by observers and the astronomical community, according to the policies described in thisdocument.

8.2 ALMA proposal data
Proposal data include 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 proposal grades
and reviews; 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 Grade A proposals (for example the source positions, observation frequencies, andintegration times) will become public after the proposal review process is completed. For Grades B and C
1

The ’Parties’ are defined in the ALMA Trilateral Agreement as the NSF (National Science Foundation of the UnitedStates), ESO (European Organisation for Astronomical Research in the Southern Hemisphere) and NINS (National
Institutes of Natural Sciences of Japan).

9

proposals, metadata will be made public for each SB as soon as the first data of such SB are archived. The
metadata for unaccepted proposals or unobserved proposals (or parts of it) will remain confidential.
The scientific and technical justification, figures, references, and review rankings and reviews are never madepublic for any proposal.

8.3 Observational metadata
Observational metadata include the positional and sky coverage information, frequency settings, frequency
coverage and resolution, angular resolution, uv-coverage, antenna lists, source and calibrator names,
polarization, observation date(s) and start/end times, time on source and sampling rate, weather information
and PI name. Observational metadata will be made available without restrictions when an observation thatpasses QA0 is archived, regardless of its grade.

8.4 Observational data
Observational data include visibility data and all resulting data products.

8.4.1 Observational data access and proprietary periods: QA2 access
All OUSs that do not fail QA2 (see Section 6.3) will be made available to the PI and any ALMA users delegatedby the PI (see Section 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. For DDT projects, this proprietary period is 6
months. The ALMA Director may grant a different proprietary period in exceptional circumstances.
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 QA2 candownload and reduce project data for this purpose.
Until the proprietary period expires, ALMA staff may not disclose or scientifically use ALMA observational datafrom projects for which they are not PI, including projects they support, without explicit recorded permission
from the PI. 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 ARC Managers andinformed to the Head of DSO.

8.4.2 Observational data access: QA0 accessPIs can request via the ALMA Helpdesk that QA0-pass raw data should be staged for download as soon as they
are available i.e. before the full QA2 products are ready. The proprietary period for the MOUS will start after
the raw data from the first Execution Block (EB) in the MOUS have been made available to the PI. Helpdesk
tickets requesting assistance with raw data will be given a lower priority than other submitted tickets althoughwill still adhere to the standard operating procedures and service level agreements of the ALMA Helpdesk (i.e.
PIs will still get a reply within 48 hours but may not have the issue Resolved in that time). The release of raw
data to the PIs will have no implications on the QA2 process. QA2 data will continue to be delivered to all PIs,
10

irrespective of whether they chose to download the raw data. The proprietary time on data that have beenrequested at QA0 will not be changed if the associated MOUS goes on to fail QA2 i.e. the proprietary time will
still be 12 months from the time the QA0 data were made available. Note that the QA0-access policy
supercedes the previous stale data and early release of ToO and time critical data policies.

8.4.3 Problems with delivered data
If a user finds a significant problem with the calibration or imaging data products, a Helpdesk ticket should besubmitted to their supporting ARC. The Observatory will then determine if the observations or data processing
need to be repeated to correct the problem. If necessary, active SBs that might be affected by the reported
issue and have not yet been observed will be put on hold while the investigation takes place. Archival accessmay be suspended until the corrected data have been re-delivered. For issues that have little to no impact tothe affected projects’ Science Goals, the solution or work-around will be communicated to the user.
If all or part of the project needs to be re-observed, the relevant SBs will be placed back in the observing queuewith the original priority. If necessary, corrected Phase 2 SBs will be produced and resubmitted. Reobservation will only be possible within the same Cycle, except for grade-A proposals that are carried over to
one subsequent Cycle. Any exceptions to this policy will be considered on a case-by-case basis at the discretionof the Head of DSO.
When re-observed, the data will be processed through QA2 and re-delivered to the PI with the corresponding
proprietary period (see Section 8.4.1). If the data need to be reprocessed rather than re-observed, these
corrected data will replace the original data in the Archive.
If a problem reported by a user is determined to impact other projects, the Observatory will proactively
contact the relevant PIs to describe the issues. The policies in this section will be applicable to the affected
projects.

8.4.4 Extension of Proprietary periods
ObsUnitSets that need to have their data corrected (see Section 8.4.3) but which do not need to be reobserved will have their proprietary period extended if the proposal Science Goals are affected. 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 thedelivery date of the corrected data.

●

Problems reported after the proprietary period has expired: the affected PIs will receive the corrected
data when available and such data will also replace the faulty products in the Archive. In this case, a
new proprietary period will not be granted.

Requests for extensions will be always considered for extenuating circumstances outside the control of the
PI. The most common circumstances where proprietary time extensions have been approved include
parental/personal leave, sick leave, or military service. PIs may submit the request through the Helpdesk and11

justify that the approved leave takes significant time away from the office. Decisions on requests for an
extension of the proprietary period are made by the Head of DSO. The length of the extension will beconsidered on a case-by-case basis based on the conditions of the approved leave. For these cases, theextension must be requested at least one month before the end of the proprietary period. An extension will
not be granted if requested within 30 days before the data are scheduled to become public. Vacation, home,science, sabbatical leaves will not be considered for an extension. The proprietary period of Large Programs
will not be extended in the cases of approved leave.

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 JAO.
All standard calibration data that have passed QA2, whether generated from JAO or PI observations, have no
proprietary period and will in the future be accessible separately from the ALMA archive. Until then, PIs may
request the delivery of such data to the corresponding ARC via the Helpdesk. Such requests will be handled
by each ARC on a best-effort basis.

8.6 ALMA Test and Science Verification Data
Data obtained during commissioning, engineering tests or science verification (SV) activities will be used tocharacterize and develop the ALMA system, including hardware and software. The data will be released
through the Science Portal, Science Archive, ALMA technical memos, or publications. Any ALMA registereduser 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 an approved PI or DDT proposal that is in the observing queueor during their proprietary period. If a PI proposal is approved that duplicates an SV observation planned after
the proposal submission deadline, the corresponding SV project must be changed to avoid duplication. DDT
proposals that duplicate an SV observation already planned and announced at the SP before the submissionof the former will be rejected.

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 available to only the user themselves and ARC-affiliated or JAO staff.
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-authenticated Helpdesk
users. Access to this information, as well as to the contents of Helpdesk tickets, is restricted to authorized
ALMA staff.
Helpdesk Knowledgebase articles will not contain any information which would identify users or reveal
confidential proposal information.
12

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), MOST and
ASIAA (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 Call for Proposals for a given cycle is issued, “C” identifies the cycle ID during that year 2,“NNNNN” is a five-digit running number and “Z” denotes the proposal type (S: Regular, V: VLBI, L: Large, T:
ToO, P: Phased Array). A similar nomenclature is used for test observations, where “Z” denotes the type ofdataset (E: Engineering, CSV: Commissioning and Science Verification, CAL: Calibration, 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). For example, 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 a 0.1" beam declination to 0.01" of arc and RA to 0.001s of time (ALMA JHHMMSS.sss+/DDMMSS.ss).

11 Final Provisions
Any situation that is unforeseen or for which ambiguity exists in this Users’ Policies document or 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 theirintroduction. 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.
2

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 the regular
C=1 observation period, C=B for the DDT cycle corresponding to the C=2 observing period, and so on.

13

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 and thesensitivity per spectral channel, after smoothing to the same spectral resolution, is better by a factorof ≤ 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.

14

The Atacama Large Millimeter/submillimeter Array (ALMA), an international astronomy facility, is apartnership of the European Organisation for Astronomical Research in the Southern Hemisphere (ESO), theU.S. National Science Foundation (NSF) and the National Institutes of Natural Sciences (NINS) of Japan incooperation with the Republic of Chile. ALMA is funded by ESO on behalf of its Member States, by NSF in
cooperation with the National Research Council of Canada (NRC) and the Ministry of Science and Technology(MOST) in Taiwan and by NINS in cooperation with the Academia Sinica (AS) in Taiwan and the Korea
Astronomy and Space Science Institute (KASI).
ALMA construction and operations are led by ESO on behalf of its Member States; by the National Radio
Astronomy Observatory (NRAO), managed by Associated Universities, Inc. (AUI), on behalf of North America;and by the National Astronomical Observatory of Japan (NAOJ) on behalf of East Asia. The Joint ALMA
Observatory (JAO) provides the unified leadership and management of the construction, commissioning andoperation of ALMA.

15