Observing accounts

An observing account is the practical handle you submit observations against. It bundles one or more queue access grants — possibly on different telescopes — into a single unit that you (or your research group, or your class) can use without thinking about which queue to hit for each request. The scheduler picks an eligible telescope from whatever the account exposes.

If you're new to the access model: telescope owners issue queue access grants to entities (users, organizations, groups). Those entities then aggregate their grants into observing accounts, and submit-permissions on the account decide who can actually use it.

This page is the observer-side view. For the owner-side mechanics, see Telescope access.

What's in an account

An ObservingAccount carries:

Owner — the entity (user or organization) the account belongs to. The owner controls who can submit through it.
Queue access grants — the set of ObservingQueueAccessGrant records that connect the account to telescope queues. These are what determine which telescopes are reachable from this account.
Observing grants — the records (MemberObservingGrant, GroupObservingGrant, etc.) that say which entities can submit observations through the account. See Observing grants.
Quotas — zero or more ObservingAccountQuota records that throttle how much the account can spend within a period. See Quotas.
credits_used — running total of credits consumed by the account so far. Each transaction is recorded as an ObservingAccountTxn linked to the originating observation task.
Subaccounts — accounts can form a tree (delegated grants below; used for classroom, consortium, and first-light flows).

You'll see your accounts in the dashboard's /dashboard/observing-access view, on your user profile, and as the very first step of the observation editor (the editor only proceeds once you've picked a funding account).

Account types

Root accounts

The most common kind. Created by a user or organization that already holds queue access grants directly.

Funded through queue access grants.
Can distribute time downstream by issuing observing grants.
Most personal accounts are root accounts.

Subaccounts

Created under a root account via a delegated observing grant. Used to split usage among users or teams without giving them direct visibility into the parent.

May be owned and managed by a group (a class, a research team).
Can only reference queues available to their parent — they don't add new queue access; they redistribute existing access.

Observing grants

An observing grant says "this entity is allowed to submit through this account." Grants have several flavors:

Owner grant

Automatically assigned to the account's owner. If the owner is a user, that user can submit. If the owner is an organization, every member of the organization can submit (subject to organizational RBAC).

Member grant

Assigned to an individual user. Lets a single member of an organization submit through an account they don't own — useful when you want fine-grained "who can submit" control inside a larger organization.

Group grant

Assigned to a group. Every member of the group can submit.

Delegated observing grant

A grant of authority to create subaccounts under the parent — not just to submit through the parent.

Group-delegated grant — a group can create subaccounts to distribute time among its members or projects. Subaccounts can be owned by the parent organization but managed independently by the group (classroom / lab workflow).
Externally-managed delegated grant — an external user or organization can create their own subaccount that references the parent. The recipient consumes time against the parent but tracks it independently (consortium / partnership workflow).

Every grant tracks its own credits_used and can carry its own quotas, so you can fine-grain how much each grantee can consume independent of the parent account's overall throttling.

Quotas

A quota is the mechanism Skynet uses to throttle credit consumption. A quota is essentially a rule of the form "don't spend more than max_credits within a period_type window."

The period_type is drawn from a small set:

`period_type`	What it means
`lifetime`	No rolling window — the cap is a fixed total over the lifetime of the account or grant
`day`	Rolling daily window, anchored to a local timezone
`week`	Rolling weekly window
`month`	Rolling monthly window
`night`	Rolling "observing night" window — local-time anchored to the start of night, so observations early and late in the night roll up to the same period

Each quota also carries:

max_credits — the cap for the period.
timezone — interpreted for the rolling-period start.
anchor_at / starts_at_local_time — fine-grained controls over exactly when each period starts.
enabled — quotas can be disabled without being deleted (so a policy that's temporarily relaxed doesn't lose its configuration).

Multi-quota composition

Both accounts and grants can carry multiple quotas at once. When they do, every enabled quota must be satisfied — the scheduler pauses dispatch as soon as any one of them would be exceeded.

Useful combinations:

Lifetime + weekly — "10 000 credits total, but no more than 500 in any rolling week." The lifetime quota caps the program's total reach; the weekly quota smooths consumption.
Daily + lifetime — a research group with a steady budget ("400/day, max 50 000 lifetime").
Nightly — for classroom workflows where the policy is "everyone gets the same time per observing night."

Account quotas vs. grant quotas

There are two places quotas can live:

ObservingAccountQuota attaches to an ObservingAccount and throttles the collective consumption of all grants under that account.
ObservingGrantQuota attaches to an ObservingGrant and throttles a single grantee's consumption — useful when an account has many grantees and you want per-grantee caps in addition to the account-wide cap.

Both layers compose. If an account has a 500/week quota and a specific member grant under it has a 100/week quota, that member caps out at 100/week and the broader pool of members caps out at 500/week collectively.

What happens when a quota is hit

When any active quota would be exceeded on the next task dispatch, the scheduler simply stops dispatching new tasks against the affected account / grant. Existing tasks continue. Observations stall — they do not error out — and resume once the quota period rolls over (or once additional credits / a new grant become available).

If your observation isn't making progress, the first thing to check is whether one of your quotas has filled up. Look at credits_used on the account and each grant, and compare against the quotas attached to them.

Submitting an observation through an account

In the observation editor, the accounts step is the first thing you do. It shows the grants you have submit-rights through, with their headroom against the relevant quotas and the telescopes they expose. Picking a grant determines which queues — and therefore which telescopes — are eligible to fulfill the observation; the configuration step later narrows further if you want.

For the editor-side detail, see Editor → Accounts step.

First-light accounts

Every new user gets a first-light observing account the moment they sign up. From the user's perspective it's an ordinary observing account with a quota — they can immediately create observations and projects against it, without needing any specific telescope grant to be issued for them.

Mechanically:

Skynet maintains a single parent first-light observing account funded by Skynet-owned queue access grants across the telescopes that participate in the first-light program.
On user signup, Skynet automatically issues a delegated observing grant from that parent account to the new user, creating a subaccount under it.
The user's subaccount inherits the parent's queue access (so it reaches the same telescopes) and carries a Skynet-managed quota (driven by the platform's first_light_credit_limit setting in SkynetConfig) that caps how much the new user can consume.

The first-light account is just an observing account configured this way; no special model fields, no first-light flag. The same machinery (delegated grants, subaccounts, quotas) is what consortiums, classrooms, and organizations use for their own sub-allocations, just with different parents and policies.

Credit accounting and how observations get charged

A few things worth knowing up front:

Creating an observation costs nothing. You can create as many observations as you want without consuming any credit. The editor never blocks creating one for quota reasons.
Credits are tallied as tasks dispatch. When the scheduler hands a task off to a telescope, it records an ObservingAccountTxn against the funding account and grant, incrementing their credits_used.
Throttling is quota-driven. Accounts and grants don't carry a single "limit" field — they carry zero or more quotas, each defining a (period, max_credits) ceiling. The scheduler pauses dispatch when any active quota would be exceeded; existing tasks finish, and dispatch resumes when the quota period rolls over or new credits become available.

Practical consequence: a "stalled" observation is much more likely to be a quota state than a scheduling bug. Inspect each of:

The account's credits_used and any ObservingAccountQuota records attached to it.
Each grant's credits_used and any ObservingGrantQuota records attached to it.

The most restrictive currently-active quota across both layers is what's holding the observation up.

Reference

The full model lives across these schemas:

ObservingAccount — the account itself.
ObservingAccountQuota — quota limits.
ObservingAccountTxn — transaction history.
ObservingGrant and subclasses (OwnerObservingGrant, MemberObservingGrant, GroupObservingGrant, GroupManagedObservingGrant, DelegatedObservingGrant, ExternallyManagedObservingGrant, ExternallyManagedObservingGrantInvitation) — the grant family.