Architettura AIKA

AIKA rende osservabile il ciclo della continuità.

Nel prototipo, Coordinator apre il run e governa il percorso del prompt attraverso gli stage. Composer interviene dopo una prima scrematura e attiva il processo interno di estrazione: un algoritmo che riconosce, nella geometria complessiva del testo, la struttura dei microsensi, li isola e li estrae.

I microsensi estratti rientrano nel ciclo del run come attrattori: guidano Memory Search nella ricerca di costellazioni semanticamente e geometricamente compatibili, aggiornano la memoria e diventano tracce di sé riattivabili da prompt futuri.

Il prototipo rende visibili i processi reali che il prodotto svolgerà in background.

Nel prototipo, gli stage sono l’interfaccia attraverso cui il ciclo del run diventa osservabile: operano su prompt reali, producono esiti reali del run e mostrano come AIKA estrae microsensi, recupera costellazioni compatibili e aggiorna la memoria.

Nel prodotto finale, questi processi lavoreranno sotto la superficie come layer operativo tra utente e LLM: AIKA costruirà il contesto utile prima dell’invio del prompt, mentre l’utente vedrà solo la risposta generata dal modello linguistico.

runtime owner

Coordinator

Possiede il lifecycle del run: apre il ciclo, governa gli stage osservabili e chiude il flow in modo esplicito.

Coordinator è l’owner del lifecycle del run assistant nel prototipo AIKA. Riceve il prompt, lo sanifica, usa il canale della request e apre il ciclo operativo solo quando l’input è valido.
Il modello è stage-oriented: Composer, Memory Search e Memory CRUD sono le fasi della sequenza operativa del run, i momenti in cui il dato cambia stato e produce un esito leggibile. Nel prototipo, gli stage seguono lo stesso schema interno: il modulo di dominio produce l’esito, Streamer lo trasforma in blocco osservabile e Receiver lo consegna al canale del run.
Ogni stage restituisce un esito osservabile: microsensi estratti o assenti, costellazioni trovate, scartate o non disponibili, memoria aggiornata, rinnovata o non modificata. L’osservabilità non coincide quindi solo con il successo, ma con la capacità del prototipo di dichiarare cosa è accaduto.
Il sistema può misurare i tempi del run e degli stage in millisecondi. Nel prototipo, il timing resta infrastruttura di verifica e report: rende il ciclo osservabile e controllabile, senza diventare logica cognitiva o decisione di routing. La sua presenza prepara una possibile evoluzione futura: usare i tempi del run come segnali operativi per rendere il sistema più adattivo.
Coordinator non sostituisce i moduli nel loro lavoro interno. Governa il lifecycle complessivo: decide se proseguire allo stage successivo, se interrompere il run e se uno stage deve diventare osservabile.
Se uno stage fallisce, Coordinator interrompe la sequenza: gli stage successivi non partono, ma i blocchi già emessi restano validi come stato osservato del run.
Il run non produce un payload finale unico verso il frontend. Gli esiti del run passano dal canale come blocchi progressivi, poi Coordinator chiude il ciclo con complete o fail e torna idle in attesa del prompt successivo.

01 Microsensi

Composer

Gestisce la pipeline di estrazione dei microsensi: riceve, classifica e instrada il prompt ai moduli interni, poi restituisce a Coordinator il ContentPackage.

Dentro Composer, Diagnostic è il primo filtro deterministico: legge il prompt, ne riconosce la natura e lo classifica in un ramo operativo — alive, killer, dead o code. Da questa classificazione dipende se il percorso si ferma presto o prosegue verso l’estrazione dei microsensi.
Quando il prompt viene classificato come alive, la pipeline di Composer prosegue con Distiller: il testo viene ripulito dal rumore, normalizzato in una forma stabile e preparato per i passaggi successivi, senza usare modelli esterni e senza modificarne il significato.
Un secondo passaggio di pulizia del testo avviene in OrtoCleaner: il prompt viene stabilizzato nella sua forma linguistica, riducendo irregolarità, forme colloquiali e rumore residuo senza alterarne, anche qui, il significato.
Quando il prompt arriva a questo punto della pipeline, è pronto per entrare in MarkerNet, il motore geometrico-semantico di AIKA. Qui smette di essere testo e diventa materia da trasformare.
MarkerNet non è un filtro, né un sistema che cerca parole chiave, ma una net interna di letture progressive: il prompt non viene letto solo come contenuto, ma anche come forma, ovvero come sequenza di segnali strutturali e geometrici.
La forma serve a dare al contenuto una seconda lettura: MarkerNet è in grado di coniugare semantica di base con struttura e geometria, riuscendo a distinguere nel prompt le porzioni informative capaci di reggere come microsenso dalle parti che non producono continuità riutilizzabile, ovvero rumore.
Infine, i candidati estratti dal prompt non vengono ancora assunti come microsensi finali: prima devono attraversare un processo di validazione gestito da Validator, che determina quali candidati possono rientrare nel ContentPackage.

