Skip to content

Telescope access

This page is the owner-facing model for who can observe with your telescope and how their time is prioritized. There are four things to know:

  1. Telescope ownership — who has full administrative control.
  2. Observing queues — the prioritized lanes that time on your telescope is divided into.
  3. Queue access grants — who can hold time on a given queue.
  4. Observing accounts — how those grants are bundled and presented to the people actually submitting observations.

Together these let you delegate time without delegating control, and share the telescope across audiences (institutional research, education, external collaborators, ToO follow-up) without conflating them.

New here, and someone just asked you for access? Skip to Three ways to grant someone access — the sections above define the pieces it refers back to.

Telescope ownership

Telescopes are owned by an entity — either an organization or an individual user. The owner has full administrative control: configuration, queues, access policy, and the ability to flip the telescope between automated and manual control.

A telescope's owner can additionally issue TelescopeAccessGrants that delegate read, update, or delete authority on the telescope record itself to other users, organizations, or groups — useful for shared operations between a host institution and a collaborating group.

Observing queues

Each telescope carries an ordered list of observing queues. A queue is a named lane of time — e.g. Maintenance, General Observing, ToO (target of opportunity), Education — and the order on the telescope is its priority order. The scheduler tries to satisfy higher queues first; lower queues fill remaining time.

Each queue has its own prioritization model, which orders the queue's access grants:

  • Fixed — grant priorities you set by hand; they don't change as time is used. Best for fully manual allocation policies and ToO lanes.
  • Fair-share — grant priorities adjust dynamically so each grantee trends toward their ownership fraction (shares), measured on contested time only — time used while nobody else was waiting is free and can't be hoarded. Available at two scopes: telescope-wide or queue-local. Best for fairness across many users.
  • Calendar — time on the queue is distributed according to a schedule (e.g. "this group has Mondays, that one has Tuesdays").

Queues are the right tool for coarse allocation policy ("classroom gets 20% of contested time"); within a grantee's slice of a queue, the grantee's own account ordering and observation priorities take over. The full comparison ladder — queue order → grant order → account order → observation order — is spelled out in Scheduler prioritization.

Queue access grants

An ObservingQueueAccessGrant says "this entity is allowed to put observations through this queue, with this much weight." Grants can be issued to users, organizations, or groups, and they can be revoked at any time.

A queue without any access grants is reachable only by the telescope owner. As you grant access, you build up the audience of the queue.

Observing accounts

An observing account is what observers see — the practical handle they submit observations against. Internally it's a bundle of one or more queue access grants, possibly spanning multiple telescopes, aggregated under a single owner.

That layer exists for four reasons:

  1. Resource aggregation. A consortium with grants on five different telescopes can aggregate them into one observing account so its members don't have to think about which queue to hit for each request — the scheduler picks among eligible telescopes.
  2. Permission delegation. The account's owner controls who can submit observations through it. A research group lead can give submit-rights to their students without those students being personally grant-holders on the underlying queues.
  3. Quota throttling. Both the account and each grant under it can carry one or more quotas — (period, max_credits) rules that cap how much can be spent within a window. Multiple quotas compose (a lifetime cap plus a rolling weekly cap, for example); all active quotas must be satisfied. This is where a parent grant can say "this delegated subaccount may not consume more than X per week" independently of the overall pool's policy.
  4. Prioritization within the grantee's slice. Accounts (and the subaccounts under them) carry an order, so an entity can decide how its own slice of a queue divides under contention — research account ahead of outreach account, thesis students ahead of intro sections. None of this affects other grantees or your queue configuration; it only orders work inside the slice you granted. See Scheduler prioritization.

So the flow is: owner → grants → account → observer. The owner issues queue access grants to entities. Those entities create observing accounts that bundle their grants. Members of those entities submit observations through the accounts.

Three ways to grant someone access

Everything above is the machinery. In practice, when someone asks to observe with your telescope, you're choosing between three routes — and the real difference between them is who ends up owning the observations, and how much oversight you keep.

Route The recipient gets… Observations owned by You keep control of Best for
1. Direct queue access Time on your queue(s), plus the ability to create and run their own observing accounts The recipient The queue's share and prioritization; revoking the grant A partner or group you want running its own program
2. Member grant on your observing account Permission to submit through an observing account you own You, the observing account's owner Everything — the observing account, its grants, quotas, and the observations Programs you want to oversee and keep institutional
3. Delegated grant on your observing account An observing subaccount they own, funded from your allocation The recipient A quota on the delegation and a revoke switch — nothing more External collaborators who must own their own data

The difference that matters is which side of the ownership boundary each route lands on — routes 1 and 3 cross into the recipient's space, route 2 stays in yours:

flowchart LR
  OWN["You — telescope owner"]:::owner

  subgraph YOURS["Your org's space · your org owns the observations"]
    direction TB
    MEMBER["Member / group<br>in your org"]:::node
    ACCT["Observing account<br>you own"]:::node
    MEMBER -->|"Route 2 · Member grant"| ACCT
  end

  subgraph THEIRS["Recipient's space · the recipient owns the observations"]
    direction TB
    ROOT["Their own root<br>observing account"]:::node
    SUB["A subaccount<br>they own"]:::node
  end

  OWN -->|"Route 1 · Queue access grant"| ROOT
  OWN --> ACCT
  ACCT -->|"Route 3 · Delegated grant"| SUB

  classDef owner fill:#eaf7f0,stroke:#2e7d32,stroke-width:1.5
  classDef node fill:#f8fafc,stroke:#94a3b8,stroke-width:1
  style YOURS fill:#eaf7f0,stroke:#2e7d32,stroke-width:1
  style THEIRS fill:#fff7ed,stroke:#ea580c,stroke-width:1

