Integrated guide

Using the review atlas

The atlas is an exploratory screening and peer-review tool. Its rankings prioritize follow-up; they are neither impact probabilities nor confirmations of impact origin.

What the atlas does

The main map brings together the manuscript study candidates, repaired impact catalogues, African review structures, endogenic controls, active faults, and community submissions. Use the layer controls to compare candidate geometry against known structures and controls before drawing or reviewing a new record.

Authenticated reviewers also get private candidate layers, source-quality/elevation/magnetic overlays, point gravity inspection, drawing tools, saved map preferences, and a live analysis status panel. Staff users additionally see all worker queue counts in that status panel.

Map and evidence layers

Study candidates are the original arcuate geometries. Structure fields are repeated across member arcs, so use consolidated structure ranks for review decisions. Community candidate layers show submitted records by review state in popups and downloads. Layer appearance controls set line style and thickness for each layer.

Remote basemaps are streamed through an allowlisted proxy and are not stored on the server. The 2D map exposes point gravity samples because WGM2012 tiles use a geographic tiling scheme that is not directly compatible with Leaflet Web Mercator. The 3D globe displays native Bouguer and isostatic gravity grids correctly, and Cesium World Terrain is enabled when the deployment supplies CESIUM_ION_TOKEN.

Submitting a candidate

  1. Log in and choose a drawing method on the Atlas: centre-to-rim drag, opposite rim points, or typed diameter from a centre point.
  2. Open the submission form from the draft marker and review the pre-filled location, diameter, and source fields.
  3. Describe the observed feature, cite the source, include scale/resolution when available, and state the strongest non-impact or endogenic alternative.
  4. Confirm the interpretation guardrail: morphology and scores do not confirm an impact origin.
  5. Submit. Passing records appear in your library, may appear in community layers, and are queued for automated follow-up analysis.

Current baseline rules

The intake baseline is configurable in Django Admin under Portal → Review configuration. Current values are:

The intake score measures documentation completeness and reviewability. It does not alter or imitate the study follow-up score.

Automated analysis

Baseline-passing submissions and staff-requested retries create CandidateAnalysisJob records. A trusted local worker polls /api/analysis/jobs, claims queued jobs with the shared ANALYSIS_WORKER_TOKEN, computes the study follow-up score using local scientific data, and posts results back to the deployment.

Exact scoring requires the numerical GEBCO 2026 grid and the study geological-province index. If either source is unavailable to the worker, the candidate remains stored and marked “scientific source data unavailable”; no visual-tile surrogate is substituted.

The live sidebar analysis panel shows personal progress for authenticated reviewers: queued, claimed, running, scored, failed, source-unavailable, and recent candidate results. Staff users also see global worker queue counts.

Follow-up score

New candidates use the same no-imagery method as the manuscript: data quality × (0.78 × topography score + 0.22 × geology independence). The topography score combines radial alignment (0.24), annular peak percentile (0.22), angular continuity (0.18), radius match (0.14), centre match (0.12), and annular relief (0.10).

The result is a prioritization score for scientific follow-up. It is uncalibrated as an impact probability and must be interpreted alongside mapped geology, gravity/magnetic context, known controls, and source quality.

Review queue workflow

Staff use the Review queue as the main operating surface. It provides summary counts, search, review-status filters, analysis-status filters, follow-up scores, intake scores, evidence fields, baseline checks, diagnostics, and review history.

Use Record review to move a candidate through baseline passed, under review, accepted, or rejected. Every status transition writes a CandidateReview audit record with reviewer, previous state, new state, note, and timestamp. Use Queue analysis when a staff decision should force or retry automated scoring, including records that did not pass the public intake gate.

Status meanings

Needs revision means the candidate failed the intake baseline and remains private/editable by its owner. Baseline passed - unreviewed means the record is public but not scientifically reviewed. Under review means staff assessment has started and owner editing is locked. Accepted means the candidate is retained in the review catalogue. Rejected means staff does not retain it for catalogue review.

Analysis states are separate from review states. Not scored, queued, claimed, and running are processing states. Scored with study method means the worker posted a successful follow-up result. Scientific source data unavailable and Scoring failed require staff attention or a retry.

Admin configuration

Superusers configure accounts, review rules, and data records in Django Admin. The key model is Review configuration, which controls baseline thresholds and duplicate screening without a code deploy. Candidate submissions, analysis jobs, analysis runs, artifacts, and review audit records are also visible there for inspection.

Changing Review configuration affects future submissions and edits. Existing candidates keep their stored baseline checks until they are edited, re-evaluated, or explicitly handled by staff.

Sources and publication

Source repository ↗ · Published draft ↗