VECTOR OS · Operating model

Una logistica complessa, organizzata come un solo sistema.

VECTOR OS è il modello applicativo che mantiene allineati esperienza cliente, connettori, decisioni, dati e prove tecniche. Non è un sistema operativo per computer: è la struttura con cui una richiesta attraversa la piattaforma senza confondere ciò che una persona vede con ciò che un servizio è autorizzato a fare.

Ogni componente ha un incarico limitato e contratti espliciti con gli altri livelli. Così un nuovo carrier, un'automazione o un modello AI possono essere introdotti senza ottenere automaticamente accesso a pagamenti, identità o dati riservati. La superficie pubblica mostra finalità ed esempi; controlli, credenziali e dettagli operativi restano protetti.

Aggiornato il · 23:44 CEST 9 min di lettura

Sette livelli, una sola direzione

Il modello procede dall'infrastruttura fino alle applicazioni. State & Data conserva stato e riferimenti; Trust & Authorization verifica identità e prove; Domain & Capability applica regole logistiche; Runtime coordina comandi e policy; Edge & Integration normalizza i collegamenti esterni; Experience & Applications presenta funzioni comprensibili alle persone.

Pulse osserva affidabilità e salute del sistema, mentre Forge mantiene contratti e strumenti di sviluppo. Sono piani trasversali: migliorano tutti i livelli senza diventare scorciatoie per aggirare permessi o responsabilità.

  • Level 7 · Experience & Applications
  • Level 6 · Edge & Integration
  • Level 5 · Vector Runtime
  • Level 4 · Domain & Capability
  • Level 3 · Trust & Authorization
  • Level 2 · State & Data
  • Level 1 · Infrastructure

Experience & Applications

È il livello che trasforma capacità tecniche in esperienze leggibili per clienti, operatori e partner: preparare una spedizione, consultare uno stato o lavorare in un'area specializzata. Presenta il passo corretto e il contesto necessario, ma non decide autonomamente permessi, prezzi o validità di una prova.

Esempio: due utenti possono aprire la stessa applicazione e vedere strumenti diversi perché ruolo e contesto vengono verificati prima di comporre la schermata. Le destinazioni operative restano disponibili soltanto dopo autenticazione e controllo degli accessi.

Edge & Integration

È il confine che uniforma API, webhook e connettori verso carrier, pagamenti e sistemi aziendali. Traduce formati, capacità e codici d'errore differenti in contratti interni coerenti, senza fingere che provider diversi offrano le stesse funzioni.

Esempio: ritiro a domicilio, consegna in filiale e servizi accessori vengono mostrati soltanto quando il connettore e il prodotto selezionato li supportano. Un errore esterno resta attribuibile alla sua origine e non viene trasformato in un successo generico.

Vector Runtime

Coordina comandi, policy, approvazioni, idempotenza e recupero delle operazioni. Mantiene una sequenza controllata tra intenzione dell'utente ed esecuzione, impedendo che un retry tecnico diventi un doppio pagamento o una seconda spedizione.

Esempio: se il pagamento è riuscito ma la label tarda, il Runtime conserva lo stato economico e riprende il fulfillment con lo stesso riferimento. Non chiede alla persona di pagare ancora e non crea una seconda spedizione alla cieca. La control room richiede un account autorizzato.

Vector Ship

Rappresenta la spedizione e il suo ciclo di vita: preparazione, offerta, conferma, affidamento, transito, eccezioni e chiusura. Le transizioni sono esplicite, così interfaccia, documenti e tracking descrivono lo stesso record operativo.

Esempio: una label creata non equivale a un pacco affidato. Vector Ship distingue creazione, primo scan, transito e consegna, evitando contatori o notifiche premature. Il flusso reale richiede autenticazione prima del calcolo e dell'acquisto.

Vector Identity

Collega identità, ruoli e permessi alle azioni tecniche. Distingue chi richiede un'operazione, chi può approvarla e quale componente può eseguirla, mantenendo revoca e responsabilità separate dai dati logistici.

Esempio: la persona che prepara un ordine può non essere quella che lo approva; un servizio può eseguire il comando senza poter leggere l'intero profilo. Ogni utente raggiunge soltanto dati e impostazioni assegnati al proprio contesto.

Vector Flow

Trasforma eventi verificati in attività, proposte e controlli ripetibili. Le automazioni sensibili restano approval-first: il motore prepara il passo successivo, ma non sostituisce una decisione umana quando sono coinvolti costi, accessi o conseguenze esterne.

Esempio: un'eccezione può generare una proposta di recupero e una richiesta di conferma, non un'azione irreversibile. La disponibilità delle automazioni dipende dal ruolo operativo e dalla policy applicata.

Vector AI Fabric

È il livello di coordinamento per modelli e assistenti: classifica dati, sceglie un profilo consentito, applica budget e mantiene un arresto immediato. Un modello può proporre o sintetizzare, ma non ottiene automaticamente autorità su infrastruttura, pagamenti o spedizioni.

Esempio: un modello può riassumere un incidente o classificare una richiesta, mentre l'esecuzione rimane a un componente autorizzato e auditabile. Le capacità visibili dipendono da ruolo, policy, provenienza del dato e stato del servizio.

Vector Vault

Definisce il confine dei dati sensibili e dei documenti. Le componenti ricevono riferimenti minimizzati invece di propagare contenuti riservati; classificazione, conservazione e accesso restano governati separatamente dall'esecuzione logistica.

Esempio: un componente può ricevere il riferimento a un documento senza ottenere il documento stesso. I dati protetti, le chiavi e le regole di accesso non sono esposti dalla superficie pubblica.

Vector Chain

È il trust layer dedicato a ricevute tecniche append-only e verificabili. Può attestare ordine e integrità di eventi selezionati senza sostituire checkout, database o API dei carrier e senza contenere i normali dati personali della spedizione.

Esempio: una transizione logistica produce un riferimento opaco e un digest confrontabile; nome, indirizzo, documento e prezzo rimangono off-chain. La sua evoluzione segue gate separati, misurabili e pubblicati con il loro stato reale.

Vector Verify e Vector Scan

Verify controlla firme, integrità e corrispondenza delle prove. Scan presenta soltanto la proiezione consultabile per il soggetto autorizzato. Sono componenti distinti dalla Chain: la Chain conserva ricevute tecniche, Verify le valida e Scan le rende leggibili senza trasformare il registro nel database operativo.

Esempio: Verify può stabilire se una ricevuta corrisponde alla sorgente autorizzata; Scan può presentare l'esito come stato comprensibile senza esporre il materiale usato per verificarlo. La consultazione completa richiede una sessione e permessi coerenti.

Vector Pulse e Vector Forge

Pulse raccoglie segnali utili a salute, affidabilità e costi. Forge mantiene contratti, SDK e strumenti con cui le componenti vengono costruite e verificate. Entrambi supportano l'OS senza assumere autorità sullo stato logistico.

Esempio: Pulse segnala che una dipendenza è lenta, mentre Forge verifica che il relativo connettore rispetti ancora il contratto atteso. Metriche dettagliate e strumenti interni sono disponibili soltanto agli account abilitati.