Identification Queue — Policies

This queue accepts identifications in the MPC's identification format, checks each link with PyRoOrb, tries to extend it with Isolated Tracklet File (ITF) tracklets, and forwards it to the Minor Planet Center at a pace the MPC can absorb. It does not replace the MPC: the MPC still decides every identification, and tells the submitter by e-mail.

Numbers in this colour are this server's live settings where it could read them, and the defaults otherwise.

1. Submitting

POST a JSON document to https://www.pyroorb.net/identifications/, or send it as a GET with a JSON body (the verb the MPC's own endpoint takes). It has a header (name, email, optional comment) and links (link_0, link_1, …). Each link names at least two ids: PACKED designations and/or trksubs as [trkSub, date, obs-code], with optional identification_type: "neocp" and an optional orbit.

{"header": {"name": "J. Doe", "email": "jdoe@example.org"},
 "links": {"link_0": {"designations": ["K16G96F"],
                      "trksubs": [["C3XY12A", "2024-03-05", "G96"]]}}}

• The header must carry your name and a valid e-mail: a document without them is refused at once (HTTP 400) and nothing is stored. The MPC credits and replies to them.
• Otherwise the document is stored at once, before any check. There is no limit on how often you may submit; the only limits are on what we send on to the MPC.
• The reply gives a submission number, one id and status per link, and a private status_url with a token. Keep it.
• GET /identifications/?document=N shows where each link is. With the &token=… from your reply it also shows the link's contents, the reasons it was held or censored, what the ITF search added, the link as forwarded and the MPC's answer.
• The MPC tells the submitter its decision by e-mail, at the address in your header: we forward under the submitter's own name and e-mail, never ours.

2. What is forwarded: a link is never edited

What goes to the MPC is your link exactly as received — every field, every value, in your spelling — under your own header, one link per outgoing document. Nothing is repacked or normalised. The only changes are:

• our own instructions noextend / noreject are removed;
• new designations and tracklets found by an ITF search are appended, only when the search LINKED them and raised no warning of its own;
• identification_type: "neocp" is set when one of your tracklets turned out to be on the NEOCP and you had not said so;
• our orbit is added when the search grew the link and you sent no orbit;
• at send time, on a link that carries tracklets only, designations the MPC has already joined to one you name are removed (restating an accepted DES=DES makes the MPC refuse the whole link). This only removes: of each joined family, the first designation you listed stays exactly as you wrote it — it is not replaced by the family's primary designation. This is logged on the link.

3. What we check

4. What is refused (censored)

A censored link is never sent. Three kinds:

• bogus: a format problem (an unpacked designation included), an id we cannot find, or a comet or interstellar designation — the MPC's identification pipeline takes minor planets only; an identification involving a comet goes to the MPC as a Jira ticket. A reviewer may also censor a held link as bogus.
• duplicate: see below.
• manually dropped: a reviewer decided a held link should not go, without calling it bogus.

The dashboard's Spared the MPC card counts every link censored or dropped, for any reason: each is an identification the MPC did not have to process.

Temporary trouble (the archive or the MPC unreachable, a search that crashed) never censors a link. See failures.

5. Duplicates

• Already the MPC's. A link that names only designations (after the ITF extension) and whose designations the MPC has already joined into one family is censored duplicate. A designations-only link is never edited, so one that restates an already-joined pair is censored and should be re-sent without that pair. The check runs after the extension, because a known pair becomes news again once a new tracklet is attached to it.
• Contained in another link. A link is a duplicate only when everything it names is already in another link — a subset or the same set. Sharing an object is not enough: a link naming a different tracklet of an object already sent still goes. Designations are compared by their current MPC family; tracklets by trkSub + station + date within 1.5 days.
  • Against a link already sent: a subset or equal set is a duplicate. A sent link the MPC refused, or filed in conflict, bans nothing, so a corrected subset of it may go.
  • Between links still waiting, only nested pairs interact, and only a link PyRoOrb would send absorbs another. A subset is a duplicate of a superset that PyRoOrb would not hold for review. A superset is never a duplicate: if it is the doubtful one, the subset goes now and the superset waits for review. Of two links naming the same set, one goes: the one PyRoOrb would not hold, then the fewest warnings, then the highest priority score, then the earliest receipt. A link counts as doubtful by PyRoOrb's verdict even when noreject lets it through; a reviewer's release clears it.

