ALMA Doc 6.16, ver. 0.5 | March 2018

ALMA Users’ Policies

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

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

Version
0.5

Date

Editors

March 2018

iSOpT
Sean Dougherty
John Carpenter
Elizabeth Humphreys

In publications, please refer to this document as:iSOpT 2018, ALMA Users’ Policies, ALMA Doc. 6.16.v1.0

Table of contents
1

Purpose and Scope ............................................................................................................................... 3

2

ALMA Users ............................................................................................................................................. 3
2.1

3

Registering with ALMA .............................................................................................................................. 3

User Support .......................................................................................................................................... 3

4

ALMA Proposal Preparation and Submission ............................................................................ 4
4.1
4.2
4.3

5

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

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

6

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

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

7

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

Changes to ALMA Proposals........................................................................................................... 10
7.1

8

Project withdrawal .................................................................................................................................. 11

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

9

Confidentiality of Information ...................................................................................................... 15

10

Publication of ALMA Results...................................................................................................... 15

10.1

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

11

Final Provisions ............................................................................................................................. 16

A.

Appendix: Definition of a Duplicate Observation .............................................................. 17

2

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

2 ALMA Users
Unauthenticated users (unregistered users, or users who are registered but have not logged in) have accessto ALMA non-proprietary data, documentation, tools, or the 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. In addition, ALMA may assign specific roles to selected
registered users that provide additional privileges. For instance, ALMA Proposal Review Committee (APRC)
and ALMA Review Panel (ARP) members are assigned the role of Science Assessor, which allows them, for
the ALMA cycles in which they serve, to run the Proposal Handling Tool to access and review proposals andsubmit their proposal assessments.

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 his/herusername after he/she has completed the registration process. To prevent the accidental creation of two
accounts with a different username by a single user, the Science Portal issues a warning if it detects such an
attempt. To register, a user must provide his/her full name, a valid email address, and the country of his/her
affiliation or the country of residence (for users not affiliated with a scientific institution). The Observatory
has experienced that often ALMA official notifications end up in the spam folder of users’ emails whose
addresses belong to commercial servers, such as Gmail or Yahoo. The Observatory reserves the right torefuse any complaint from users entering such email addresses in the user profile.
Users are required to update their ALMA user profile whenever there is a change in their personal details,
such as a new email address or a change of affiliation. Users are responsible for ensuring that their profile iscorrect and are requested to contact ALMA staff through the Helpdesk if they encounter problems or to deactivate unnecessary, duplicated, profiles.

3 User Support
User support is provided by the ALMA Regional Centers (ARCs) and ARC nodes.
The country specified in the user’s profile constrains which ARC will provide his/her support. Users from acountry within the three Executives (EA, EU or NA) are automatically and compulsorily assigned the ARC of3their Executive for support. Users from Taiwan may elect either the EA ARC or the NA ARC as their support
ARC. Users outside the three ALMA Executives, including Chilean users, may choose any Executive ARC as
their support ARC. The supporting ARC for Large Programs may be changed from the one assigned to the PI
to the one assigned to one of the co-PIs under especial circumstances.
The assigned ARC will assist users during Phase 2, data quality assurance process and data delivery. Face-toface support may be provided by the assigned ARC or one of its ARC nodes.
Questions should be submitted to the supporting ARC through the ALMA Helpdesk. Any potentially sensitive
information communicated to ARC staff or submitted to the Helpdesk regarding the user or proprietary
project details are held in the strictest confidence. Information submitted through the Helpdesk can only beaccessed through a secured database by ARC-affiliated and the Joint ALMA Observatory (JAO) staff.
ARC-affiliated staff are the interface between ALMA users and the Observatory 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) may the PI be in contact with the Astronomer on Duty (AoD). In this case the communication proceeds
via the 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 Proposal Call documentation. In particular, allusers accept the limitations of the observing capabilities and operational restrictions applicable for the cycle
for which he/she submits a proposal.
Each proposal must identify a single individual 1 who will serve as Principal Investigator (PI). The PI will act as
the official contact between ALMA and the proposing team for all proposal correspondence. Proposals may
include any number of Co-Investigators (Co-Is) and, for Large Programs and VLBI Proposals, Co-Principal
Investigators (Co-PIs). Additional rules, described at http://www.das.uchile.cl/das_alma_crc.html, apply for
qualification to use the Chilean share of the time. Proposals which are submitted through Chilean time and,based on reasons related to the Chilean rules above, are found not to be compliant will not be eligible for
the Open Skies Time.

