Administrator overview
The admin surfaces let operators monitor the data pipeline, curate vocabulary, fix individual trials, and audit drift against upstream registries.
Admin routes
| Route | What it does |
|---|---|
/settings | Search Filters · AI Models · Developer tabs. Singleton config. |
/admin/pipeline | Recent pipeline runs + manual trigger. |
/admin/pipeline/[runId] | Per-run drill-down: log, delta trials, spot-review tabs. |
/admin/qa-findings | Nightly-audit divergences against CT.gov + CTRI. |
/admin/curation | All 9 curation domains (umbrellas, aliases, etc.). |
/admin/curation/[domain] | Per-domain editor + version history + rollback. |
/admin/location-aliases | Structured UI for the city_state_aliases curation domain. |
/admin/trials/[registry_id]/edit | Per-trial editor — any column, with audit. |
The dispatch token
Mutating admin actions (curation saves, trial edits, run triggers, audit / regen / flag) are gated by an x-admin-token HTTP header. Read-only admin views are ungated — anyone can see the pipeline run list and QA findings; only mutations require the token.
The token value lives in your deployment dashboard as ADMIN_DISPATCH_TOKEN. This guide does not print or derive it.
Audit trail
Every mutating admin action writes a row to manual_dispatches (action, target, actor, payload). The pipeline run list surfaces this for run triggers; the QA-findings list surfaces it for flag-resolutions; trial edits and curation saves are tracked too.