Cum verificăm conținutul

Cum ajunge un document în bază

1. Draft - se scrie markdown structurat cu un schema 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 : viitor posibil).
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. Însemnă: citit de autor + cel puțin un review pass, 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 se poate acum: halucinări fără disclaimer. Dacă modelul scrie cifre specifice și nu le ai în documentele noastre, banner-ul trebuie să fie acolo. Dacă nu e - 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.