In fortgeschrittener Entwicklung · H001–H057 abgeschlossen · H058 Memory-Envelope-Vertrag abgeschlossen · M1–M5 abgenommen · Aktuell: M6 Gedächtnis-Implementierung2026

HUGO

Local-First Personal-AI- & Robotik-Runtime

Meine Rolle

Produktarchitektur · AI-Runtime · Gateway & Authentifizierung · Provider-Integration · Safety- & Authority-Grenzen

Projektübersicht

HUGO ist eine tragbare, local-first Personal-Brain-Runtime. Sie besitzt eine persistente Identität, eine Nutzerbeziehung, ein kontrolliertes Gedächtnissystem und — über die Zeit — mehrere autorisierte Capability-Provider.

Die Kernarchitekturidee ist eine persistente Intelligenz mit vielen Körpern: Der aktive Körper ist Kontext, nicht Identität. Der Wechsel von Telefon, Host, Roboter oder Dienst ändert nie, wer HUGO ist, und Körper-/Gerätekalibrierung bleibt providerspezifisch. LOOI ist Reference Body Adapter #1 — ein Körper für HUGO, nicht HUGOs Identität.

Die Entwicklung ist meilensteinbasiert und evidence-gebunden. H001–H057 sind abgeschlossen, der H058-Memory-Envelope-Vertrag ist abgeschlossen und die Meilensteine M1–M5 sind abgenommen, einschließlich Real-Device-Abnahme auf Samsung-Hardware. Aktuell arbeitet HUGO an M6, Langzeitgedächtnis: Der Common-Memory-Envelope-Domainvertrag (H058) ist als reine, nicht verdrahtete Schemaebene implementiert; Speicherung und Abruf (H059+) sind die nächste Grenze.

Reale Produkt-Screenshots

Hier werden ausschließlich reale Produkt-Screenshots ergänzt—keine Mockups oder Stockbilder.

Screenshot

Hier werden ausschließlich reale Produkt-Screenshots ergänzt—keine Mockups oder Stockbilder.

/projects/hugo/desktop-01.webp

Systemarchitektur

HUGO Core

Persistente Identität · Nutzerbeziehung · deterministische lokale Policy

→

Conversation Runtime

Streaming · Barge-in · Model Policy · Budgets · Circuit Breaker

→

Gateway & Capability-Provider

Authentifizierung · BodyAdapter · DeviceAdapter · ServiceConnector

→

Körper & Umgebungen

LOOI-Referenzkörper · autorisierte Geräte, Dienste und Umgebungen

Projektstatus

Umgesetzt

Persistente Identity/Core und die Capability-/Provider-Architektur
Deterministische Safety- und Authority-Grenzen für physische Kontrolle
Gateway/Authentifizierung und Context Handling
Streaming-Conversation-Runtime mit Barge-in
Model Policy, Budgets und Circuit-Breaker-Verhalten
H001–H057 abgeschlossen; Meilensteine M1–M5 auf einer gesperrten Evidence-Kette abgenommen
Real-Device-Abnahme auf Samsung-Hardware (LOOI-Referenzkörper)
H058 Common Memory Envelope: providerneutraler Memory-Domainvertrag

In aktiver Entwicklung

M6 Langzeitgedächtnis: H059 — verschlüsseltes lokales Memory-Repository (Ports, Storage-Entscheidung, Key-Handling)
Working-, Episodic-, Semantic-, Device/Body- und Strategy-Memory-Schichten (H060–H063)
Validierung, Abstimmung und begrenzter Abruf (H064–H065)
Der H058-Envelope ist als reiner, nicht verdrahteter Domainvertrag implementiert — noch kein Storage oder Runtime-Wiring

Geplant

Memory-Kontrolloberfläche: Inspizieren, Bestätigen, Korrigieren, Löschen und Exportieren (H067)
Multi-Provider-Orchestrierung über Körper und Dienste hinweg (M7)
Developer Mode und kontrollierte Adapter-Erweiterung (M8)
Portable Product Acceptance über Hosts und Provider hinweg (M9)

Technische Entscheidungen

Warum ist der aktive Körper nicht die Identität?

HUGO ist eine persistente Intelligenz mit einer Identität und einer Nutzerbeziehung. Telefone, Hosts, Roboter und Dienste sind Kontext: Ihr Austausch darf die Identität oder das dazugehörige Gedächtnis nicht ändern. Körper- und Gerätekalibrierung bleibt beim Provider, nicht bei HUGOs Identität.

Warum scheitern unbekannte Provider geschlossen?

Discovery gewährt keine Autorisierung. Unbekannte Provider failen für Steuerung geschlossen, und eine deterministische lokale Policy bleibt für physische Sicherheit autoritativ — kein Modell, Cloud-Dienst oder Körper kann sie überstimmen.

Warum local-first mit optionalem Cloud-AI?

Nutzerdaten bleiben local-first und portabel. Cloud-AI ist ein optionaler Capability-Provider für ausgewählte Aufgaben — nie der Besitzer von Identität oder Gedächtnis.

Warum darf die Runtime keinen eigenen Code deployen?

Die Runtime kann ihren eigenen Produktionscode nicht ändern oder deployen. Änderungen an HUGO bleiben ein expliziter, menschlich kontrollierter Engineering-Akt mit eigenen Abnahme-Gates.

Gelöste Herausforderungen

01Eine Identität über Telefone, Hosts und Körper hinweg stabil halten
02Deterministische Authority-Grenzen für physische Sicherheit durchsetzen
03Gedächtnis als Envelope modellieren, der Provenance, Privacy, Confidence, Retention, Konflikte und Scope trägt
04Echtzeit-Conversation-Verhalten — Streaming und Barge-in — auf echten Geräten

Technologien

Core Runtime

Local-First Personal Runtime
Persistente Identität & Nutzerbeziehung
Deterministische lokale Policy

Conversation

Streaming-Runtime
Barge-in-Koordination
Model Policy & Budgets
Circuit-Breaker-Verhalten

Provider

BodyAdapter — LOOI ist Reference Adapter #1
DeviceAdapter
ServiceConnector

Memory (M6)

Common-Memory-Envelope-Domainvertrag (H058)
Provenance · Privacy · Confidence · Retention · Konflikte · Scope
Verschlüsseltes lokales Repository (H059, nächste Grenze)

Was es demonstriert

HUGO demonstriert meine Fähigkeit, eine persistente Personal-AI-Runtime als kontrolliertes Produkt zu entwickeln: eine Identität, eine Nutzerbeziehung, autorisierte Capability-Provider und deterministische Safety-Grenzen — verifiziert durch einen abgenommenen, evidence-gebundenen Meilensteinprozess auf echter Hardware.

Benötigen Sie ein ähnliches System?

Ich kann eine Lösung passend zu Ihren Abläufen, Ihrem Team und Ihren Geschäftszielen konzipieren und umsetzen.

Projekt besprechen ↗

← Vorheriges Projekt

Piano Core

Nächstes Projekt →

PitlaneOne