Foundation · Tech NavUp v0.3 · offen

Foundation Tech — Einladung ans Tech-Milieu

Eine kurze, ehrliche Bestandsaufnahme von Foundation: was ist, wo wir stehen, was Pain und Pearl ist, wo wir Brücken suchen. Geschrieben für Menschen mit Tech-Hintergrund — kein Verkaufstext.

Die Reise dauert 10-12 Minuten. Du kannst jederzeit aussteigen oder zur Signatur springen. Wer das hier weiterleitet an Menschen, bei denen es resonieren könnte, tut Foundation einen Dienst.

Eingang
Stand
Pains/Pearls
Brücken
Signatur

Eingang — kurz ankommen

Bevor wir loslegen, eine sanfte Verortung. Submit kommt erst am Ende.
Nur wenn du Antwort möchtest. Sonst leer lassen.
Tagesform ehrlich — beeinflusst, wie du das hier liest.

Wo Foundation technisch steht

Eine kurze, ehrliche Bestandsaufnahme. Was läuft, was ist Roadmap, was sind die offenen Punkte. Reine Information — keine Frage an dich an dieser Stelle.
∙ ∙ ∙

Was heute läuft

Stack

NavUps in HTML + Formspree

NavUps laufen als statische HTML-Seiten auf eigener Infrastruktur (navup.dltsecure.net). Submissions werden strukturiert gespeichert — inkl. Verhaltensmetadaten — und im Team-Dashboard auswertbar.

Stack

Foundation TLS — Filesystem-basiertes Wissens-System

Ein Markdown-basiertes Multi-Ebenen-Wissens-System (Ebene 0-5: Verfassung → Mechanik → Module → Interface → Instanz) auf lokalem Filesystem, gespiegelt via OneDrive. ~400 Dateien, lebende Dokumentation. Editor-Zugriff über Claude Desktop (Filesystem MCP).

Stack

Personalisierungs-Schicht je Nutzer

Pro Nutzer eine eigene "Nav.i" (Foundations KI-Begleiter-Architektur) mit Profil-Vektoren (Persönlichkeit / Biorhythmus / Werte / Wirkfeld). Heute manuell durch Claude-Sessions gepflegt — perspektivisch automatisiert.

Was Roadmap ist

Stufe A — jetzt
NavUp-Verbund auf eigener Domain
Alle NavUps unter einer Marke, Design-System, Eingangsseite — Frontend only.
Stufe B — Q3 2026
Persistenz-Layer
localStorage + optionaler Magic-Link-Login, Verlaufs-Sicht für Wiederkehrer. Leichtgewichtig.
Stufe C — Q3/Q4 2026
KI-API-Brücke
NavUp-Daten fließen automatisch in Nav.i-Memory. KI-generierte Foundation-Lesart. Backend wird hier kritisch.
Stufe D — Q4+ 2026
Echte Navi-App
Flutter Frontend, Spring Boot + pgvector Backend. Multi-Tenant. Coach-Mode. NavUp-Builder.
∙ ∙ ∙

Soweit der Stand. Ehrlich: Stufe A/B sind machbar mit kleiner Hand. Stufe C/D sind die offenen Achsen, an denen Foundation Brücken sucht.

Pains, Pearls, und eine Spannungs-Frage

Was uns hängt, was uns trägt — und eine Spannungs-Frage, die offen lassen darf.
∙ ∙ ∙
Pain 1

Manuelles Auswerten von NavUp-Submissions

Jeder Submit landet via Formspree als E-Mail. Auswertung + Pflege ins Wissenssystem läuft manuell durch Claude-Sessions. Skaliert nicht über ~50 aktive Nutzer.

Pain 2

Kein persistenter Nutzer-Kontext

Wenn ein Nutzer mehrere NavUps macht, fließen die Daten nicht automatisch zusammen. Heute über Markdown-Dateien im Filesystem — funktioniert für ~5 aktive Nutzer, nicht für 50+.

