ALMA Doc 7.16, ver.0.7 | March 2019

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

Date

Editors

March 2019

iSOpT

In publications, please refer to this document as:iSOpT 2019, ALMA Users’ Policies, ALMA Doc. 7.16 v0.7

Table of Contents
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
Eligibility and responsibility .......................................................................................................... 3
4.2
Proposal Time Assignment .......................................................................................................... 4
4.3
Proposal submission: Phase 1 .................................................................................................... 45 ALMA Proposal Selection ........................................................................................................................ 5
5.1
Duplications .................................................................................................................................... 5
5.2
Descoping ....................................................................................................................................... 5
5.3
Proposal Assessment ................................................................................................................... 6
5.4
Outcome ......................................................................................................................................... 6
6 Preparation and Execution of ALMA Observations ............................................................................. 6
6.1
Observation preparation: Phase 2 .............................................................................................. 6
6.2
Observation scheduling ................................................................................................................ 7
6.3
Quality Assurance, project completion and carry-over............................................................ 7
6.4
Time accounting ............................................................................................................................ 8
6.5
PI errors .......................................................................................................................................... 8
7 Changes to ALMA Proposals .................................................................................................................. 8
7.1
Project withdrawal ......................................................................................................................... 9
8 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 .......................................................... 10
8.4.2 Stale Data ................................................................................................................................. 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 ....................................................................................................................................... 14
A. Appendix: Definition of a Duplicate Observation ................................................................................ 15

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, or 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 or accessing their proprietary data.

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 puts constraints on which ARC will provide support. Users from acountry within the three Executives (EA, EU or NA) are automatically and compulsorily assigned to the ARC of2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 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, CoPIs and the ARC Managers.
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 Principles of the
Proposal Review Process for a definition of proposal types) projects or special observing campaigns (e.g., VLBI
and Solar) 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. 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/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);● Submission of the Phase 2 Products (see Section 6.1);● 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 document, 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 Guide for 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, and that are received
before the submission deadline will be considered.
The final proposal submission deadline is firm – 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.
DDT proposals do not have a specific submission deadline and can be submitted at any time until the end of
an observing cycle for execution during that cycle. DDT proposals are not overwritten when submitted. As
such they can only be submitted once. DDT proposals are not carried over to subsequent cycles.
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 previous cycle, the relevant SGs of the resubmitted proposal will be cancelled.

5 ALMA Proposal Selection
ALMA proposals other than DDTs are subject to international peer review. Reviewers are appointed by the
JAO and are selected to ensure appropriate representation of the ALMA regions and Chile.

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 Head of DSO will take the final decision onwhich program will be observed. Typically, the program with the better grade will have higher priority in thequeue. Other factors will also be considered, including the requested observing frequency and the prevalent
weather conditions, and which project triggered the observation 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. If any part of a project should be descoped because of duplication, this must be clearly stated in
the consensus report sent to PIs. Descoping should not add Science Goals (SGs) to a proposal. Parameters will
not be changed for a subset of targets within a SG (e.g., removal of one spectral window or changing thecorrelator setup or requested resolution and sensitivity for a subset of targets within a SG).

5

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 document. 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 not have Phase 2 Scheduling Blocks (SBs) prepared (see Section 6.1) and not be considered for schedulingat 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 Head of ALMA Department of Science
Operations (Head of DSO) based on the advice from a 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.

5.4 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 throughthe 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.1 Observation preparation: Phase 2
The PI must 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 Science Portal (see Phase 2 QuickStart Guide andUser's Guide to ALMA Scheduling Blocks). These guidelines describe any allowed changes that may be madeby PIs with respect to the submitted proposal before the Phase 2 material is generated. PIs may contact ARC
staff at any time for questions or recommendations regarding checking and generating Phase 2 material.
Once the SGs are prepared and reviewed, the PI must submit the SGs through the OT to the ALMA archive.
This submission constitutes the PI approval that the project is valid for scheduling on the telescope. ALMA
staff may modify submitted projects for technical reasons (e.g., to improve the efficiency of the observational
setup). If such technical modifications affect the scientific output (e.g., moving slightly the spectral windows
from the band edge) of the project in any way, the PI will be contacted to approve the changes.
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 (see Section 7).

6

If the PI does not approve the Phase 2 products within the given deadline as indicated in the email notification,
the project will be downgraded to the next lower grade except those projects that have pending change
requests submitted before the Phase 2 submission deadline.

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

7

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), the project is terminated.

6.4 Time accounting
The policies of time accounting are described in the 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 a
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.

8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 the change
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 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 Parties1. 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
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.

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The scientific and technical justification, figures, references, and panel review rankings and reviews are nevermade public 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
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 CoIs, prior to data delivery. Any exceptions to this policy must be approved by the ARC Managers and informed
to the Head of DSO.
For ToO and time critical observations, PIs have the possibility to request the release of the raw data via the
Helpdesk to enable a prompt analysis. The proprietary period for these observations will start when thequality-assured data products are delivered to the PI, as for any other observation (see above).

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 a “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/Semi-pass execution;● The SB remains “active” (i.e., opportunities remain to observe the SBs);
10

Data that are considered stale are eligible for “intermediate data delivery”, which means that the raw (QA0
Pass and Semi-pass) data may be made available to the PI or PI delegates (see Section 4.1). Intermediate datadelivery will only be done if requested by the PI. In each case, ALMA staff on a best-efforts basis will assess
the possibility and consequences of delivering the data partially to the PI. The data will be made available
without undergoing the full set of quality assurance checks and will be delivered without further support fromthe ARCs. An 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 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.
11

Parental/sick/military leave by the PI may be considered as a justification for the extension of proprietary time
if the leave has been approved by the supervisor/employer. PIs may submit the request through the Helpdesk
and 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 approved that is in theobserving queue or 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 submission of 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.

12

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.

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 year2,“NNNNN” is a five-digit running number and “Z” denotes the proposal type (S: Regular, V: VLBI, L: Large, T:
ToO). A similar nomenclature is used for test observations, where “Z” denotes the type of dataset (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).

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

14

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.

15

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.

16