Mit Independo entwickeln wir digitale Werkzeuge für und mit Menschen, die Unterstützte Kommunikation nutzen. Unsere Apps helfen dabei, Alltag, Termine und Erlebnisse so zugänglich wie möglich zu machen.

Künstliche Intelligenz kann dabei viel unterstützen: Texte vereinfachen, Inhalte zusammenfassen, Symbole vorschlagen oder beim Formulieren helfen. Gleichzeitig verändert sich die KI-Landschaft sehr schnell.

Vor kurzer Zeit war die wichtigste Frage oft: Welchen Cloud-Anbieter verwenden wir? Inzwischen ist die Antwort deutlich komplizierter:

• Apple baut mit Foundation Models einen Weg für KI direkt in iOS, iPadOS, macOS und andere Apple-Plattformen.
• Google entwickelt mit Gemini Nano, AICore und ML Kit GenAI eigene On-Device-Möglichkeiten für Android.
• Cloud-APIs wie OpenAI bleiben wichtig, weil sie starke Modelle, Streaming und breite Plattformunterstützung bieten.
• Open-Source-Runtimes wie llama.cpp, ONNX, MediaPipe oder ExecuTorch machen lokale und eingebettete Ausführung zunehmend realistischer.

Das ist spannend. Für App-Entwickler:innen ist es aber auch anstrengend.

Das Problem: zu viele Wege

Jeder Provider bringt eigene APIs, eigene Annahmen und eigene Grenzen mit. Manche Modelle laufen lokal am Gerät. Andere brauchen eine Internetverbindung. Manche sind sehr schnell, andere genauer. Manche sind günstiger, andere besser für komplexe Aufgaben. Und bei Anwendungen im Bereich digitaler Inklusion kommt noch eine zentrale Frage dazu: Welche Daten dürfen das Gerät überhaupt verlassen?

Eine App sollte solche Entscheidungen nicht an jeder Stelle neu hart einbauen müssen.

Stattdessen braucht es eine stabile Schicht, die prüft:

• Welche Provider sind gerade verfügbar?
• Welche Aufgabe soll ausgeführt werden?
• Gibt es Datenschutz- oder Kostenregeln?
• Ist das Gerät online?
• Ist lokale Ausführung möglich?
• Was passiert, wenn ein Provider ausfällt?
• Wie bekommt die App einen verständlichen Fehler zurück?

Genau dafür entsteht IndeRun.

Was IndeRun ist

IndeRun ist kein Modelltraining-Projekt. Wir trainieren also keine eigenen großen KI-Modelle.

IndeRun ist eine Ausführungs- und Routing-Schicht für KI-Funktionen. Die Idee ist: Eine App beschreibt, was sie braucht. IndeRun entscheidet, wo diese Aufgabe sinnvoll ausgeführt wird.

Das kann zum Beispiel sein:

• direkt am Gerät,
• in einer eingebetteten lokalen Runtime,
• an einem Edge-Dienst,
• oder über eine Cloud-API.

Für Entwickler:innen soll sich das möglichst gleich anfühlen. Die App ruft eine stabile Schnittstelle auf. IndeRun kümmert sich um Provider-Auswahl, Regeln, Fallbacks, Fehler und einheitliche Ergebnisse.

Welche Provider wir betrachten

Für die erste Architektur schauen wir uns bewusst nicht "alle" Möglichkeiten gleichzeitig an. Wichtiger ist ein stabiles Fundament.

Als Baseline-Kandidaten betrachten wir derzeit:

• OpenAI HTTP / Responses API als Cloud-Baseline,
• Apple Foundation Models als iOS-Pfad für lokale und systemnahe Modelle,
• Android ML Kit GenAI / Gemini Nano als Android-Pfad für lokale und systemnahe Modelle.

Darüber hinaus gibt es weitere Kandidaten für spätere Ausbaustufen:

• Hugging Face Inference API,
• lokale ONNX-Runtimes,
• MediaPipe LLM Inference,
• Core ML,
• ExecuTorch,
• llama.cpp oder lokale OpenAI-kompatible Server,
• später auch TTS- und Audio-Pfade.

Wichtig ist: Das sind Provider-Kandidaten und Architekturpfade. Nicht jeder davon ist schon implementiert. Für uns gilt gerade: stabile Architektur vor möglichst langer Provider-Liste.

Unsere Architekturentscheidung

Die aktuelle Architektur von IndeRun besteht aus drei Teilen.

Engine Core

Der Engine Core ist das gemeinsame Herzstück. Er soll unabhängig von einzelnen Plattformen bleiben und kümmert sich um:

• Provider-Registry,
• Routing und Policies,
• Fallback-Verhalten,
• Orchestrierung,
• einheitliche Events,
• Abbruchlogik,
• typisierte Fehler,
• Telemetrie und Route-Erklärungen.

