# Source Service-Level Agreement (SLA)

**Version:** 1.0 — 2026-04-27
**Owner:** APS Reg-Dashboard
**Audience:** PRRC, QM, regulatory affairs leads using the dashboard for PMS/PSUR/SSCP work

This document describes the freshness, completeness, and reliability targets for each agency feed surfaced in the dashboard. It is the authoritative reference for "is this data still trustworthy for a regulatory decision?".

---

## 1. Severity tiers

Every agency feed is classified into one of three operational tiers based on regulatory criticality. The tier dictates the freshness threshold, the alert escalation, and the expected SLA on data refresh.

| Tier | Freshness threshold | Stale-data badge | Use cases |
|------|--------------------:|------------------|-----------|
| **Vigilance (V)** | 30 days | ⚠ shown after 30d | MDR Art. 87 vigilance, PMS, FSCA tracking, signal detection |
| **Catalogue (C)** | 365 days | ⚠ shown after 365d | NB designation, manufacturer authorisation, drug catalogues, pricing references |
| **Reference (R)** | None | (badge suppressed) | Standards, guidance, ICH/IMDRF library, evergreen reference docs |

Tier is auto-assigned at scrape time from the agency name pattern (`MAUDE|RECALL|DSU|YELLOW|MPA|EUDAMED|FAERS|VIG` → V; everything else → C).

---

## 2. Per-agency targets

| Agency feed | Tier | Cron schedule | Target latency | Notes |
|-------------|:----:|---------------|---------------:|-------|
| FDA MAUDE | V | hourly during US business hours, 4× off-hours | ≤24h | Vigilance — primary signal source |
| FDA Recalls | V | every 4h | ≤24h | Class I/II/III; mapped to severity |
| FDA Warning Letters | V | daily 02:00 UTC | ≤72h | FEI cross-reference where available |
| FDA Drug Establishment Reg | C | weekly | ≤14d | Catalogue — facility registry |
| EMA EudraGMDP | V | weekly Sun 03:00 | ≤14d | **Currently paused** — EMA Azure SSO migration |
| EUDAMED MD | V | every 6h | ≤24h | Vigilance + UDI; deep history available |
| MHRA DSU + Yellow Card | V | daily | ≤48h | UK vigilance |
| MHRA MIA | C | weekly | ≤14d | Manufacturer Authorisation |
| Health Canada Recalls/MedEffect | V | every 6h | ≤48h | EN+FR captured original-first |
| TGA Australia | V | daily (via Sydney SOCKS5) | ≤72h | Geo-blocked; proxy-routed |
| MFDS Korea | V | daily | ≤72h | KO original captured; DeepL translated |
| PMDA Japan | V | daily | ≤72h | JP original captured |
| HSA Singapore SHARE | V | daily | ≤48h | Selenium |
| NMPA China CDE | V | daily | ≤7d | **Deferred** — proxy + scraper open |
| ANVISA Brazil | V | daily | ≤72h | Power-BI Selenium for some endpoints |
| Roszdravnadzor Russia | V | weekly via Wayback | ≤21d | **Geo-blocked** — Wayback fallback only |
| INVIMA Colombia | V | daily | ≤7d | Per-alert PDF date fetch is slow — incremental mode pending |
| EFDA Ethiopia | V | weekly | ≤21d | **Blocked** — needs Selenium / Wayback |
| DGDA Bangladesh | V | daily | ≤7d | Public-alerts portal works (60 EN-titled alerts) |
| Phil-FDA Philippines | V | daily (Selenium) | ≤72h | CloudFront blocks plain requests |
| WHO PQ + Substandard alerts | V | daily | ≤72h | Two distinct feeds |
| WHO Biologicals TRS | C | weekly | ≤14d | Catalogue |
| ClinicalTrials.gov + EU CTIS | C | daily | ≤48h | Trial registry filter for ATMP/MD |
| NICE / G-BA / HAS / CMS / Lauer-Taxe | C | weekly | ≤14d | HTA + pricing references |
| BDPM (FR) | C | monthly | ≤45d | 36k records — translation pending |
| MDCG / IMDRF / Team-NB | R | weekly | best-effort | Evergreen reference; freshness badge suppressed |
| ICH / EMA CHMP calendars | R | monthly | best-effort | Calendar/date-driven |
| NANDO (NB designation) | C | **deferred** | — | SMCS SPA migration; static `data/nb_bridge.json` is the working snapshot. See `project_nando_smcs_migration.md` |

---

## 3. Operational guarantees

### 3.1 What APS commits to
- **Scrape execution**: each cron-scheduled scraper runs at the cadence above unless the source is publicly down.
- **Original-language preservation**: every event is stored verbatim in its source language; `translator.py` produces machine translations into `event_translations` without overwriting the original.
- **Provenance**: every event has source URL, source ID, scrape timestamp, and a record UUID — surfaced in the event-detail modal under "Source provenance & audit trail".
- **Severity audit**: when APS reclassifies an event severity, the original severity is preserved and shown in the modal.
- **Stale-data signalling**: events older than the freshness threshold are flagged with a ⚠ badge in the events table and a banner in the detail modal.
- **Deferred sources**: any source that cannot be scraped is documented with a memory file and a "deferred" status — never silently dropped.

### 3.2 What the dashboard does NOT guarantee
- **Real-time mirror**: the dashboard is a delta-aware aggregator, not a live mirror. Always verify against the live source URL before any regulatory action.
- **Translation accuracy**: machine translations are flagged with `MT` and a yellow banner. The original is the sole source of truth for regulatory decisions.
- **Severity correctness**: the APS rules engine reclassifies severity using product-class + content keywords (Class III, IVD-D, FSCA, CVSS≥7, KEV). The reclassification is auditable but is not a clinical assessment.
- **Coverage of every notice**: agencies sometimes publish via channels APS does not yet ingest (e.g. social media, mailing lists). Critical regulatory work must be cross-checked.

---

## 4. Incident response

When a scraper goes red on the source-health drilldown for ≥48h on a tier-V feed, or ≥14d on a tier-C feed:
1. APS investigates within 1 business day.
2. If the source is up but the scraper is broken, the scraper is fixed and a backfill run is kicked off.
3. If the source is down or migrated (e.g. NANDO → SMCS), the agency is marked deferred and a memory file is written.
4. A status banner is shown in the affected source-health row.

Audit events for triage decisions (acknowledge / assign / close) are persisted via the `alert_*` API endpoints and visible in the event-detail modal under the PRRC workflow section.

---

## 5. Validation linkage

This SLA is the operational complement to the validation pack in `docs/validation/`. The URS section "Functional requirements" pulls freshness thresholds from this document; the OQ test protocol verifies the stale-data badge behaviour against these thresholds.

---

*This document is reviewed quarterly. Discrepancies between the per-agency table and observed behaviour should be filed as a memory entry under `project_*.md`.*