1 Single individual is understood as a single person, i.e. proposals submitted by a consortium are not valid. Instead, aperson within the consortium should submit the proposal and act as PI and any other consortium members will act as
co-Is or co-PIs (if the proposal type allows them).

4By submitting a proposal, the PI takes full responsibility of its contents. In particular, PIs must 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 his/her 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.
PI responsibilities include proposal submission and, for approved projects, submission of Phase 2 products(see Sect. 6.1) and proposal change requests (see Sect. 7). PI responsibilities may only be transferred to CoPIs 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). These responsibilities may not be transferred for non-urgent
circumstances (e.g., sabbatical or science leave, vacations). Requests to transfer PI responsibility should besent to the ALMA Helpdesk.
The project PI may grant the following PI privileges on a project basis to one or more ALMA registered users:• Access to proprietary data (see Section 8.4);• Email notification of state changes to an approved project.
These privileges are granted through the Science Portal (SP) user profile “Project Delegation” interface. The
same interface can be used by the PI of an approved proposal to allow another ALMA registered user tosubmit the Phase 2 products for his/her proposal.
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 at the Science Portal. There may be cycle-dependent limits on the time
allocated for proposals of different types (e.g. using non-standard modes, Large Programs, stand-alone
ACA). These will be described in the Proposer’s Guide for each cycle.

4.3 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 proper OT version,that comply with the advertised technical constraints and restrictions, and that are received before thesubmission 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, see 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 Sect. 6.4) are not allowed. If such proposals are detected, the first submitted version will beconsidered, and the remaining proposals will be ignored.

5

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. Unlike all other proposals, DDT proposals can only besubmitted once and that submission will be considered final.
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
proposal is accepted and one or more Science Goals (SGs) were successfully completed in the previous cycle,
the relevant SGs of the resubmitted proposal will be cancelled.

5 ALMA Proposal Selection
ALMA proposals other than DDT are subject to international peer review by the ARPs and the APRC. Panelmembers are appointed by the ALMA Director and are selected to ensure appropriate representation of the
ALMA regions and Chile.

5.1 Duplications
In order to ensure the most efficient use of ALMA, duplicate observations of the same location on the sky
with similar observing parameters (frequency, angular resolution, coverage, and sensitivity) are notpermitted unless scientifically justified. Archival data should be used whenever possible to accomplish thescience goals of a proposed investigation. Detailed criteria of what constitutes a duplicated observation are
specified in Appendix A of this document.
It is the responsibility of the proposers to check the proposed observations against the previously executed
programs in the Archive and accepted grade A programs to avoid duplicate observations. Proposers cannot
be penalized for proposing duplications of previous Cycle observations if they had no way to know about
them by the proposal deadline. Any proposed duplicate observation must be justified in the proposal. The
ALMA Review Panels 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 isformed, 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 not have access to the data from the other proposal until the proprietary period has expired.
There may be cases where more than one DDT or ToO programs are triggered on the same object nearly
simultaneously. Should such a situation arise, the Observatory Scientist will take the decision on which
program will be observed according to the following guidelines:•

If the programs do not fulfil the criteria for being considered duplicates, all programs will be
executed•

If two or more programs are identified as duplicates and have a different grade (see Section 5.3), theproject with the highest grade will be executed6

•

If two or more programs are identified as duplicates and have the same grade, the project that was
triggered first (identified via the timestamp of the submitted Helpdesk ticket) will be executed

5.2 Descoping
Projects may be descoped only for compelling scientific or technical reasons. This includes duplications withexisting data or with a higher-ranked project from the same cycle. If any part of a project should bedescoped because of duplication, this must be clearly stated in the consensus report sent to PIs. Projectdescoping must be done without adding SGs to a proposal. Parameters will not be changed for a subset oftargets within a SG (e.g. remove one spectral window or change the correlator setup or requested resolution
and sensitivity for a subset of targets in a SG).

5.3 Proposal Assessment
Each proposal is assigned a letter grade as a result of the proposal review process as described in the
Principles of Proposal Review Process document. Grades A, B and C will be assigned based on scientific rank,
Executive balance, and scheduling feasibility. Proposal grades affect 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 Sect. 6.1) and 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 Sect.
6.1). The final decision on project infeasibility will be taken by the ALMA Director, based on the advice froma small standing committee consisting of senior 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
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.1 Observation preparation: Phase 2
Once a project has been approved for execution, it passes into Phase 2.
The PI will retrieve the project from the archive with the OT, and use the OT to check and approve the Phase
2 material following the guidelines provided through the SP (see Phase 2 QuickStart Guide and User's Guide
to ALMA Scheduling Blocks). These guidelines describe any allowed changes that may be made by PIs with7

