Catalogul de produse ca sursă de adevăr pentru AI

Catalogul de produse este sursă de adevăr operațională atunci când poate spune ce produs există, ce variantă descriem, ce afirmații sunt aprobate, pentru ce piață sunt valabile și când s-au schimbat. Nu este obligatoriu o singură bază de date și nu este o promisiune că un motor AI extern îl va citi.

Un catalog bun produce aceeași identitate și aceleași fapte de bază pentru pagina de produs, datele structurate, feed, API, suport și verificarea răspunsurilor AI. Prețul și stocul pot veni din sisteme mai rapide, dar autoritatea lor este declarată. Contradicția devine incident de date, nu concurs între copii.

1. Catalogul canonic nu este un fișier cu produse

Un spreadsheet poate inventaria produse. Un PIM poate gestiona atribute. Un ERP poate deține coduri și lifecycle. Un CMS publică texte. Niciunul nu devine automat sursa unică pentru toate câmpurile.

Catalogul canonic este un contract logic: identifică autoritatea fiecărui câmp, normalizează relațiile, păstrează timpul și publică un snapshot verificat. Poate fi federat peste mai multe sisteme. „Unic” descrie verdictul pentru un câmp, o piață și un moment, nu neapărat serverul fizic.

Articolul despre Knowledge Base ca sursă de adevăr explică regula generală pentru afirmații de brand. Aici construim versiunea specializată pentru produse, variante, oferte și stări comerciale volatile.

2. Identitatea internă trebuie să rămână stabilă

Fiecare produs primește un canonical_product_id intern, unic și imuabil. Nu îl derivăm din titlul comercial, URL sau numele campaniei. Dacă produsul este redenumit ori mutat, identitatea rămâne; dacă apare o versiune comercială distinctă, politica decide dacă avem o variantă, un model nou sau o succesiune.

Google Merchant Center cere un ID stabil și avertizează că schimbarea lui tratează articolul ca produs nou, rupând continuitatea. Este o regulă a acelei platforme, dar ilustrează un principiu general: identitatea volatilă distruge istoricul și reconcilierea.

GTIN, MPN și SKU rămân identificatori externi sau specifici unui emitent. GS1 folosește GTIN pentru identificarea articolelor comerciale. Dacă produsul nu are GTIN, nu inventăm unul; catalogul intern păstrează identificatorul canonic și dovada despre identificatorii disponibili.

3. Modelăm familia, produsul, varianta, bundle-ul și oferta

• grup/familie: proprietăți comune și dimensiuni de variație;
• produs: modelul identificabil asupra căruia facem afirmații;
• variantă: configurația concretă pe culoare, mărime, capacitate ori material;
• bundle: compoziție cumpărabilă separat, cu propriile relații;
• ofertă: produs + merchant + piață + preț + disponibilitate + moment.

Google Search Central descrie ProductGroup, variesBy și hasVariant. Schema.org tratează ProductGroup ca prototip pentru variante. Catalogul intern poate folosi altă tehnologie, dar trebuie să păstreze aceeași distincție semantică.

Nu copiem prețul familiei într-o variantă și nu atribuim întregii game o compatibilitate verificată numai pentru un model. Moștenirea proprietăților are reguli explicite și excepții inspectabile.

4. Autoritatea se declară pe câmp

Domeniu	Producător autorizat	Exemple de câmpuri
Identitate	PIM/ERP/product master	ID, familie, model, variantă, GTIN/MPN
Specificații	product/engineering	dimensiuni, capacitate, compatibilitate
Preț	pricing/commerce	sumă, monedă, taxe, perioadă
Disponibilitate	OMS/WMS/commerce	stoc, preorder, backorder, locație
Politici	legal/operations	garanție, retur, restricții de piață
Prezentare	CMS/content	titlu localizat, descriere, media

„Cel mai nou câștigă” este o regulă periculoasă. Un titlu editat ieri în CMS nu poate suprascrie modelul aprobat în PIM. Un stoc actual din OMS trebuie însă să depășească o copie veche din pagina cache. Prioritatea vine din autoritate și scop, apoi din timp.

5. Specificația și oferta au viteze diferite

Greutatea, materialul și compatibilitatea se schimbă rar. Prețul, stocul și termenul de livrare se pot schimba în minute. Catalogul le separă pentru a evita republicarea întregului produs la fiecare mișcare comercială și pentru a aplica SLA-uri diferite.

Specificația Google pentru preț cere concordanță cu landing page și checkout. Disponibilitatea are stări controlate și trebuie să corespundă site-ului. Aceste cerințe arată de ce prețul include moneda și piața, iar stocul include locația, sursa și momentul.

