Contratti Dati Tra le Fasi della Pipeline: Perché gli Errori si Fermano al Confine
Come ogni fase della pipeline di Rexfin rifiuta i dati malformati passati dalla fase precedente, così che un errore venga intercettato al confine invece di arrivare fino al tuo modello.
Di The Rexfin team
La maggior parte delle pipeline fallisce silenziosamente nel mezzo. Una fase produce qualcosa di leggermente sbagliato, un campo con la forma sbagliata, un valore andato in overflow, una corrispondenza ambigua, e la fase successiva fa comunque del suo meglio con ciò che riceve, perché rifiutarsi di procedere sembra peggio che continuare con un’ipotesi. Quando qualcosa comincia a sembrare sbagliato, altre tre fasi hanno già costruito sopra quell’input difettoso, e nessuno può dire esattamente dove le cose sono andate storte. La pipeline di Rexfin funziona su un presupposto diverso: ogni passaggio di consegne tra fasi è un contratto, e alla fase ricevente è permesso, anzi ci si aspetta, che rifiuti tutto ciò che non lo rispetta.
Il bundle è il contratto, non una speranza
L’ingestion non consegna il proprio output alla fase successiva come un mucchio disordinato di numeri estratti. Assembla tutto ciò che un deposito documentale ha prodotto, il fact ledger, i frammenti citati, le pagine canoniche, il grafo delle relazioni che collega le cifre tra loro, un report su come il gate di qualità dell’estrazione ha valutato il documento, e un manifest che descrive cosa contiene il pacchetto, in un unico bundle indirizzato per contenuto. Prima che quel bundle vada da qualsiasi parte, l’ingestion lo valida rispetto a uno schema che non possiede essa stessa. Se il bundle non è conforme, l’ingestion si rifiuta di emetterlo. Non rimodella silenziosamente i dati per farli entrare, e non lascia passare un bundle “abbastanza vicino” lasciando che sia la fase successiva a risolvere il problema. Un rifiuto a questo punto significa un documento che richiede un altro sguardo, non un numero sbagliato tre fasi più in là senza modo di risalire alla causa.
Anche l’altro lato controlla
La fase che riceve il bundle non dà per scontata la conformità solo perché il mittente ha dichiarato di averla validata. Esegue il proprio gate dichiarativo di qualità dei dati sulla stessa forma di contratto al confine, prima che qualsiasi cosa nel bundle venga trattata come dato nuovo. Due controlli indipendenti su un unico passaggio di consegne, uno su ciascun lato del confine, è ciò che un contratto imposto ha l’aspetto di essere, piuttosto che un contratto semplicemente presunto: se mai un bug nel validatore dell’ingestion lasciasse passare qualcosa, il lato ricevente è la seconda linea di difesa, non una formalità.
Parte di ciò che attraversa quel confine viene rifiutata per forma, un campo numerico che in realtà non è un numero finito, o un valore andato in overflow oltre qualsiasi cosa che un documento reale potrebbe riportare, e parte viene rifiutata per ambiguità: un’ancora di citazione che potrebbe plausibilmente puntare a più di una cifra viene respinta invece di essere risolta scegliendone una a caso e sperando bene. Le strutture ricorsive che si riferiscono l’una all’altra vengono percorse fino a una profondità limitata invece di essere seguite indefinitamente, così che una struttura malformata o avversaria non possa trasformare un passaggio di validazione in un blocco.
I contratti non riguardano solo la forma
Un record può essere perfettamente ben formato e comunque non guadagnarsi la fiducia. Prima che una cifra estratta possa diventare citabile, prima che chiunque possa indicarla come un fatto, più backend di estrazione indipendenti devono concordare su cosa dica. La lettura di un singolo backend, per quanto pulita, non basta da sola; l’accordo tra più backend fa parte del contratto che una cifra deve soddisfare prima di passare da estratta a utilizzabile, lo stesso standard su cui si basa la verifica quando controlla che i totali quadrino davvero.
La stessa logica separa i numeri provvisori da quelli effettivi. Una previsione o un piano inviato in Rexfin percorre una propria corsia, con proprio storage, proprio percorso di scrittura, tenuta strutturalmente separata dagli atomi su cui si basano verifica e citazione. Qualsiasi cosa in quell’invio che tenti di dichiararsi già effettiva, già citata, o già verificata viene respinta senza appello, e il livello di garanzia associato a un piano viene attribuito dal sistema stesso invece che accettato per come lo dichiara il mittente. Una proiezione non può travestirsi da numero depositato semplicemente chiedendo di essere trattata come tale.
Perché il rifiuto batte la riparazione
Una fase che rifiuta un input malformato invece di ripararlo fallisce anche in un modo da cui ci si può riprendere, la stessa disciplina dietro il modo in cui la piattaforma gestisce affidabilità e disaster recovery: sapere esattamente cosa si è rotto, isolarlo, e lasciare che tutto il resto continui a funzionare. I contratti tra le fasi rendono questo possibile a livello di confine, non solo a livello dell’intero sistema.
A chi si rivolge
A chiunque abbia visto un report a valle rompersi e abbia passato un pomeriggio a risalire un numero sbagliato attraverso tre sistemi prima di trovare dove le cose sono andate storte. La pipeline di Rexfin è costruita in modo che un record malformato venga respinto al primo confine che attraversa, con una motivazione allegata, invece di propagarsi silenziosamente finché non emerge come una cifra sbagliata su una pagina di cui ti fidavi. Guarda come si incastrano i confini nella panoramica del pilastro, oppure prenota una demo per vedere una violazione di contratto intercettata dal vivo.
Parte di Dentro la piattaforma Rexfin: come funziona il meccanismo della fiducia