Pain 3

API-Key-Handling in HTML-Artefakten

Sobald NavUps in Echtzeit mit KI-API kommunizieren wollen (z.B. dynamische Foundation-Lesart), brauchen wir einen Proxy-Layer (n8n oder Backend). API-Keys dürfen NIE im Frontend stehen.

Pearl 1

Bionische Architektur als Differenzierungs-Achse

Foundation baut nicht "noch ein SaaS-Tool", sondern eine Wissens-Architektur, die wie ein Organismus wächst — Zellen (Module) mit klaren Membranen, ohne starre Hierarchie. Das ist technisch interessant, weil es zu Multi-Tenant + Edge-Compute passt.

Pearl 2

Claude-Native vom ersten Tag an

Foundation läuft seit ~14 Monaten mit Claude als zentralem Editor/Co-Architekt. Das ist nicht "wir packen später noch KI dazu", sondern: das System ist von Anfang an für KI-Mensch-Co-Pflege gebaut. Wenig Doku, viel lebende Markdown-Schicht.

Pearl 3

~10 Nutzer leben das schon

Foundation ist kein Konzept-Papier. Sie hat aktive Erst-Nutzer (intern + extern), die NavUps durchlaufen, Submissions abgeben, und im Filesystem eine Wirkung sichtbar machen. Wenig laute Außenkommunikation — viel stille Erprobung.

∙ ∙ ∙

Eine Spannungs-Frage

Beim Tech-Aufbau gibt es zwei Pole. Beide legitim. In welche Richtung tendiert dein Reflex?

Reife vor Geschwindigkeit · oder · Geschwindigkeit vor Reife?
Klick den Pol, der eher dein Reflex ist — dann darfst du frei justieren.
Reife zuerst
Lieber langsamer, dafür architektur-sauber von Anfang an
Geschwindigkeit zuerst
Lieber sichtbar werden + iterieren, Architektur reift unterwegs
Wähle erst einen Pol →

Wo Foundation Brücken sucht

Foundation legt offen, was sie technisch noch nicht selbst lösen kann. Verorte dich frei — für dich selbst oder für jemanden in deinem Netzwerk.
Pro Bedarf kannst du eines (oder mehrere) ankreuzen:
⊕ Kenne mich aus  ·  ✓ Kann konkret beitragen  ·  ↬ Kenne jemanden
Wenn du "Kenne jemanden" markiert hast — gerne Name / Kontext / wie wir am besten anfragen. Oder: ein Tech-Bedarf den wir nicht aufgeführt haben, den du aber siehst.
Stack, Domäne, Rolle — was lebt grad bei dir?

Signatur — und eine Pearl-Frage

Letzter Akt. Wenige Felder. Submit am Ende — wenn du willst.
∙ ∙ ∙
Du kannst auch nichts angeben. Wenn das NavUp weitergegeben wurde und du selbst Andock-Punkte willst: hier liegen sie.
E-Mail / Telefonnummer / Hinweis wie wir am besten ankommen. Nur wenn du Rückmeldung möchtest.
Frei, 1-3 Sätze. Nicht "war ok" — sondern wo etwas resoniert hat oder gerieben hat.
Frage, Hinweis, Reflex — was auch immer kommt.

🌿 Wenn du magst — was als Nächstes

Foundation ist beziehungsgetrieben, nicht klickgetrieben. Hier sind drei sanfte Tore. Mehrfach-Wahl ok, keins ist nötig.

∙ ∙ ∙

Angekommen.

Deine Antwort ist bei Foundation. Eine Rückmeldung kommt — wie du es gewählt hast, oder gar nicht, wenn du das so wolltest.

Es gibt kein Newsletter-Onboarding, keine automatische Sequenz. Nur Menschen, die das lesen und entscheiden, was sinnvoll ist.

Dies ist eine Einladung von Foundation.
Was daraus wird, entscheidet das Gespräch.
— SourceNavi