Skip to content

ROADMAP.md

Latest commit

 

History

History
85 lines (68 loc) · 5.38 KB

ROADMAP.md

File metadata and controls

85 lines (68 loc) · 5.38 KB
Raw

Roadmap — MxMap.it / Osservatorio Nazionale Sovranità Digitale

Derivata dalle issue GitHub aperte + le dipendenze sui dati accumulate. Ordinata per dipendenza e impatto. Stato: giugno 2026. Vedi il contesto in CLAUDE.md (§"Project context: the Italian digital-sovereignty observatory").

Le issue vivono nel repo MxMap: https://github.com/mxmap-it/mxmap.it/issues.

✅ Fatto — fondamenta live

  • Motore dati IT (~22.987 PA), modello di sovranità (bucket 6→4, ISD), confidence scoring (ESORICS).
  • Artefatti pubblici alla root: kpi.json, report.json; pagine statistiche.html, report.html, methodology.html, anomalie.html.
  • Nightly robusta (deploy disaccoppiato dal git, CI smoke, auto-issue); regola "numeri sempre testati-verificati"; dominio custom mxmap.it.

Fase 1 — Baseline del dato → sblocca lo storico

Obiettivo: un run #1 pulito, così serie storiche e sezione "andamento" del report vanno live.

  • [#4] Sistemare i ~700 record PA in anomalia — iterare a mano + automatismi per gruppo. Blocca il run #1. (Vedi anomalie.html + docs/LOW_CONFIDENCE_CASES.md.)
  • Attivare la storicizzazione — togliere il commento agli step historicize/build_dcat in nightly.yml quando #4 è chiusa → si popolano storia.html, le timeline per-ente e il trend del report.

Fase 2 — Asse geografico → attiva gli amministratori locali

Obiettivo: analisi "per aree" (regione → comune), la leva politica più forte (sindaci).

  • ✅ Fatto — mapping comune→regione strutturale. scripts/enrich_geo.py risolve la chiave-sede pulita ipa_codice_comune_istat sul crosswalk ufficiale ISTAT (geo.py) e scrive regione/provincia/comune/macroarea su ogni ente: 20/20 regioni, 100% di copertura (Sardegna via prefissi provincia legacy 112-119).
  • ✅ Fatto — sezione "Analisi per aree" del report. stats.compute_by_region (unit-testata + assert_integrity) → stats_by_region.json + sezione attiva in report.json/report.html: classifica regionale per ISD, sintesi per macroarea, regione più sovrana / più esposta al CLOUD Act.
  • ⏳ Resta: affinamento al comune esatto per la Sardegna (oggi regione+provincia), pagine per-regione dedicate, e — quando #2 ripulisce la fonte — il dato territoriale a grana fine.
  • La grana comune/territorio fine dipende in parte da #2 (qualità della fonte).

Fase 3 — Bonifica della fonte (fondazionale)

  • [#2] Software per un IndicePA ben manutenuto e bonificato — misura autonoma della qualità del dato + cicli di segnalazione (PEC a enti e AgID). Riduce le anomalie (Fase 1) e sblocca dati comune/dominio puliti (Fase 2). È la dipendenza più profonda.

Fase 4 — Irrobustire l'attendibilità

  • [#5] Metodo basato su Email Bounce — il bounce-verifier (già progettato, docs/BOUNCE_VERIFIER_DESIGN.md; serve config/bounce.toml + autorizzazione esplicita all'invio). Valida le classificazioni a bassa confidenza via smarthost + analisi NDR.

Fase 5 — Fiducia & diagnostica

  • ✅ Fatto — [#15] scheda per-ente + hub geografici (SEO). scripts/build_entity_pages.py genera ~53k pagine statiche: una per ente (/ente/{sigla-prov}/{nome-ente}/) con tutti i dati di rilevamento, verdetto di sovranità (riusa il modello canonico), affidabilità, enti vicini come spinta reputazionale, e «Riporta un errore» → CTA «Aiutaci a risolvere l'anomalia» per anomalie/ bassa confidence; più hub regione/provincia/comune, facet per categoria, alias dominio e sitemap a indice (sitemap-enti-{regione} ×20). URL deterministici/collision-free in src/mail_sovereignty/pages.py (unit-testati); git-ignored (solo nell'artifact), coperto dal job smoke.
  • [#6] Pagina di diagnostica — mostra ogni dimensione di raccolta/classificazione da IndicePA in poi, con un pulsante di rendiconto problema per ente. Si lega alla scheda per-ente (#15) + al controllo "Segnala errore" pre-compilato (task #12).

Fase 6 — Attivazione degli stakeholder (motore di advocacy)

  • Integrazione Osservatorio — update-report.yml (fetch di report.json) + un layout Hugo report; più i moduli d'azione per audience.
  • [#3] Emailing agli stakeholder — tipologia di email e di report specifica per stakeholder, mappata sui dati dell'Osservatorio → trasformare i finding segmentati in azione mirata (decisori, stampa, sindaci, …). È il motore di "azionabilità".

Cammino critico (dipendenze trasversali)

[#2] bonifica IndicePA ──┬─→ meno anomalie [#4] ─→ run #1 ─→ storicizzazione live
                         └─→ comune→regione pulito ─→ asse "per aree" ─→ attivazione sindaci
[#5] email-bounce ─→ confidenza più alta ─→ numeri pubblici più solidi
[#6] diagnostica + scheda per-ente ─→ [#3] attivazione stakeholder

In sintesi: le anomalie (#4) e la qualità della fonte (#2) sono il collo di bottiglia che sblocca sia lo storico sia l'asse geografico; #5 alza la confidenza; #6 e #3 chiudono il cerchio trasformando la misura in azione degli stakeholder. La scelta di priorità raccomandata: #4 → mapping regione → #2 in parallelo, poi #6/#3 per l'attivazione.