respect to the submitted proposal before the Phase 2 material is generated. Any changes to a project
mandated by the proposal review process (as described in the consensus report) or motivated by technicalconsiderations will be made by ALMA staff. PIs may contact 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 has the responsibility to submit them through the OT to the
ALMA archive. This submission constitutes the PI approval that the project is valid for scheduling on thetelescope. ALMA staff may modify submitted projects for technical reasons (e.g. to improve the efficiency ofthe observational setup). If such technical modifications may affect by any means the scientific output (e.g.
moving slightly the spectral windows from the band edge) of the project, the PI will be contacted to approvethe 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 (Section 7).
If the PI does not approve the Phase 2 products within the given deadline as indicated in the email
notification, the project may be downgraded to the next lower grade.

6.2 Observation scheduling
Science observations will be executed by ALMA operations staff, taking into account the weather conditions,the array configuration, target elevation and other practical constraints, the project grades and the
Executive balance. All other things being equal, the proposal with the highest grade will be observed first.
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 Sect. 6.3)
2. The potential scheduling period has ended (one observing season for grade B and C projects, twoobserving seasons for grade A projects)
3. There are no more 12-m Array configurations planned for the rest of the scheduling period thatmatch the 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-overData acquired with ALMA are subject to a near real-time verification of data quality for each individual
execution (Quality Assurance level 0 or QA0), and again after an SB has run to completion or been
terminated (QA2) 2. The quality assurance criteria and outcomes (Pass, Fail, SemiPass) are described in the
Quality Assurance chapter of the Technical Handbook. Data that have no scientific value (e.g. no valid dataor cannot be calibrated or exported) are marked “QA0 Fail”. These data do not count against projectcompletion or regional time shares, are not available to PIs, and do not show up in archival searches. Data
that are not useful for the proposed science goal but which are worthy of archiving (e.g. because they
contain useful calibrator data) are marked “QA0 SemiPass”. These data will not be used in the generation of
Quality assurance level 1 (QA1) deals with the overall performance of the array. See the ALMA Technical Handbook
for details.
28

PI science products, and do not count against the PI or regional time shares, but the raw data follow thesame access rules and proprietary periods as “QA0 Pass” data (Sect. 8.4.1) and do show up in archival
searches.
QA2 is performed on the data that result from all executions of an SB (called an ObsUnitSet or OUS). Data
that meet the PI-specified goals within cycle-specific tolerances (as published in the Technical Handbook foreach cycle) are marked “QA2 Pass” and are made available to the PI. Data that do not pass QA2 have twooutcomes: if there is still the chance to obtain more observations in the current cycle then the data aremarked “QA2 Fail” and the corresponding SB is re-inserted into the observation queue; otherwise they aremarked “QA2 SemiPass” and delivered to the PI. A special case is constituted by an OUS that has been
already observed for more than twice the originally estimated time and still does not pass QA2. In this case,the region where the QA2 assessment was performed will report on how much time was already spent, howmuch additional time is anticipated to be needed to complete the OUS, and whether the additional time isthought to be useful for that OUS. Based on this, the ARC manager at each region will take the decision tomark the corresponding OUS as “QA2 Fail” and have it placed back into the observing queue or as “QA2
SemiPass” and have the data products delivered to the PI. QA2 SemiPass data have the same proprietary
period as other data deliveries (Sect. 8.4), and do count against regional shares (Sect. 6.4).
SBs from Grade B and C projects that have not been started or completed by the end of the cycle and havenot been accepted as a resubmission in the new cycle will be “TimedOut” and removed from the observing
queue. Grade A proposals that have not been completed at the end of the cycle in which they were
submitted will be carried over to the next cycle. At the end of the second cycle in the observing queue,
Grade A proposals will also be “TimedOut” and removed from the observing queue unless a resubmission
has been accepted for the upcoming cycle.
A project is deemed completed if all associated QA0 Pass data have been assessed and delivered and all its
OUS have been assessed and delivered as QA2 Pass.
If none or not all of the project’s OUS have been delivered as QA2 Pass but there is no further opportunity toobserve 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, the project is terminated and marked as “NotObserved” or“PartiallyCompleted”, respectively.

