„De două ori am fost întrebat: «Vă rog, domnule Babbage, dacă introduceți în mașină cifre greșite, vor ieși răspunsurile corecte?» … Nu sunt în stare să pricep ce fel de confuzie a ideilor ar putea provoca o asemenea întrebare.”Charles Babbage · Passages from the Life of a Philosopher · 1864 · Passages from the Life of a Philosopher (1864), cap. V — Difference Engine No. 1
Fiecare cifră dintr-un raport trebuie să poată spune din ce rânduri și din ce fișier a venit.
Întrebarea care l-a scos din sărite pe Babbage e pusă și azi, doar că altfel: „modelul e bun, deci cifrele sunt bune?”. Nu. Un depozit nu repară ce primește; cel mult face vizibil de unde a venit. Asta e proveniența (lineage): pentru fiecare cifră dintr-un raport, drumul înapoi prin transformări până la rândurile și fișierul sursă, la nivel de coloană, dedus din SQL-ul care le-a produs. Pe fiecare rând, metadate mici: sistemul sursă, identificatorul încărcării, momentul extragerii. La ce folosește: analiza de impact (dacă sursa X se strică, ce rapoarte suferă?), depanarea (cifra asta ciudată — din ce rânduri? din ce fișier? din ce zi?), conformitatea (pe unde circulă datele personale, lucru pe care GDPR îl cere explicit) și reproductibilitatea (același cod, aceeași versiune de date, același rezultat). Cazul tipic: o coloană de sumă trece în amonte din lei în euro fără anunț; totalurile „arată plauzibil” două săptămâni. Nicio validare de tip nu prinde asta. Singura apărare e să poți urmări fiecare cifră înapoi și să vezi ziua în care distribuția s-a mutat.
De ce contează Cifra greșită care „arată bine” e cea mai scumpă din depozit. Fără proveniență, o cauți săptămâni; cu ea, o găsești într-o interogare.