1. Give direct queue access

Issue the entity a TelescopeAccessGrant (with a number of shares) and one or more ObservingQueueAccessGrants. This puts time directly in their hands: a root account is only funded by queues its owner already holds grants for, so holding a queue access grant is what lets an entity stand up usable observing accounts of its own. From there the recipient is self-sufficient — they can bundle your queues with grants on other telescopes into a single account, add member grants for their own people, and delegate their own subaccounts to outside collaborators.

  • You keep control of the allocation — the queue's share, and whether its priority is fixed, calendar, or fair-share. Fair-share holds each grantee to their shares automatically.
  • You give up visibility into individual observations; they belong to the recipient, in the recipient's space.
  • Reach for this when you want a collaborator to run their own program and manage their own people, and you only need to govern how much telescope time they get and at what priority.

2. Add them to an account you own (member grant)

Create an observing account owned by your organization and issue the person a MemberObservingGrant (or a GroupObservingGrant for a whole group, or rely on the automatic OwnerObservingGrant that lets every org member submit). They can now submit observations through the account — but the account, and everything submitted through it, stays owned by your organization. The member can't pull that account into their personal space, and you retain the right to see, examine, and modify what they submit.

  • You keep full oversight: you own the account, its grants, its quotas, and the observations themselves. Per-grant quotas let you cap each member independently.
  • You give up nothing on the ownership side — but the member can't take "their" observations with them; the data is institutional.
  • Reach for this when the organization wants to run and be accountable for the observing — staff working under an institutional allocation, a PI's students observing under the PI's account, a class whose data the department retains.

Member and group grants are intra-organization: they route through your org's membership and roles. To bring in someone outside your organization, use route 3.

3. Delegate a subaccount they own (delegated grant)

From an account you own, invite an external user or organization with an ExternallyManagedObservingGrant. When they accept, Skynet creates a subaccount owned by them, hanging off your account. They see it in their own space and fully own everything they submit through it — the subaccount draws on the queues your parent account already exposes, but adds no new access of its own.

  • You keep exactly three levers: attach a quota to the delegation to cap how much they consume, revoke the delegation, or archive your own node. Credit usage still rolls up to you (so quotas work and you can watch aggregate consumption) — but the observations are theirs, and you have no authority to view or modify them.
  • You give up oversight of their individual observations. If you need to inspect or manage their data, that's route 2, not this.
  • Reach for this when an outside partner or consortium member must own their own data and manage their own people, while drawing time from your allocation under a spending cap you control.

For the same delegation within your own organization — a class or lab that manages itself day-to-day while the data stays org-owned — use a GroupManagedObservingGrant instead: the subaccount is owned by your organization but managed by the group.

The same tools at every level

These routes aren't mutually exclusive, and they compose. The moment you use route 1 to give an entity direct queue access, that entity gets the same three choices for its own members and partners — member grants inside its org, delegated subaccounts for outsiders. Access fans out down a tree, and at every node the owner governs only its own slice: share and priority above, ownership and oversight below.

In the web app

The owner-facing UI for this lives in the React port at:

The Angular site has equivalents under apps/website/src/app/features/entity/telescopes/.

Reference

ObservingQueueAccessGrant Schema

Properties

Name Type Description
id Integer The unique identifier for the queue access grant.
queue_id Integer The ID of the queue to which the allocation belongs.
telescope_access_grant_id Integer The ID of the telescope access grant providing access to this queue.
order Integer The order used to prioritize this allocation within the queue. Lower values are higher priority.
revoked Boolean Whether this allocation has been revoked. If true, the allocation is no longer valid.
effective_order Integer The effective order used to prioritize thisa llocation within the queue, taking into account the queue's prioritization policy and the allocation's own priority.
time_used Float The total time used by the account regardless of whether it was contested or not.
time_contested Float The total time used by the account when sibling accounts also had observations which could have been scheduled.
time_waiting Float The total time that the other accounts used while this account was waiting for its observations to be scheduled.
observing_policy_id Integer (Optional) No description

Relationships

Relationship Name Type
queue ObservingQueue
telescope_access_grant TelescopeAccessGrant
observing_accounts ObservingAccount
observing_policy ObservingPolicy

ObservingAccount Schema

Properties

Name Type Description
id Integer Unique identifier of the observing account.
owner_id Integer No description
managing_group_id Integer (Optional) No description
name String(256) (Optional) No description
slug String(256) (Optional) No description
source_account_id Integer (Optional) The ID of the parent node in the hierarchy. Null if this node is a root.
source_account_grant_id Integer (Optional) The ID of the delegated observing grant that links this subaccount to its parent. Composite FK in table_args enforces that the grant's account_id matches source_account_id.
path LtreeType() (Optional) The materialized path using the PostgreSQL ltree type, representing the hierarchical structure for efficient querying. [Automatically set by trigger]
credits_used Float No description
is_deleted Boolean Whether the observing account has been archived.
order Integer The order used to prioritize the account among its siblings. Lower values are higher priority.
last_activity_on DateTime (Optional) No description
observing_policy_id Integer (Optional) No description

Relationships

Relationship Name Type
observing_policy ObservingPolicy
owner Entity
managing_group Group
observing_grants ObservingGrant
quotas ObservingQuota
queue_access_grants ObservingQueueAccessGrant
source_account_grant DelegatedObservingGrant
source_account ObservingAccount
subaccounts ObservingAccount
ancestors ObservingAccount
descendants ObservingAccount
root_account ObservingAccount