La gestione del servizio si è basata molto, come già accennato,
sulla nozione di ``gruppo di lavoro'', realizzato attraverso delle
mailing list di comunicazione molti-a-molti e sui precisi
percorsi per la validazione di quelle informazioni che non erano state
organizzate in unità autonome. È inoltre da sottolineare come
questi gruppi di lavoro fossero estremamente sparsi
geograficamente,
e
che quindi i meccanismi di comunicazione di Rete si sono rivelati come
una delle migliori soluzioni possibili per ogni tipo di
collaborazione.
Nella definizione del modello abbiamo evidenziato due tipi di comunicazione: quella che sale i livelli dell'``albero di validazione'' fino a trovare il punto finale, e quella utilizzata per comunicare cambiamenti avvenuti in un'unità informativa che potevano ripercuotersi su altre unità. Nel primo caso (che abbiamo visto essere solamente per poche e selezionate informazioni critiche) si sono utilizzati normali meccanismi di comunicazione Internet, in particolare FTP per il trasferimento dei file e posta elettronica per l'attivazione e conferma della validazione; gli indirizzi da utilizzare per questi meccanismi erano stati diffusi attraverso le liste di comunicazione generale e facevano parte a tutti gli effetti del modello architetturale scelto.
Per le comunicazioni di aggiornamento si provvedeva invece ad una comunicazione sulla lista globale (praticamente in broadcast), contando sul numero ridotto, grazie a come era stata progettata l'architettura, di queste necessità e sulla probabilità elevata che una modifica in questo senso interessasse la maggior parte delle unità formate da informazioni raccolte: ipotesi che si è rivelata, nella pratica, fondata e adatta al tipo di lavoro.