out_of_stock nu înseamnă discontinued. Primul descrie oferta curentă; al doilea descrie lifecycle-ul produsului. Ștergerea unui produs temporar indisponibil pierde istoricul și poate rupe relațiile.

6. Fiecare valoare importantă are timp

Un câmp comercial păstrează cel puțin:

• effective_from — când începe valabilitatea de business;
• effective_to — când încetează, dacă este cunoscut;
• observed_at — când sistemul a observat sursa;
• ingested_at — când a intrat în catalog;
• published_at — când snapshotul a ajuns în canal;
• freshness_sla — cât timp poate rămâne neverificat.

RFC 3339 oferă un format interoperabil pentru timestampuri cu UTC ori offset explicit. „Actualizat azi” fără fus orar, sursă și tip de timp nu este suficient pentru reconcilierea stocului sau prețului.

7. Afirmațiile despre produs sunt atomice și dovedite

Descrierea „compact, rapid și compatibil cu sistemul X” conține mai multe afirmații. Catalogul le separă: valoare, unitate, condiție, piață, sursă, evidence pointer, proprietar, aprobare și valabilitate. Afirmațiile de marketing necuantificate primesc și ele statut, nu sunt confundate cu specificațiile tehnice.

Un câmp poate fi aprobat, în revizuire, expirat, contestat sau neaplicabil. Canalul public primește numai stările permise de contractul său. Nu propagăm o afirmație contestată în markup doar fiindcă a rămas într-o descriere veche.

Pentru verificarea outputurilor externe, articolul despre vizibilitatea produselor în răspunsurile AI separă prezența, recomandarea, acuratețea și freshness-ul. Catalogul furnizează referința datată, nu verdictul despre performanța AI.

8. Lifecycle-ul păstrează istoria

Stările minime pot fi draft, active, paused, discontinued și archived. Trecerea are motiv, autor și moment. Un model înlocuit primește superseded_by; nu este redenumit în succesor.

Paginile istorice, manualele, piesele compatibile și răspunsurile AI pot continua să menționeze produsul retras. Păstrarea identității permite clasificarea corectă: mențiune istorică validă, recomandare depășită sau confuzie între generații.

9. Arhitectura separă sursa de proiecții

În stânga sunt producătorii autorizați pe domenii. În centru, catalogul rezolvă identitatea, claims, oferta și proveniența într-un snapshot versionat. Un gate validează contractul. În dreapta, adaptoarele construiesc pagina, JSON-LD, feedul/API și Knowledge Base-ul.

Canalele nu sunt copii manuale independente. Fiecare proiecție păstrează versiunea catalogului, timpul generării, regulile adaptorului și rezultatul validării. Dacă un canal are o valoare diferită, diferența se întoarce ca incident de drift; nu suprascrie automat centrul.

10. Validarea are mai multe straturi

1. sintaxă: câmp obligatoriu, tip, enum, unitate și timestamp;
2. identitate: unicitate, ID stabil, format și emitent;
3. relații: varianta aparține grupului, componentele bundle-ului există;
4. timp: intervale valide, SLA și absența suprapunerilor imposibile;
5. cross-field: prețul are monedă, produsul retras nu este activ comercial fără excepție;
6. cross-channel: produs, variantă, preț și disponibilitate concordă la momentul comparat;
7. guvernanță: sursă, proprietar și aprobare pentru claims sensibile.

Validarea nu repară inventând. Un câmp lipsă rămâne lipsă, blochează proiecția relevantă sau intră într-o coadă cu proprietar. O valoare invalidă nu este înlocuită automat cu prima valoare găsită pe web.

11. Pagina, markup-ul și feedul sunt proiecții

Pagina vizibilă poate combina identitatea și claims stabile cu prețul din commerce. JSON-LD exprimă un subset structural. Feedul respectă taxonomia și cerințele destinației. API-ul oferă câmpuri pentru aplicații, iar Knowledge Base-ul transformă faptele în răspunsuri documentate.

Google cere ca pagina să corespundă variantei, prețului și disponibilității trimise. Coerența este verificabilă. Totuși, publicarea corectă nu garantează că un motor AI extern va prelua, cita sau recomanda produsul.

Implementarea detaliată a datelor structurate, WooCommerce și diferența feed versus crawl rămân în paginile lor canonice. Aici contează că toate aceste canale provin din aceeași versiune aprobată.

12. Reconcilierea nu este „last write wins”

