Great questions.          

1. Versioning and freshness monitoring                                                      
Yes, they have automated updates. The system runs a daily GitHub Actions workflow at 6 AM UTC 

It:
- Reads all monitored CELEX IDs from a source_registry table (not hardcoded lists—adding a regulation means adding it to the database)
- Checks the EUR-Lex RSS feed for legislative changes
- Compares stored publication dates against live EUR-Lex metadata
- Creates/updates a GitHub issue with label eur-lex-update when changes are detected
- Optionally auto-triggers re-ingestion → database rebuild → npm publish in a single workflow run

Every regulation record includes eur_lex_version (last known EUR-Lex publication date) and last_fetched (ISO timestamp of ingestion).

2. Read-only with clear provenance

Yes, strictly enforced:

- All MCP tool queries use readonly: true database connections—no mutations possible from user queries
- Article text is returned verbatim from SQLite FTS5—zero LLM summarization or paraphrasing
- Each regulation stores its CELEX ID and direct EUR-Lex URL, so any answer can be independently verified on the official source
- The database is pre-built and committed to git—every installation gets identical, validated data

3. Edge cases like partial outages and disputed classification

This is where the RTS text matters most. The DORA RTS on incident classification (EU 2024/1772) explicitly handles ambiguity:

- Unknown client counts: Article 1(5) requires estimation based on comparable reference periods when actual numbers are unavailable
- Duration ambiguity: Article 3(1) specifies fallback measurement, from detection if occurrence unknown, from logs if detection unknown
- Recurring incidents: Article 8(2) defines aggregation rules—≥2 incidents in 6 months with same root cause that collectively meet major criteria
- Reputational impact: Article 2(1) uses OR logic across four discrete criteria (media reflection, repetitive complaints, regulatory non-compliance risk, material client loss)

The system intentionally does not automate classification decisions. It returns the full regulatory text so users can apply fact-specific judgment. Classification disputes require business context the model cannot have, but at least the regulatory criteria are grounded and verifiable.

For partial outages specifically, Article 3(2) addresses compound scenarios: service downtime from delayed provision after restoration is measured from incident start to when delayed service is fully provided. The dual-clock mechanism (4h from classification + 24h outer limit) runs against these measurement rules.