Hier wird entschieden, welcher Provider für eine Anfrage passt. Zum Beispiel: lokal bevorzugen, aber nur wenn das Gerät die nötigen Fähigkeiten hat. Oder: Cloud nur erlauben, wenn die Policy das zulässt.

Host Services

Host Services sind die Verbindung zur jeweiligen Plattform. Sie liefern Informationen wie:

• Internetverbindung,
• Gerätezustand,
• sichere Speicherung von Zugangsdaten,
• Zeit und Systeminformationen,
• später eventuell Audio-Ein- und Ausgabe.

Der Engine Core soll nicht direkt iOS-, Android- oder Browser-spezifische APIs importieren. Dadurch bleibt er portabel und testbar.

Provider Adapters

Provider Adapters sind die Wrapper um konkrete Anbieter und Runtimes. Ein Adapter weiß, wie Apple Foundation Models, ML Kit GenAI, OpenAI oder ein späterer lokaler Provider angesprochen wird.

Die App soll diese Unterschiede möglichst nicht merken. Provider-spezifische Fehler, Events und Sonderfälle werden normalisiert, bevor sie in der öffentlichen IndeRun-API landen.

Die API-Form: Run, Stream, Session

Auch bei der API wollen wir zuerst klare Grundformen schaffen.

Run

Eine Anfrage geht hinein, ein Ergebnis kommt zurück. Das ist der einfachste Fall, etwa für "fasse diesen Text zusammen" oder "schlage Symbole für diesen Satz vor".

Stream

Bei längeren Antworten kann die App Zwischenergebnisse als Event-Stream erhalten. Wichtig ist dabei auch: Abbruch muss zuverlässig funktionieren. Nach einem Cancel dürfen keine verspäteten Events mehr in der App landen.

Session

Für spätere bidirektionale oder Echtzeit-Interaktionen planen wir eine Session-Form. Das ist relevant für komplexere Dialoge, kontinuierliche Kontexte oder spätere Audio-Anwendungen.

Was wir bewusst noch nicht bauen: dauerhafte Async-Jobs oder Queue-Infrastruktur. Die Architektur lässt dafür Raum, aber für den Anfang konzentrieren wir uns auf die Kernfälle.

Warum JSON Schema?

IndeRun soll über mehrere Plattformen hinweg konsistent sein: TypeScript, Swift, Kotlin und Capacitor-Bridges sollen dieselben Grundverträge verstehen.

Darum verwenden wir JSON Schema als kanonische Quelle für zentrale Verträge:

• Requests,
• Ergebnisse,
• Events,
• Fehler,
• Provider-Beschreibungen,
• Capability-Snapshots.

Das klingt technisch, hat aber einen einfachen Zweck: Wenn eine App auf iOS, Android und Web dieselbe Aufgabe stellt, sollen Begriffe, Fehlerklassen und Ergebnisse nicht auseinanderlaufen.

Gerade für Open Source ist das wichtig. Andere Entwickler:innen sollen nachvollziehen können, was eine IndeRun-Anfrage bedeutet und wie ein Provider sich verhalten muss.

Warum das für Inklusion wichtig ist

Für viele KI-Anwendungen ist ein Fehler ärgerlich. Für Menschen, die auf digitale Unterstützungswerkzeuge angewiesen sind, kann er aber viel stärker ins Gewicht fallen.

Wenn eine App beim Kommunizieren, Planen oder Verstehen hilft, muss sie vorhersehbar reagieren. Sie sollte erklären können, warum etwas nicht funktioniert. Sie sollte lokale Ausführung bevorzugen können, wenn Datenschutz wichtig ist. Und sie sollte sauber ausweichen können, wenn ein Provider gerade nicht verfügbar ist.

Mit IndeRun wollen wir dafür eine technische Grundlage schaffen:

• bessere Kontrolle über Datenschutz,
• nachvollziehbare Routing-Entscheidungen,
• klare Fehler statt versteckter Provider-Ausnahmen,
• zuverlässige Fallbacks,
• weniger Abhängigkeit von einem einzelnen Anbieter.

So wird KI nicht automatisch inklusiv. Aber sie wird besser integrierbar, prüfbarer und verantwortbarer.

Wie es weitergeht

Der nächste Schritt ist die stabile Grundlage für Milestone 1: Verträge, Runtime-Kern, einfache Policies, erste Provider-Pfade, SDK-Oberflächen und Dokumentation.

Sobald die erste v0.1-Version und das öffentliche Release bereit sind, werden wir dazu einen eigenen Beitrag veröffentlichen.

Bis dahin klären wir bewusst zuerst die Architektur. Denn genau dort entscheidet sich, ob IndeRun später wirklich das leisten kann, was wir brauchen: eine offene, verlässliche und provider-unabhängige Grundlage für KI-Funktionen in inklusiven Apps.