Presupunem că PIM spune „P20”, CMS spune „P20 Pro”, iar feedul păstrează „P20 v2”. Sistemul nu alege automat valoarea cu timestampul cel mai nou. Verifică autoritatea pentru identitate, relația de supersesiune și dovada modificării.

Incidentul conține câmpul, valorile concurente, sistemele, momentul, impactul canalelor și proprietarul. După decizie, o nouă versiune canonică generează proiecții. Istoricul arată cine a schimbat, de ce și ce destinații au fost regenerate.

GS1 EPCIS păstrează evenimente cu context despre ce, când și unde și tratează corecțiile ca evenimente explicite. Nu cerem implementarea EPCIS pentru orice catalog; preluăm disciplina de a nu șterge tacit istoria.

13. Limbile schimbă prezentarea, nu identitatea

Produsul canonic rămâne același între română, engleză și germană. Titlul, descrierea și anumite claims pot fi localizate; unitățile, reglementările, disponibilitatea și oferta pot varia pe piață. Fiecare valoare are locale și market_scope acolo unde este necesar.

Traducerea nu rescrie identificatorul și nu transformă o afirmație neaprobată într-una validă. Termenii tehnici pot folosi un glosar, iar diferențele juridice sau comerciale cer aprobare locală, nu traducere automată.

14. Outputul AI este observație, nu sursă

Dacă un răspuns AI spune că P20 are atributul X, îl comparăm cu catalogul datat și cu dovada lui. Dacă afirmația pare mai nouă decât catalogul, deschidem investigația spre sursa primară. Nu copiem outputul direct în master data.

Același principiu se aplică review-urilor, retailerilor și publicațiilor. Ele pot furniza dovezi despre experiență, preț sau ofertă, dar nu primesc automat autoritate asupra identității producătorului ori specificației aprobate.

La analiza competitivă, product share of voice folosește catalogul pentru entity resolution. Clasamentul observat nu schimbă catalogul; doar atașează evenimente de măsurare entităților canonice.

15. Înregistrarea minimă auditabilă

• canonical_product_id și versiunea;
• brand, familie, model, variantă și dimensiuni de variație;
• GTIN/MPN/SKU corecte, emitent și stare de verificare;
• lifecycle, predecessor și successor;
• nume canonic și localizări aprobate;
• specificații atomice cu valoare, unitate, condiție și dovadă;
• compatibilități, accesorii, bundle-uri și excluderi;
• oferte cu merchant, piață, monedă, preț și disponibilitate;
• effective_from/to, observed_at și freshness SLA;
• proprietar, aprobator și evidence pointer;
• URL-uri de destinație și versiunea fiecărei proiecții;
• conflicte, excepții și istoric de schimbare.

16. Implementarea începe mic și demonstrabil

1. alegem o familie de produse cu probleme reale de inconsistență;
2. definim ierarhia și ID-urile fără să le schimbăm în canalele existente;
3. scriem matricea de autoritate pentru 15–30 de câmpuri critice;
4. importăm valorile cu sursă și marcăm conflictele, nu le ascundem;
5. stabilim lifecycle, timp și SLA pe categorii de câmpuri;
6. generăm un snapshot și o singură proiecție controlată;
7. comparăm proiecția cu pagina și checkoutul;
8. adăugăm feed, markup, API și Knowledge Base progresiv;
9. capturăm driftul și măsurăm timpul de remediere;
10. extindem numai după ce recalcularea este reproductibilă.

Verdict

Catalogul de produse devine sursă de adevăr când identitatea este stabilă, fiecare câmp are autoritate, fiecare valoare are timp și dovadă, iar canalele sunt proiecții versionate. Nu trebuie să fie o singură aplicație; trebuie să producă un singur verdict auditabil pentru domeniul declarat.

Această disciplină nu controlează ce spune un motor AI extern. Face însă trei lucruri esențiale: reduce contradicțiile publice, permite verificarea afirmațiilor și arată exact ce trebuie corectat când pagina, feedul, checkoutul ori răspunsul observat nu concordă.

Surse

• GS1 — Standards repository
• GS1 — General Specifications
• GS1 — EPCIS 2.0.1
• Google Merchant Center — Product ID
• Google Search Central — Product variants
• Google Merchant Center — Price
• Google Merchant Center — Availability
• Google Merchant Center — Landing page requirements
• W3C — PROV-O
• IETF — RFC 3339 timestamps

Arhitectura este un model editorial și operațional, nu descrierea unei funcții AYSA lansate și nu o garanție de preluare, citare sau recomandare într-un sistem AI extern.