6.4 Time accounting
The policies of time accounting are described in the Principles of Proposal Review Process document in the
ALMA SP.
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 for details on QA0).
Regular, ToO and DDT projects will have their observing time assigned to the region of the PI. As long as it
does not exceed 5% of the total observation time of the cycle, observation time for PIs unaffiliated with an
ALMA partner (Open Skies projects) will be accounted to the regions, proportionally to their regional share,i.e., 10% for Chile, 22.5% for EA, and 33.75% for each of EU and NA. Any additional time required by Open
Skies observations will be assigned to NA.
9The observing time of Large Programs and VLBI Proposals will be assigned to the regions of the PI and of the
Co-PIs, proportionally to the fraction that are affiliated with each region.
For calculation of the Executive balance, the affiliation of a PI – or of a Co-PI, in the case of Large Programs
and VLBI Proposals – is the affiliation in his/her ALMA user profile at the time of the proposal’s last
submission. For EA/NA affiliation, 50% of the time is accounted to EA and 50% to NA.

6.5 PI errors
The Observatory is not responsible for errors in tuning or pointing due to incorrect information included in agiven project by the PI. All ALMA time allocations charged to observations that are flawed due to user error
will be charged to the relevant region as if the observation had been completed without errors.
Should a PI realize after observations of his/her project have been made that, due to an error on his/herpart, they do not actually produce the expected scientific outcome, then the observations will not be
repeated. Any remaining unexecuted Scheduling Blocks from the same project without errors may beretained in the observing queue at the discretion of the Observatory. If unexecuted parts of the project arefound 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.
Changes to a project recommended by the proposal review process (and included in the feedback to the PI)
or motivated by technical considerations will be considered for implementation during Phase 2. Any otherchange may only be made after the approval of a PI-initiated change request (see below).
Changes to a project for which Phase 2 has been finalized and accepted for admission to the ALMA
observing queue will only be permitted in exceptional circumstances and only if the pertinent Scheduling
Block has not been observed and had some data pass QA0. An exception is the correction of errors
introduced by the Observatory (either by ALMA staff or ALMA tools) in the generation of a Scheduling Blockand identified after it is submitted to the observing queue. Consultation with the PI, if required, will behandled via the respective support ARC. Any time spent executing such erroneous SBs will not be charged
against the PI observing time.
Change requests initiated during Phase 2 that are not resolved before the deadline for generation andapproval of Phase 2 products will result in generation of the Phase 2 products by ALMA staff once thechange request resolution is announced. For change requests initiated after the Phase 2 products have been
submitted to the observing queue, these products will be immediately removed from the queue until thechange request status is resolved.
Change requests leading to duplications against ALMA proposals in the observing queue or archival
observations are not allowed.

10

The Observatory’s decision on the requested change will be communicated to the PI via the Helpdesk
system. Approved changes will be implemented by ARC staff, in consultation with the PI.

7.1 Project withdrawal
A PI may withdraw a submitted project at any time. If a PI withdraws a project prior to completion, aHelpdesk ticket should be filed so that no further observations are acquired for the project.

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

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

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

8.3 Observational metadata
Observational metadata describe the observations and the bulk data (excluding proposal data). They include
positional and sky coverage information; frequency settings, frequency coverage and resolution; angularresolution, uv-coverage, and antenna lists; source and calibrator names; polarization; observation date(s)and start/end times; time on source and sampling rate; basic weather; and PI name.
3 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).

11

Observational metadata will be made available without restrictions when an observation that passes QA0 is
archived, regardless of its grade.

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

8.4.1 Observational data access and proprietary periods
All OUSs that do not fail QA2 (see Sect. 6.3) will be made available to the PI, and any ALMA users delegatedby the PI (see Sect. 4.1). These data are subject to a 12-month proprietary period that begins when the ARC
sends an email notification to the PI that the data are available. For DDT Projects, this proprietary period is 6
months. The ALMA Director may exceptionally grant a different proprietary period.
Successful proposers will have exclusive access to their project’s observational data for the proprietary
period, after which the data will become publicly accessible. PIs may be contacted by their supporting ARCs
to answer questions helping ALMA to provide better data and support in the future.
ALMA staff will have access to observational data at all times, as necessary for technical analysis andperformance tuning. In addition, ALMA staff members formally assigned to perform project Quality
Assurance (stage 2, QA2) can download and reduce project data for this purpose.
Until the proprietary period expires, ALMA staff may not disclose or scientifically use ALMA observational
data from projects for which they are not PI, including projects they support, without explicit PI permission
registered on a Helpdesk ticket. Similarly, ALMA staff performing QA2 may not disclose any intermediate or
final data reduction products of PI observations to anyone outside the ALMA/ARC network, including the
project PI, co-PIs and Co-Is, prior to data delivery. Any exceptions to this policy must be approved by the
Head of Science Operations and the associated ARC Manager.
For ToO observations that require follow up/subsequent observations based on the outcome of the initialobservation, 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 the quality 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 “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/Semipass execution;• The SB remains “active” (it is not TimedOut, e.g. due to no further observing opportunities for theremainder of the observing season);
Data that are considered stale are eligible for “intermediate data delivery”, which means that the raw (QA0
Pass and Semipass) data may be made available to the PI or PI delegates (see Section 4.1). Intermediate datadelivery will only be done if triggered by the Principle Investigator (PI). In each case the possibility andconsequences of delivering the data partially to the PI will be assessed by ALMA staff. Considerations must12

