REDION / Applicazioni

Tutto, a un clic di distanza.

Scopri ogni piattaforma sul suo sito. L’accesso all’applicazione si trova lì.

Applicazioni8

Applicazioni private5

I siti informativi sono pubblici. Solo l’accesso alle app richiede la rete privata o un account approvato.

Siti web5

Sviluppo avanzato · H001–H057 completate · M1–M5 accettate · strati di memoria M6 H058–H066 completati · Attuale: H067 controllo della memoria e accettazione M62026

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

hugo
HUGO: HUGO su Android: cattura reale dall’emulatore, corpo simulato
Video5 Screenshot

01

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: H058–H066 sono completate — Common Memory Envelope, una repository locale cifrata, memoria working, episodic, semantic, device/body e strategy, validazione e riconciliazione, recupero delimitato e riepiloghi con provenance — come strati puri non ancora cablati nel runtime. La superficie di controllo della memoria e l’accettazione M6 (H067) sono il confine successivo.

▶

Tour del prodotto

02

Screenshot reali del prodotto

Viste del prodotto reale, senza mockup o immagini stock.

HUGO su Android: cattura reale dall’emulatore, corpo simulato
Una proposta in attesa non ha autorità di esecuzione
Conferma esplicita una tantum
Velocità eccessiva respinta dal codice deterministico
Autovalidazione del modello respinta

03

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

04

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
  • H059–H066: repository locale cifrata della memoria (AES-256-GCM, Android Keystore), memoria working, episodic, semantic, device/body e strategy, validazione e riconciliazione senza sovrascritture silenziose, recupero delimitato e riepiloghi con provenance che propagano le cancellazioni — 1141 test JVM superati

In sviluppo attivo

  • M6 memoria a lungo termine: H067 — superficie di controllo della memoria (ispezionare, confermare, correggere, eliminare, esportare) e accettazione M6
  • Gli strati di memoria H058–H066 sono puri e non ancora cablati nel runtime

Pianificato

  • 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)

05

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.

06

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

07

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)

  • Common Memory Envelope (H058) · repository locale cifrata (H059)
  • Memoria working · episodic · semantic · device/body · strategy (H060–H063)
  • Validazione · recupero delimitato · riepiloghi con provenance (H064–H066)

08

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 ↗