6. What is held for review

A link is held, not sent, when the identification check says no (or the joint fit failed), when the check's verdict is one it would not offer for submission (y2, y-systematic, unknown), or when it raised 2 or more warnings. A reviewer sees the warnings and the fit, then releases it (normal pacing) or censors it as bogus. The public dashboard shows only how many warnings a held link has.

7. Order of work

1. Tier 0 first: a link flagged neocp, a link with a tracklet on the NEOCP now, or one naming a designation whose published perihelion distance is under 1.3 au.
2. Within a tier, the priority score = tracklets + 3 × designations, highest first (3 tracklets + 2 designations = 9).
3. Then first come, first served.

8. Pacing of sends to the MPC

The MPC processes identifications by hand. The queue paces what it sends so as not to bury them, checked in this order:

1. Floor. No two sends of any kind closer than 5 s.
2. Immediate. A tier-0 (NEO / NEOCP) link goes the moment our checks finish. These do not wait behind anything and do not count toward the rotation below.
3. Top-up. We read the MPC's own count of unprocessed identification submissions (its status table, re-read every two minutes) and add what we sent since it was last updated. While that is under 250, waiting links go one per floor interval.
4. Cadence. Otherwise one link every 5 minutes, whatever the backlog.

Fairness. Of the paced sends (top-up or cadence), every 3rd is round-robin: the next submitter, in alphabetical order of e-mail address, who has something ready gets their highest-priority link sent. The others go by priority. So one person submitting a thousand links cannot hold everyone else back.

Links are processed even while sending is switched off; they then wait as ready.

9. Failures and retries

• Temporary trouble puts the link back in the queue with a growing delay. After 3 tries it goes on without the ITF extension; if even its astrometry could not be read it is forwarded as submitted, unchecked, under the normal pacing, with a "not checked" warning on its record. The duplicate rules still apply.
• Every status change is a compare-and-set claim. A link is marked sending before it is transmitted, so it cannot be censored, released or sent twice from under the sender.
• A link is sent to MPC only when the MPC answers 200. Anything else is a failed send: an MPC error reply, a timeout or reset after the connection opened (the MPC may have it), a connection that never opened, or a link still sending 15 minutes after it was claimed (the server stopped mid-send; a real send takes under three).
• After any failed send nothing is sent for 30 minutes, NEO / NEOCP links included. The MPC has been seen to receive and queue a submission without ever answering, so a failure may be a send it already has; retrying at once would pile up copies, and a struggling MPC needs time to recover.
• The failed link goes back to ready and is tried again after the pause. Once it has failed 3 times it is held for review, with the failures and the MPC's last answer on its record. A reviewer's Release grants one more try.
• A server restart never fails a send in progress: the server being replaced is left to finish it. If the MPC accepts a link after its send was counted as failed, it is recorded as submitted and not sent again.

10. The noextend and noreject flags

Either may be set on the whole document or on one link. Neither is forwarded to the MPC.

• "noextend": true — the sender already ran an ITF search. We skip ours; every other check still runs.
• "noreject": true — switches off the bogus censors and the hold for review: an id we cannot find becomes a warning instead. Warnings are still counted and shown, and duplicates are still censored. A link the MPC cannot accept at all is still refused at send time. PyRoOrb's own web page sets it, because its user has already seen and clicked through each caution.

11. Tracking the MPC's decision

The MPC's immediate reply is only an acknowledgement. Every 10 minutes we look at what the MPC has published: whether each sent tracklet's observations have been filed under a designation, and whether each designation now belongs to a joined family. A link is then:

12. What is public

• The dashboard shows, per link, the submission number and link name, the submitter's name, its priority, status and times, and the MPC's backlog. It never shows a link's ids or anyone's e-mail address.
• The status lookup without the token shows only status, priority and acceptance; with the token, the contents and reasons. The e-mail address is never echoed back.
• Your submission is forwarded to the MPC under your name and e-mail, and stored on the queue's server.