Data operations in Accordo: 9 job, 6 a metà, 3 assenti

In breve. Le operazioni dati di Accordo stanno a metà strada, ed è il catalogo pubblico a dirlo, non io: 9 job, 6 parzialmente supportati e 3 non supportati. Import con ricevute ma senza CSV, duplicati decisi per regola ma solo in import, merge logico ma non fisico, export con bound ma non sui record commerciali. La mappa del cluster è nell'hub data governance; qui il giro dei nove job, con i confini in privacy e segregation.

Entrare: import, duplicati, merge

L'import è bounded (job JTBD-DO-01) e non afferma il falso mai: mapping con impronta, anteprima che provabilmente non scrive niente, ricevuta per riga con esito e codice motivo, conteggi che quadrano sempre — accettate più rifiutate più saltate uguale righe — e chiave di idempotenza da sistema sorgente, impronta del mapping e digest ordinati, mai orologio o caso. Il rovescio, scritto nella stessa riga: niente CSV — array JSON bounded da 500 righe, niente upload, niente inferenza di delimitatori, niente mapping a UI, niente streaming né resume. Prova: tests/customer-data-foundation.test.js, scenario examples/scenarios/customer-identity-governance.scenario.json.

I duplicati si decidono con tre regole esatte in precedenza fissa — identità esterna, email di contatto, nome azienda più dominio — sotto policy versionata con impronta. L'ambiguità non si rompe: diventa un candidato con regola, evidence e impronta, e la riga resta irrisolta per una persona. Niente fuzzy, niente fonetico, niente punteggi, e il controllo gira solo in import: inserire a mano non rileva niente.

Il merge è logico e umano: una persona — mai un agente, mai senza motivo — registra che due record sono un cliente solo, e dopo entrambi i record esistono identici, entrambi risolvono, entrambi leggono un profilo consolidato. Niente merge fisico: niente cancellazioni, niente re-pointing, niente sopravvivenza di campo. Chi vuole due righe diventate una non lo ottiene qui.

Uscire e rileggere: export, bulk, timeline

L'export copre otto insiemi gestiti — log degli import con ricevute, identità, candidati, collegamenti, finding, run bulk con ricevute — conta prima con lettura completa e sopra le 10.000 righe rifiuta con EXPORT_WOULD_TRUNCATE invece di troncare. Ma i record commerciali non escono da nessun endpoint, i filtri sono solo exact-match, niente CSV né scheduling. Prova: tests/customer-data-operations-v2.test.js.

Il bulk (job JTBD-DO-05) applica una di tre decisioni umane — collegare, archiviare o governare — fino a 500 record in una chiamata, una transazione, una ricevuta per record, con idempotenza da payload, resume e replay. Niente bulk sui campi, sugli stage o sulle cancellazioni, e ogni decisione resta a controllo umano.

La timeline (job JTBD-DO-08) è append-only per soggetto, vocabolario chiuso di quattro voci, dal passato al presente nell'Admin — ma copre solo ciò che Work ha registrato: niente email, chiamate, campagne né audit. Accanto, un profilo consolidato in sola lettura per cliente, dove un package non composto legge non disponibile con motivo invece di zero. Prove: tests/work-operations-e2e.test.js, tests/admin-work.test.js.

Fatti e limiti, separati

Fatti: 9 job data operations, 6 parzialmente supportati e 3 non supportati; import bounded da 500 righe con ricevute ed esito più motivo; tre regole esatte di matching con candidato irrisolto per l'ambiguità; merge logico umano con motivo; export su otto insiemi con bound di 10.000 righe; bulk di tre decisioni fino a 500 record; timeline append-only più profilo consolidato in sola lettura.

Limiti: niente viste salvate, niente ricerca globale — solo lookup esatti per modulo, nessun indice — niente note né allegati; niente CSV in import né in export; niente merge fisico; la timeline non è unificata. Mezzo supporto non è quasi pronto: è la lista scritta di cosa manca, riga per riga.

Domande frequenti

Perché "parzialmente supportato" invece di un voto?

Perché il catalogo conta solo ciò che un test prova end-to-end: il resto si nomina invece di implicarlo. La riga resta parziale finché un test non la chiude.

L'import senza CSV serve a qualcosa?

Sì, a separare il contratto dal formato: ricevute, riconciliazione e idempotenza sono provati sul JSON bounded; il CSV è trasporto, e manca tutto — upload, inferenza, mapping a UI, resume.

Quando export e bulk saranno completi?

Quando il catalogo lo dirà con un test: oggi i record commerciali non escono e non si aggiornano in massa. Lo stato si legge nella pagina dei job, non si indovina dal codice.