You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🔄 EU Parliament Monitor — Business Continuity Plan
🛡️ Classification-Driven Business Resilience for European Parliament Intelligence 🎯 Systematic Recovery Planning Through AWS S3 + CloudFront Static Site Architecture
📋 Document Owner: CEO | 📄 Version: 2.3 | 📅 Last Updated: 2026-05-30 (UTC) | 🏷️ Platform Release: v0.9.26 🔄 Review Cycle: Semi-Annual | ⏰ Next Review: 2026-11-30
EU Parliament Monitor's business continuity framework demonstrates how systematic recovery planning directly enables both operational resilience and democratic transparency excellence. Our classification-driven continuity approach serves as both operational necessity and demonstration of enterprise-grade practices for an open-source European Parliament Intelligence Platform.
This plan ensures European Parliament monitoring and multi-language news generation (14 languages) can continue during and after disruptive events, based on the Classification Framework impact analysis and recovery requirements.
— James Pether Sörling, CEO/Founder
📊 Business Impact-Driven Recovery Framework
🎯 Business Impact Analysis Integration
Our business continuity planning is directly driven by the Classification Framework business impact analysis matrix:
graph TB
subgraph BIA["📊 Business Impact Analysis"]
DEMOCRATIC[🏛️ Democratic Impact<br/>Transparency Disruption]
OPERATIONAL[⚙️ Operational Impact<br/>Platform Availability]
REPUTATIONAL[🤝 Reputational Impact<br/>Public Trust]
TECHNICAL[💻 Technical Impact<br/>Service Degradation]
end
subgraph RECOVERY["🔄 Recovery Prioritization"]
CRITICAL[🔴 Critical Recovery<br/>RTO ≤ 2 hours]
HIGH[🟠 High Priority<br/>RTO 2-4 hours]
MEDIUM[🟡 Medium Priority<br/>RTO 4-24 hours]
STANDARD[🟢 Standard Recovery<br/>RTO > 24 hours]
end
subgraph BUSINESS["🏢 Platform Functions"]
CORE[🏗️ Core Platform<br/>Static Site Serving]
NEWS[📰 News Generation<br/>14-Language Pipeline]
DATA[📡 EP Data Integration<br/>MCP Server Connection]
CI[⚙️ CI/CD Pipeline<br/>Build & Deploy]
end
DEMOCRATIC --> CRITICAL
OPERATIONAL --> HIGH
REPUTATIONAL --> MEDIUM
TECHNICAL --> HIGH
CRITICAL --> CORE
HIGH --> CORE
HIGH --> NEWS
MEDIUM --> DATA
STANDARD --> CI
style BIA fill:#1565C0,color:#fff
style RECOVERY fill:#FF9800,color:#fff
style BUSINESS fill:#4CAF50,color:#fff
IMF is the sole authoritative source for economic / fiscal / monetary / trade / FDI / exchange-rate / banking-soundness context. When dataservices.imf.org is unavailable, the agent must (a) attempt the cached analysis/daily/<date>/<run>/cache/imf/*.json path first, (b) if no cache exists, mark the economic-context artifact as IMF Source: knowledge-only (which Stage-C blocks), and (c) defer the article to a later run when IMF recovers.
Probability
Low–Medium (IMF SDMX 3.0 is generally stable; transient SDMX-XML 503s are observed during scheduled IMF maintenance windows)
Recovery
Automatic on IMF recovery — re-run the workflow; the cached probe JSON is reused for back-fill on subsequent same-day runs. Stage-C imf-cache:missing / imf-source:knowledge-only issues block article PR creation until IMF data is present. The legacy WB IMF requirement fallback is retired.
Mitigation
(a) Single-source IMF surface (IMFMCPClient SDMX 3.0 with WEO + FM 5-year forecasts) with per-call cache writes to cache/imf/*.json; (b) per-source IMF_API_BASE_URL / IMF_API_TIMEOUT_MS overrides; (c) analysis/methodologies/imf-indicator-mapping.md §7 vintage rules so an article can use last-known-good cached data with explicit vintage; (d) Stage-C validate-analysis-completeness.js enforces IMF presence and rejects WB economic indicator codes (NY.GDP.*, FP.CPI.*, SL.UEM.*, …) and "World Bank … GDP/inflation/…" prose claims inside intelligence/economic-context.md.
Manual local runs possible via npm run generate-article:all + npm run generate-news-indexes; push generated artifacts directly to main for deploy-s3.yml to pick up when runners recover
Mitigation
15 agentic workflows compiled into deterministic .lock.yml via gh aw compile --validate (pinned GH_AW_VERSION: v0.77.3) — locally reproducible; static build fully scriptable
Scenario 9: Copilot / Claude / Codex Quota Exhaustion
Swap engine: field in workflow frontmatter (Copilot ↔ Claude ↔ Codex); if all AI engines unavailable, human-author English source and trigger news-translate directly
Mitigation
Engine-agnostic gh-aw frontmatter; quality thresholds in analysis/methodologies/reference-quality-thresholds.json enforce minimums regardless of engine
.lock.yml compilation fails or produces incorrect runtime; agentic workflows error during compile-gate
Probability
Low
Recovery
Pin to known-good GH_AW_VERSION in .github/workflows/compile-agentic-workflows.yml; rollback via git revert; if rollback insufficient, convert affected workflow to traditional YAML with human-author mode
Mitigation
Pinned version in infra workflow; .lock.yml artifacts versioned in git; sibling repos (Hack23/cia, Hack23/homepage) provide cross-reference for upgrade regression
Scenario 12: npm Registry Outage or Package Tampering
📋 Aspect
📊 Detail
Impact
Consumers of @hack23/euparliamentmonitor npm package blocked; or dependency install fails in CI
Probability
Very Low
Recovery
GitHub Packages mirror available via package namespace; verify SLSA Level 3 provenance attestation via gh attestation verify; if tampering suspected, rotate publishing OIDC identity and republish from tag
Mitigation
Published with provenance + SLSA 3 attestations; npm ci + package-lock.json locks dependency graph; Dependabot surfaces supply-chain alerts
Scenario 13: Compromised Maintainer Credential
📋 Aspect
📊 Detail
Impact
Potential unauthorized push, workflow edit, or release
Branch protection + required reviews on main; OIDC federation (no long-lived AWS keys); GitHub 2FA mandatory; SHA-pinned actions
Scenario 14: MCP-Borne Data Poisoning
📋 Aspect
📊 Detail
Impact
Hostile EP MCP response injects misleading content or tries to bypass validator gates
Probability
Very Low (Hack23-maintained)
Recovery
scanHtmlForFallbackLeaks + FALLBACK_TEMPLATE_PATTERNS gate in validate-analysis-completeness.js aborts the PR; reference thresholds (intelligence/mcp-reliability-audit.md ≥200 words / breaking ≥385) catch low-signal content; human review on every agentic PR
Mitigation
Pre-translation validator gate scans all EN sources before fan-out; reference quality thresholds in analysis/methodologies/reference-quality-thresholds.json; 5-layer gh-aw security (AWF firewall, Docker sandbox, safe-output constraints, JSONL audit, lock file compilation)
🚨 Incident Response Procedures
Phase 1: Immediate Response (0-30 minutes)
Assessment and Safety:
🛡️ Safety First: Ensure no security compromise in progress
📊 Impact Assessment: Determine scope using criticality matrix above
🚨 Alert: Create GitHub Issue tagged incident
📋 Documentation: Begin incident logging with timestamps
Verify AWS S3 sync and CloudFront invalidation status (deploy-s3 workflow)
Check GitHub Pages fallback deployment status
Assess which of the 14 language versions are affected
Phase 2: Short-Term Recovery (30 min – 2 hours for critical static-site serving; up to 4 hours for non-critical/high-priority functions)
For critical static-site availability (primary S3/CloudFront or GitHub Pages fallback), full restoration must occur within 2 hours (the documented RTO). The broader 2–4 hour window applies only to non-critical or high-priority supporting functions (e.g., news content generation, auxiliary automation).
Operational Continuity:
🌐 If AWS S3/CloudFront: Check S3 bucket status, CloudFront distribution health; failover to GitHub Pages fallback
⚙️ If CI/CD: Debug and fix the workflow, then redeploy by rerunning the last successful deploy-s3 workflow run from the GitHub Actions UI or by pushing a no-op commit to the main branch in accordance with change-control rules
📡 If Data Source: Existing content serves users, monitor EP API status
📦 If Repository: Restore from fork or local clone
🔒 If Security: Isolate affected components, roll back to known-good state
Critical System Procedures:
Static site: If AWS S3 + CloudFront experiences an extended outage (>30 minutes), perform a GitHub Pages fallback using the current static site layout, or deploy from local build to an alternative CDN, following the dedicated runbook: GitHub Pages Failover.
Build pipeline: Run npm run build locally, push static assets directly
Source repository: Restore from contributor forks (distributed backup)
Phase 3: Full Recovery (4-24 hours)
Sustained Operations:
✅ Verify all 14 language versions are serving correctly (5,231 HTML articles in news/)
🧪 Run full test suite (npm run lint && npm run test) — 5,933+ Vitest tests across 153 test files
📰 Re-run affected agentic workflows to regenerate news + indexes + sitemap (npm run build / npm run generate-article:all / npm run generate-news-indexes / npm run generate-sitemap)
🔍 Validate E2E tests pass (npm run test:e2e) — Playwright + axe-core WCAG 2.1 AA
📋 Document incident and lessons learned in GitHub Issue
Phase 4: Recovery Normalization (24-72 hours)
Return to Normal Operations:
✅ System fully restored and validated
📊 Post-incident review conducted
📋 BCP updated with improvements
🧪 Schedule follow-up testing
📢 Communicate resolution to stakeholders
🛡️ Supplier Dependency Matrix
Supplier/Service
Service Type
Criticality
Backup Strategy
Recovery Time
AWS S3 + CloudFront
Static Site Hosting
Critical
GitHub Pages fallback; alternative CDN (Cloudflare/Netlify)
1–2 hours
GitHub Repository
Source Code Storage
Critical
Local clones, contributor forks
15 minutes
GitHub Actions
CI/CD + gh-aw Runtime
High
Manual local build + deploy
4 hours
GitHub Copilot Business
AI inference via gh aw
High
Engine switch (Claude / Codex) in workflow frontmatter; human fallback
30 minutes
EP MCP Server (european-parliament-mcp-server@1.3.20)
Article continues without WB cross-refs; non-economic claims relax to "data unavailable for current vintage" with explicit caveat
N/A (graceful degrade)
IMF REST (SDMX 3.0, native IMFMCPClient)
WEO + FM forecasts (sole authoritative economic source)
High
Cached cache/imf/*.json reused on transient outage; if no cache and live IMF down, Stage-C blocks article (imf-cache:missing); IMF_API_TIMEOUT_MS configurable.
CloudFront distribution, S3 bucket policies and DNS managed via code/automation (no unmanaged click-ops)
Fallback: GitHub Pages deployment path reserved as a secondary publishing option; if activated, the configuration and procedure MUST be documented and, when automated, expressed as a version-controlled workflow in .github/workflows/
Emergency exception: If GitHub Pages Settings → Pages configuration must be changed manually during an incident, the change MUST be documented in the incident log (who/when/what/why) and, after resolution, either codified into automation or reverted back to the documented default configuration (primary S3 + CloudFront path)
All steady-state infrastructure and CI/CD configuration is declarative and version-controlled; any emergency console changes are temporary and either codified or rolled back
🧪 DR Testing & Runbooks
Recovery Runbook Index
Runbooks live in runbooks/ and are invoked by the Incident Response Procedures above. All runbooks are version-controlled, Markdown-only, and executable by any maintainer with standard repository push + AWS OIDC access.