02 Costellazioni

Memory Search

Riattiva costellazioni compatibili dalla memoria a partire dai microsensi estratti dal prompt.

In Memory Search, ogni microsenso estratto dal prompt diventa un attrattore quando può attivare una costellazione di microsensi già presenti in memoria, per compatibilità semantica, strutturale e geometrica.
La memoria di AIKA non è un archivio lineare, né un repository di riassunti o testi da recuperare, e non è neppure un archivio cronologico: è uno spazio popolato da microsensi dormienti e riattivabili, che non dipendono dal momento in cui sono stati salvati ma dalla possibilità di tornare compatibili con il presente del prompt.
Una costellazione non è un blocco di testo o un vecchio paragrafo ripescato dal passato. È un insieme temporaneo di microsensi residenti nello spazio della memoria, salvati in momenti e contesti differenti, che si connettono attorno all’attrattore perché, insieme, rispondono al presente dell’utente.
La costellazione non porta con sé solo semantica, ma anche individualità linguistica: lessico, ricorrenze e un modo unico di stare nel discorso. Se il microsenso è la traccia minima di sé, la costellazione ne è l’impronta.
Ogni attrattore attiva la propria costellazione, che viene consegnata insieme al prompt all’LLM esterno: non come regola rigida o risposta da ripetere, ma come mappa di orientamento, un contesto vivo che aiuta il modello a calibrare reasoning e scelte lessicali dentro il campo di senso riattivato dall’utente.

03 Persistenza

Memory CRUD

Rende sostenibile la persistenza dei microsensi, evitando che la memoria diventi accumulo indiscriminato.

Memory CRUD è l’ultimo modulo del ciclo: riceve da Coordinator la lista dei microsensi estratti da Composer, ma interviene solo dopo la fase di ricerca delle costellazioni. Questo preserva la memoria dall’autoreferenza: i microsensi appena emersi non vengono usati per costruire la costellazione dello stesso run, perché in quello spazio non risiedono ancora. Solo dopo possono persistere in memoria.
L’adozione del microsenso come mattoncino della continuità conversazionale rende sostenibile la persistenza della memoria: Memory CRUD evita che la memoria si gonfi e impedisce ai microsensi già residenti di perdere la propria storia.
Se riconosce che un microsenso estratto durante il run è già residente in memoria, non crea una nuova traccia: conserva quella esistente e la rinnova. Se invece apporta nuovo contenuto informativo alla memoria, lo salva.
Raggiunta una certa quantità di microsensi residenti in memoria, le costellazioni attivate dagli attrattori potrebbero assumere una densità tale da non restituire solo continuità conversazionale personale, ma anche continuità culturale situata.

osservabilità

Streamer Receiver

Consentono l’osservabilità del run per l’utente, trasformando gli esiti dei moduli di dominio in blocchi progressivi per il frontend.

Dopo i moduli di dominio — Composer, Memory Search e Memory CRUD — il focus passa al layer che rende osservabili i loro esiti nel prototipo.
Nel prototipo, ogni stage ha una sequenza interna riconoscibile: il modulo di dominio produce l’esito, Streamer lo trasforma in blocco osservabile e Receiver tenta la consegna al canale del run verso il frontend.
Entrando più nel dettaglio, Streamer riceve gli esiti prodotti dai moduli di dominio e li trasforma in blocchi osservabili, coerenti con lo stage del run da cui provengono, senza modificarne il contenuto.
Ogni blocco organizza il contenuto dello stage in una forma osservabile: rende leggibile l’esito per l’utente e fornisce al frontend la struttura necessaria per visualizzarlo a schermo.
Receiver completa la sequenza osservabile dello stage: prende in carico il blocco emesso da Streamer e ne cura la consegna al canale del run verso il frontend, senza modificarne contenuto o forma e restituendo solo un esito tecnico minimale del proprio lavoro.