include the benefit provided to the PI, the burden on the Observatory, and the probability of additional data
to be collected.
As a minimum, raw (uncalibrated) visibilities will be made available. The details of the delivery products may
evolve with time as the pipeline becomes more mature and are left to the discretion of the Integrated
Science Operations Team. The data will be made available without undergoing the full set of quality
assurance checks and will be delivered without further support from the ARCs.
Intermediate data delivery does not initiate the proprietary period. The normal proprietary period
restrictions and extension request processes apply once calibrated products are delivered.

8.4.3 Problems with delivered data
If users discover problems with the calibration or imaging data products that they believe require theproject to be re-observed, they should submit a Helpdesk ticket to their supporting ARC. These problems
may include incorrect observing procedures, calibration, or observing parameters (e.g. target positions,mosaic spacing), different than those approved by the PI during Phase 2 or anything else that may reflect anunderlying data validity problem.
Unless the reported case is due to a mistake or incorrect interpretation of the data by the users, all active
project components and any other projects that might be affected by the reported issue and have not yet
been delivered will be put on hold. For delivered data, public access of the archival data will be suspended
until the corrected data have been re-delivered to the PIs.
For issues that have little to no impact to the affected projects’ Science Goals, the solution or work-aroundwill be communicated to the PI, and the original proprietary period will be reinstated (see Sect. 8.4.1).
If all or part of the project needs to be re-observed, the relevant Scheduling Blocks will be placed back in theobserving queue with the original priority. If necessary, corrected Phase 2 SBs will be produced andresubmitted. Re-observation will only be possible within the same Cycle, except for grade-A proposals thatare carried over to one subsequent cycle. When re-observed, the data will be processed through QA2 andre-delivered to the PI with the corresponding proprietary period (see Sect. 8.4.1).
If the data need to be corrected rather than re-observed, this corrected data will replace the original data in
the archive.

8.4.4 Extension of Proprietary periods
ObsUnitSets that need to have their data corrected (Section 8.4.3) but which do not need to be re-observed
will have their proprietary period extended if the proposal Science Goals are affected by the correction. To
encourage PIs to check the data they receive as soon as possible, the extension of the proprietary period isgranted based on the rapidity of the problem report:•

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

•

Problems reported more than two months from the original delivery: the affected PIs will only
receive an extension equal to the elapsed time between the posting of the reporting Helpdesk ticket
and the delivery date of the corrected data.
13

•Problems reported after the proprietary period has expired: the affected PIs will receive thecorrected 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.

Parental/sick/military leave may be considered as a justification for the extension of proprietary time if theleave has been approved by the supervisor/employer. PIs may submit the request through the Helpdesk andjustify that the approved leave takes significant time away from the office. For these cases, the extension
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 do not fall within this category and will not be considered for an extension.

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

14

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

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

10.1 Naming convention of sources discovered by ALMA
If referring to sources detected for the first time in ALMA fields one should follow the naming convention
ALMA JHHMMSS.s+/-DDMMSS (approved by IAU "Clearing House" of Commission 5 Working Group on
Designations), where J indicates J2000 coordinates.
The coordinates should be truncated according to the precision in the position of the source. Typically, thisshould be approximately 1/10th of the size of the synthesized beam used in the discovery observation (seethe ALMA Technical Handbook for details on ALMA astrometric precision), e.g. for a 1" beam, declination
The “C” is used to identify both regular cycles (using a single digit), and DDT cycles (using a single letter). C=1 for the
first regular cycle of the considered year, C=2 for the second (if any), etc. C=A for the DDT cycle coinciding with theregular C=1 observation period, C=B for the DDT cycle corresponding to the C=2 observing period, and so on.

415

should be given to a precision of 0.1" of arc and RA to 0.01s of time (ALMA JHHMMSS.ss+/-DDMMSS.s), for a0.1" beam declination to 0.01" of arc and RA to 0.001s of time (ALMA JHHMMSS.sss+/-DDMMSS.ss) etc.

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.

16

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

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

Angular Resolution•

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

Spectral windows▪

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

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

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

17