Sviluppo avanzato · H001–H057 completate · H058 contratto Memory Envelope completato · M1–M5 accettate · Attuale: M6 implementazione della memoria2026

HUGO

Runtime AI personale e robotica local-first

Il mio ruolo

Architettura del prodotto · Runtime AI · Gateway e autenticazione · Integrazione provider · Confini di safety e authority

Panoramica

HUGO è un runtime personale local-first e portatile. Possiede un’identità persistente, una relazione con l’utente, un sistema di memoria governato e — nel tempo — più provider di capacità autorizzati.

L’idea architetturale centrale è un’intelligenza persistente con molti corpi: il corpo attivo è contesto, non identità. Cambiare telefono, host, robot o servizio non cambia mai chi è HUGO, e la calibrazione di corpi/dispositivi resta specifica del provider. LOOI è il Reference Body Adapter #1 — un corpo per HUGO, non l’identità di HUGO.

Lo sviluppo è guidato da milestone e vincolato a evidenze. H001–H057 sono completate, il contratto H058 Memory Envelope è completato e le milestone M1–M5 sono accettate, inclusa l’accettazione su dispositivo reale Samsung. Il lavoro attuale è M6, memoria a lungo termine: il contratto di dominio Common Memory Envelope (H058) è implementato come puro schema non cablato; archiviazione e recupero della memoria (H059+) sono il confine successivo.

Screenshot reali del prodotto

Qui verranno inseriti esclusivamente screenshot reali del prodotto, senza mockup o immagini stock.

Screenshot

Qui verranno inseriti esclusivamente screenshot reali del prodotto, senza mockup o immagini stock.

/projects/hugo/desktop-01.webp

Architettura

HUGO Core

Identità persistente · relazione con l’utente · policy locale deterministica

→

Runtime di conversazione

Streaming · Barge-in · Model policy · Budget · Circuit breaker

→

Gateway & provider di capacità

Autenticazione · BodyAdapter · DeviceAdapter · ServiceConnector

→

Corpi & ambienti

Corpo di riferimento LOOI · dispositivi, servizi e ambienti autorizzati

Stato del progetto

Realizzato

Identity/core persistente e architettura dei provider di capacità
Confini deterministici di safety e authority per il controllo fisico
Gateway/authenticazione e gestione del contesto
Runtime di conversazione con streaming e barge-in
Model policy, budget e comportamento circuit-breaker
H001–H057 completate; milestone M1–M5 accettate su una catena di evidenze bloccata
Accettazione su dispositivo reale Samsung (corpo di riferimento LOOI)
H058 Common Memory Envelope: contratto di dominio di memoria neutrale rispetto ai provider

In sviluppo attivo

M6 memoria a lungo termine: H059 — repository locale cifrata della memoria (porte, decisione di storage, gestione delle chiavi)
Strati working, episodic, semantic, device/body e strategy memory (H060–H063)
Validazione, riconciliazione e recupero delimitato (H064–H065)
L’envelope H058 è implementato come contratto di dominio puro e non cablato — ancora senza storage o collegamento al runtime

Pianificato

Superficie di controllo della memoria: ispezionare, confermare, correggere, eliminare ed esportare (H067)
Orchestrazione multi-provider attraverso corpi e servizi (M7)
Developer mode ed espansione controllata degli adapter (M8)
Accettazione di prodotto portatile attraverso host e provider (M9)

Decisioni tecniche

Perché il corpo attivo non è l’identità?

HUGO è un’intelligenza persistente con un’identità e una relazione con l’utente. Telefoni, host, robot e servizi sono contesto: sostituirli non deve cambiare l’identità né la memoria che le appartiene. La calibrazione di corpi e dispositivi resta al provider, non all’identità di HUGO.

Perché i provider sconosciuti falliscono in modo chiuso?

La scoperta non concede autorizzazione. I provider sconosciuti fail closed per il controllo, e una policy locale deterministica resta autoritativa per la sicurezza fisica — nessun modello, servizio cloud o corpo può prevalere su di essa.

Perché local-first con AI cloud opzionale?

I dati dell’utente restano local-first e portatili. L’AI cloud è un provider di capacità opzionale per compiti selezionati — mai il proprietario di identità o memoria.

Perché il runtime non può deployare il proprio codice?

Il runtime non può modificare o deployare il proprio codice di produzione. Le modifiche a HUGO restano un atto di ingegneria esplicito, controllato dall’uomo, con i propri gate di accettazione.

Problemi risolti

01Mantenere un’identità stabile attraverso telefoni, host e corpi
02Far rispettare confini deterministici di authority per la sicurezza fisica
03Modellare la memoria come envelope che trasporta provenance, privacy, confidence, retention, conflitti e scope
04Comportamento di conversazione in tempo reale — streaming e barge-in — su dispositivi reali

Tecnologie

Runtime core

Runtime personale local-first
Identità persistente & relazione con l’utente
Policy locale deterministica

Conversazione

Runtime con streaming
Coordinamento barge-in
Model policy & budget
Comportamento circuit-breaker

Provider

BodyAdapter — LOOI è Reference Adapter #1
DeviceAdapter
ServiceConnector

Memoria (M6)

Contratto di dominio Common Memory Envelope (H058)
Provenance · privacy · confidence · retention · conflitti · scope
Repository locale cifrata (H059, confine successivo)

Cosa dimostra

HUGO dimostra la mia capacità di progettare un runtime AI personale persistente come prodotto governato: un’identità, una relazione con l’utente, provider di capacità autorizzati e confini deterministici di safety — verificato attraverso un processo di milestone accettato e vincolato a evidenze su hardware reale.

Ti serve un sistema simile?

Posso progettare e sviluppare una soluzione adatta al tuo flusso di lavoro, al team e agli obiettivi aziendali.

Parliamo del progetto ↗

← Progetto precedente

Piano Core

Progetto successivo →

PitlaneOne