Date validate despre patrimoniul construit al României

O fișă de monument completată greșit nu se corectează singură. Se propagă: ajunge în rapoarte, în decizii de finanțare, în documentații de urbanism, iar fiecare copie a erorii costă mai mult decât precedenta.

Iar provocarea este de scară națională: mii de monumente istorice, situri arheologice și zone de protecție, cu date colectate din teren, de operatori diferiți, în condiții diferite, pentru un singur inventar care trebuie să fie corect. Terenul complică totul: multe monumente și situri arheologice nu stau în orașe cu semnal bun, ci în sate, pe dealuri, în zone fără semnal.

În cadrul programului Heritas, Ministerul Culturii a stabilit standardul: un instrument unic de colectare și actualizare din teren a datelor despre patrimoniul cultural imobil (monumente istorice, zone de protecție, unități administrativ-teritoriale), construit pe un principiu clar, definit de beneficiar de la început: nicio informație nu intră în inventarul național fără să treacă printr-un workflow de validare.

Zenvertising a proiectat, dezvoltat și livrat integral sistemul: analiză, arhitectură, design, aplicația de teren pentru tabletă, platforma web de administrare și pachetul complet de documentație de acceptanță. Am pornit de la specificația funcțională a beneficiarului și am transformat-o mai întâi într-un document de analiză de business, cu workflow-uri desenate explicit, matrice actor-funcționalități și scenarii de utilizare măsurabile. Abia apoi am scris cod.

Heritas este construit în jurul unui workflow de validare. Fiecare fișă trece prin trei mâini, cu roluri și responsabilități separate:

• Operatorul colectează datele în teren și trimite la verificare fiecare secțiune pe măsură ce o termină, fără să aștepte fișa întreagă.
• Verificatorul primește secțiunile în coada sa, le aprobă sau le returnează cu motiv. Motivul ajunge la operator chiar deasupra secțiunii vizate: „Completați datarea conform Monitorului Oficial.”
• Aprobatorul preia fișele finalizate și dă aprobarea finală. Abia atunci datele intră în inventar.

Lucrul pe secțiuni scurtează drumul: verificatorul poate începe controlul fără să aștepte fișe întregi, iar un retur blochează doar secțiunea vizată; restul lucrării merge înainte. Statusul fiecărei secțiuni (draft, completată, în verificare, validată, returnată) este vizibil în orice moment, iar statusul fișei se calculează singur, din statusurile secțiunilor.

Înainte de trimitere, operatorul are la dispoziție o verificare de completitudine direct pe device: sistemul îi arată ce câmpuri obligatorii lipsesc din secțiune, fără să schimbe niciun status. După trimitere, fiecare tranziție (completare, trimitere, validare, retur, aprobare) se înregistrează în audit trail, cu autor, rol și timestamp. Oricând se poate vedea cine a aprobat o fișă și când.

Firul roșu al acestui studiu este o fișă reală: Situl arheologic de la Pietroasele (cod LMI BZ-I-s-A-02263), castrul roman și termele din satul buzoian unde s-a descoperit tezaurul „Cloșca cu puii de aur”. Un sit de grupă A, într-o zonă unde semnalul de date e mai degrabă un noroc. De aceea aplicația de tabletă a fost gândită offline-first de la prima linie de cod:

• Baza de date locală criptată (SQLCipher) păstrează fișele, schemele și valorile pe device.
• Sync-ul este controlat: modificările se acumulează într-o coadă vizibilă, se trimit la cerere și se pot relua individual dacă rețeaua pică pe parcurs. După autentificare, schemele și valorile fișelor alocate se descarcă automat în fundal.
• Hărțile funcționează complet offline, pe tile-uri vectoriale pregenerate pentru județ, cu GPS pentru centrare, capturi de tip punct sau poligon și fotografii cu geotag puse la coadă pentru upload.

Formularul însuși este motorul aplicației. Fișa de patrimoniu imobil are 13 secțiuni și sute de câmpuri, dar niciunul nu este hard-codat: structura este definită ca schemă, versionată pe server, iar aplicația o interpretează la runtime: câmpuri text, picklist-uri, repeatere imbricate, câmpuri condiționate care apar doar când devin relevante și lookup-uri în cascadă pe nomenclatorul teritorial, unde județul filtrează UAT-urile și UAT-ul filtrează satele. Validarea câmpurilor obligatorii rulează local, pe regulile schemei, iar operatorul are un check de completitudine înainte de trimitere.

