Cum verificăm conținutul

Cum ajunge un document în bază

1. Draft - se scrie markdown structurat cu o schemă Zod strictă (titlu, sumar, categorie, instituții implicate, pași, termene, costuri, surse oficiale, bază legală, intenții user). Nu se publică niciodată direct în bază fără validare.
2. Validare automată - un script (npm run validate) verifică:
   • schema strictă (Zod)
   • referințe oficiale >= 1 pentru docs publicate
   • format dată YYYY-MM-DD pentru ultima_verificare
   • URL-uri cunoscute ca problematice (ex: pagini ANAF vechi care au dat 404)
   • Pentru ghiduri compuse: verificăm că toate procedurile referite există.
3. Revizie - citirea finală înainte de status_document = „publicat". Se marchează nivel_validare: verificat-intern (citit de autor + măcar un reviewer) sau verificat-jurist (consultat cu jurist; rar acum, ambiție pe viitor).
4. Publicare - documentul devine vizibil public doar când status_document = publicat. Altfel stă în backend, nu apare în sitemap.

Ce înseamnă „verificat intern"

Fiecare procedură are un câmp nivel_validare afișat ca badge:

• Draft editorial - nu se publică niciodată cu acest nivel. Dacă îl vezi, e bug, spune-ne.
• Verificat intern - standard pentru tot conținutul public curent. Înseamnă: citit de autor + cel puțin un pas de review, surse oficiale verificate la publicare.
• Revizuit juridic - consultat cu un jurist. Ambiția, nu realitatea curentă. Când vom avea, îl marcăm explicit.
• Confirmat de instituție - instituția competentă a validat explicit conținutul. Cazuri foarte rare, marcate la fel.

Re-verificare periodică

Fiecare document are o politică de reverificare cu un interval în zile (politica_reverificare.interval_zile) - de regulă 90-180 zile, mai scurt pentru conținut fiscal (ANAF), mai lung pentru documente stabile (buletin, cazier).

Un script (npm run db:stale-audit) rulat săptămânal:

• Identifică documente cu ultima_verificare > intervalul politicii → le marchează stale.
• Trimite raport email administratorului.
• Apare în dashboard-ul intern ca „hot spots" - categoriile cu cele mai multe docs de re-verificat.

Când re-verificăm, actualizăm data, adăugăm o intrare în istoric_modificari (audit trail). Nu ștergem, nu rescriem istoria silent.

Cum funcționează chat-ul (RAG)

1. Embedding - fiecare procedură e trecută printr-un model multilingv (Xenova paraphrase-multilingual-MiniLM-L12-v2, 384 dim) care produce un vector semantic pe titlu + sumar + instituții + intenții + primul paragraf.
2. Retrieval hybrid - când întrebi ceva, calculăm embedding-ul întrebării și-l comparăm cu toate documentele (cosine similarity), plus un scor de keyword overlap. Top 5 relevante intră în contextul modelului.
3. Generare - modelul primește ca instrucție strictă: „răspunzi EXCLUSIV pe baza documentelor din baza de cunoștințe. Dacă informația nu e acolo, marchează refuzul."
4. Fallback controlat - când întrebarea nu e acoperită, modelul emite marker-ul [NEEDS_FALLBACK] sau un tipar de refuz. Serverul detectează și trece pe un al doilea apel cu temperatură joasă, răspunzând din cunoașterea generală, dar DOAR dacă modelul își auto-evaluează încrederea peste un prag minim. Răspunsul apare cu banner clar: „⚠️ Răspuns în afara bazei noastre verificate · încredere estimată X%".

Ce nu permitem: halucinări fără disclaimer. Dacă modelul scrie cifre specifice și nu le avem în documente, banner-ul de avertizare trebuie să fie acolo. Dacă lipsește — e bug, raportează-l.

Ce surse folosim

• Legislație: legislatie.just.ro (Portalul Legislativ al României), Monitorul Oficial
• ANAF: anaf.ro, declarații DUF, pagina oficială SPV
• MAI: hub.mai.gov.ro, dgep.mai.gov.ro, spclep.mai.gov.ro
• ANCPI: ancpi.ro (cadastru, carte funciară)
• ONRC: onrc.ro (Registrul Comerțului)
• Pensii / Muncă: cnpp.ro, mmuncii.ro
• Sănătate: cnas.ro, pagina casei locale de asigurări
• Auto: drpciv.ro, politiaromana.ro (contravenții)
• Ghișeul.ro - pentru plata taxelor locale + amenzi

Pagini care s-au dovedit instabile (scot 404 după câteva luni) sunt trecute pe o listă neagră internă și nu le mai folosim ca surse canonice. Le înlocuim cu pagina stabilă a instituției.

Ce e „thin content" și ce facem cu el

Procedurile cu body < 200 cuvinte și fără structură (fără documente, termene, costuri, >1 referință) sunt marcate automat robots: noindex. Există dar nu diluează trust-ul domain-ului la Google. Se re-indexează automat când sunt completate.

Cum raportezi o greșeală

Când semnalezi ceva concret (cifră greșită, link spart, pas omis), corectura apare pe site cu menționare în istoric_modificari și data nouă de verificare. Tu nu apari nominalizat decât dacă vrei (noi păstrăm comunicare privată).

Limite pe care le recunoaștem

• Un singur autor activ acum. Review-ul e intern, nu cross-checked de 3 experți. Asta înseamnă că și greșelile sistematice (bias, lacune) pot persista mai mult.
• Regulile locale diferă între primării (sectoare București, orașe mari vs. mici). Ce e scris aici e la nivel național; dacă primăria ta are reguli diferite, poate să nu fie captat. Vezi și pagina de județe pentru context local.
• Chat-ul nu păstrează contextul între sesiuni decât dacă ești autentificat. Nu facem „memorie persistentă" pe anonimi - privacy wins over convenience.