Versionarea schemelor protejează lucrul în curs: fiecare fișă își fixează versiunea de șablon la creare, deci un update ulterior al modelului nu invalidează fișele deschise. Câmpurile completate automat de sistem (codul LMI, titlul fișei) rămân în afara mâinii operatorului, deci în afara erorii umane. Un tip nou de fișă înseamnă o schemă nouă, nu o aplicație nouă.

Iar pentru că tabletele circulă între oameni, ele sunt gestionate ca device-uri înregistrate, cu lifecycle propriu (pending, activ, blocat, revocat) și alocare exclusivă pe operator. La predarea tabletei către alt operator, datele locale ale predecesorului se șterg complet înainte de prima autentificare. Niciun operator nu vede lucrarea altuia.

Tot ce colectează terenul ajunge în backend-ul web, unde se administrează programul: 11 module de administrare și 17 widget-uri de dashboard diferențiate pe rol. Fiecare rol are propriul dashboard: verificatorul își vede coada, performanța operatorilor din subordine (rată de retur, progres pe secțiuni) și cele mai vechi secțiuni aflate în așteptare; aprobatorul urmărește funnel-ul de aprobare și timpul mediu de așteptare; administratorul are imaginea întregului sistem, de la activitate la sync și utilizatori.

Gestiunea operațională acoperă tot ciclul de viață al datelor:

• Fișe și șabloane, cu căutare și filtre pe cod LMI și unitate teritorială, cu fațete indexate automat din valorile fișelor.
• Alocări pe rol: operator, verificator și aprobator per fișă, cu o singură alocare activă per rol și istoric complet.
• Device-uri și alocări device-operator, cu whitelisting și blocare/revocare instant.
• Nomenclatoare teritoriale (județ → UAT → sat) și importuri structurate, validate rând cu rând înainte de aplicare.
• Exporturi și rapoarte: situația fișelor pleacă din sistem în format tabelar, filtrată la fel ca pe ecran.

Iar totul rămâne trasabil: audit trail-ul înregistrează fiecare tranziție de workflow și fiecare modificare, cu autor, rol și timestamp, iar log-urile de sync păstrează fiecare operațiune venită de pe teren, cu status și mesaj de eroare unde e cazul. Cine a modificat o fișă și când nu e o anchetă: e un filtru în listă.

Datele despre patrimoniu ajung în decizii publice, așa că protecția lor a fost tratată ca cerință de bază:

• Autentificare în doi pași pe platforma web, cu cod trimis pe e-mail.
• Bază de date criptată pe device (SQLCipher): dacă tableta se pierde, datele rămân ilizibile fără cheia de criptare.
• Acces pe trei chei independente: device activ + alocare device-operator activă + alocare pe fișă activă. Oricare dintre ele revocată, accesul dispare.
• Permisiuni pe rol la nivel de acțiune, în ambele aplicații.
• Audit trail ca sursă de adevăr pentru cine, ce și când, de la prima completare până la aprobarea finală.

Proiectul a fost livrat în 9 săptămâni de la fundație până la go-live, acoperind 93 de user stories și 47 de ecrane proiectate. În cifre: 2.548 de teste automate și 47 de migrări de bază de date.

Ritmul a fost dat de opt milestone-uri săptămânale (fundație, autentificare, liste și sincronizare, motorul de fișe, media, hartă și GPS, sync în scriere, consolidare și accesibilitate), fiecare închis cu criterii de acceptanță explicite și cu toate testele trecute înainte de următorul.

Livrarea a urmat cadrul de acceptanță stabilit de beneficiar, cu peste 20 de livrabile formale: analiza de business, arhitectura logică și fizică, designul bazei de date, planul și documentația de testare, mecanismele de securitate, planurile de deployment și rollback, soluția de backup și manualele de utilizare pentru ambele aplicații. Documentele nu s-au scris la final, ci au însoțit fiecare etapă.