diff --git a/docs/architecture/functional/guardrails.md b/docs/architecture/functional/guardrails.md new file mode 100644 index 0000000..8463b38 --- /dev/null +++ b/docs/architecture/functional/guardrails.md @@ -0,0 +1,719 @@ +--- +title: "Kanshō – Guardrails, Privacy Gateway und externe KI" +version: "0.1" +status: "In Bearbeitung" +date: "2026-08-18" +document_role: "Querschnittliches Fachkapitel / Privacy / AI Egress / Guardrails" +parent_document: "fachliche_zielarchitektur.md" +--- + +# Kanshō – Guardrails, Privacy Gateway und externe KI + +## 1. Zweck dieses Dokuments + +Dieses Dokument beschreibt die fachlichen Guardrails für den Umgang mit besonders sensiblen persönlichen Daten in Kanshō, insbesondere bei Nutzung externer KI-Dienste. + +Kanshō soll langfristig vollständige Dialoge, zeitgebundene Innenperspektiven, Gedanken, beschriebene Gefühle, Zweifel, biografische Zusammenhänge und daraus abgeleitete persönliche Modelle speichern können. + +Diese Daten bilden eine besonders sensible Ebene des persönlichen digitalen Zwillings. + +Gleichzeitig ist vorgesehen, für leistungsfähige KI-Funktionen weitgehend externe Dienste beziehungsweise Modellprovider, beispielsweise über OpenRouter, zu verwenden, weil die derzeitige lokale Infrastruktur große Modelle nicht in ausreichender Qualität und Geschwindigkeit betreiben kann. + +Daraus entsteht eine zentrale Architekturaufgabe: + +> **Externe KI soll hohe semantische Leistungsfähigkeit liefern können, ohne dass die externe Seite die reale Identität des Nutzers oder unnötig viele identifizierende Merkmale erhält.** + +Dieses Dokument definiert dafür fachliche Schutzprinzipien. Die konkrete technische Implementierung wird später in Security-, Privacy-, AI- und Data-Architecture-Kapiteln spezifiziert. + +--- + +# 2. Root-Cause-Herleitung + +## 2.1 Root Cause + +Kanshō benötigt für hochwertige, kontextreiche und langfristige Reflexionsdialoge leistungsfähige Sprachmodelle. + +Die aktuell verfügbare lokale Infrastruktur ist dafür nicht ausreichend leistungsfähig. Eine weitgehend lokale Ausführung großer Modelle ist deshalb derzeit keine tragfähige Grundannahme. + +Gleichzeitig verarbeitet Kanshō potenziell besonders sensible autobiografische Informationen, darunter: + +- vollständige persönliche Dialoge, +- Gedanken und beschriebene Gefühle, +- Zweifel und Ambivalenzen, +- Beziehungen und Familienkontexte, +- berufliche Situationen, +- Gesundheitsbezüge, +- Werte und Weltanschauungen, +- biografische Ereignisse, +- zeitgebundene Innenperspektiven, +- Self-Model-Informationen, +- möglicherweise besondere Kategorien personenbezogener Daten. + +Eine direkte Übertragung vollständiger, identifizierbarer Kanshō-Kontexte an externe KI-Dienste würde daher eine sehr große und langfristig schwer kontrollierbare Vertrauensgrenze erzeugen. + +## 2.2 Risiko + +Ohne Schutzschicht könnten externe Dienste oder deren nachgelagerte Provider: + +- den realen Namen oder andere direkte Identifikatoren erhalten, +- Personen aus dem privaten Umfeld identifizieren, +- genaue Orte, Arbeitgeber oder Adressen erhalten, +- über Kombination mehrerer Merkmale eine Person indirekt wiedererkennen, +- langfristige autobiografische Profile mit einer realen Identität verknüpfen, +- sensible Informationen unnötig speichern oder protokollieren, +- Daten über Tool- oder Providerketten an weitere Systeme weiterreichen. + +Besonders kritisch ist, dass Kanshō-Kontexte mit zunehmender Nutzungsdauer immer reichhaltiger werden. Selbst ein Text ohne Namen kann durch seltene Kombinationen aus Beruf, Ort, Familie, Ereignissen und Zeitpunkten identifizierbar werden. + +## 2.3 Fachliche Konsequenz + +Die Architektur darf externe Inferenz nicht mit direktem Zugriff auf den vollständigen internen Personenkontext gleichsetzen. + +Es wird eine lokale Vertrauensgrenze benötigt, die: + +- interne Identität und externe Modellrepräsentation trennt, +- den Kontext vor jeder externen Anfrage minimiert, +- direkte Identifikatoren pseudonymisiert, +- besonders sensible Daten gegebenenfalls vollständig zurückhält, +- externe Antworten vor lokaler Weiterverarbeitung prüft, +- Identitäten ausschließlich lokal wiederherstellt. + +## 2.4 Abgeleitete Architektur-Invariante + +> **Identität bleibt lokal. Externe Intelligenz erhält nur den für die Aufgabe notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.** + +Diese Invariante gilt unabhängig davon, welcher externe Modellprovider später verwendet wird. + +--- + +# 3. Grundbegriffe + +## 3.1 Pseudonymisierung ist nicht Anonymisierung + +Das Maskieren eines Namens durch einen symbolischen Platzhalter macht einen Dialog nicht automatisch anonym. + +Pseudonymisierung reduziert die direkte Verknüpfbarkeit mit einer Person. Solange die Zuordnung mit zusätzlichen Informationen wiederhergestellt werden kann, bleiben die Daten grundsätzlich personenbezogen. + +Daher gilt: + +> Kanshō soll gegenüber externen KI-Diensten **pseudonymisierte und datenminimierte Kontexte** erzeugen. Eine vollständige Anonymität wird nicht behauptet. + +## 3.2 Direkte Identifikatoren + +Beispiele: + +- Name, +- E-Mail-Adresse, +- Telefonnummer, +- postalische Adresse, +- Benutzername, +- Kundennummer, +- Fahrzeugkennzeichen, +- Vertragsnummer, +- Kontodaten, +- eindeutige technische IDs. + +## 3.3 Quasi-Identifikatoren + +Auch ohne Namen können Kombinationen identifizierend wirken, beispielsweise: + +- seltene berufliche Rolle, +- konkrete Organisation, +- genauer Wohnort, +- exaktes Alter, +- Familienstruktur, +- seltenes Ereignis, +- konkrete Zeit-/Ortskombination, +- Kombination aus mehreren biografischen Merkmalen. + +Diese Merkmale müssen kontextabhängig bewertet werden. + +--- + +# 4. Vertrauensgrenzen + +Kanshō unterscheidet mindestens folgende Vertrauenszonen. + +## 4.1 Local Trusted Zone + +Darf vollständige Identität und Primärquellen enthalten. + +Dazu gehören insbesondere: + +- Identity Mapping, +- vollständige Dialogquellen, +- echte Namen, +- private Adressen, +- originale Obsidian-/mindnet-Referenzen, +- vollständiger digitaler Zwilling, +- lokale API-Secrets, +- Demasking-Tabellen, +- Privacy- und Routing-Konfiguration. + +## 4.2 External AI Zone + +Erhält ausschließlich einen für die jeweilige Inferenz erzeugten External Model Context. + +Dieser Kontext soll: + +- minimiert, +- pseudonymisiert, +- aufgabenspezifisch, +- provenance-aware, +- zeitlich begrenzt + +sein. + +## 4.3 Tool-/Plugin-Zone + +Externe Tools, Websuche, Plugins oder nachgelagerte Dienste bilden eine eigene Vertrauenszone. + +Eine Freigabe für externe LLM-Inferenz bedeutet **nicht automatisch**, dass derselbe Kontext an Tools oder Suchdienste weitergegeben werden darf. + +--- + +# 5. Datenklassen + +## 5.1 Klasse A – Local Only + +Diese Daten sollen die lokale Vertrauenszone grundsätzlich nicht verlassen. + +Beispiele: + +- Mapping echter Namen zu Pseudonymen, +- API-Secrets, +- vollständige Adressen, +- vollständiges Identitätsprofil, +- interne Berechtigungsinformationen, +- technische Security-Secrets, +- Rohdaten, deren externe Verarbeitung nicht erforderlich ist. + +Abhängig vom späteren Schutzbedarf können weitere Datenarten als Local Only klassifiziert werden. + +## 5.2 Klasse B – Pseudonymized AI Context + +Dies ist der erwartete Normalfall für persönliche KI-Dialoge. + +Beispiele: + +- relevante Dialogauszüge, +- Reflection Memories, +- relevante Self-Model-Informationen, +- Reflection-Space-Kontext, +- autobiografische Episoden, +- ausgewählte mindnet-Kontexte. + +Vor externem Versand werden diese Inhalte lokal minimiert und pseudonymisiert. + +## 5.3 Klasse C – Low-Identity / Non-identifying Context + +Inhalte mit keinem oder sehr geringem Personenbezug. + +Beispiele: + +- allgemeine Meditationsmethoden, +- generische Schreibfragen, +- allgemeine Wissensfragen, +- nicht-personalisierte Hilfstexte. + +Hier kann eine weniger starke Transformation ausreichend sein. + +--- + +# 6. Local Privacy Gateway + +Zwischen Kanshō und jeder externen KI-Inferenz soll fachlich eine lokale Privacy-Gateway-Schicht liegen. + +## 6.1 Aufgaben + +Das Gateway soll mindestens folgende Verantwortlichkeiten besitzen: + +1. Context Minimization +2. Entity Detection +3. Pseudonymization +4. Policy Check +5. Provider/Endpoint Eligibility Check +6. Egress Validation +7. Response Validation +8. Local Rehydration / Demasking +9. Audit Metadata +10. Fail-Closed Handling + +## 6.2 Keine direkte externe Modellanbindung + +Fachliche Invariante: + +> **Kanshō-Komponenten senden persönlichen Kontext nicht direkt an externe Modellprovider.** + +Alle persönlichen External-AI-Aufrufe laufen über die Privacy- und Routing-Schicht. + +--- + +# 7. External Model Context + +Der interne Context Builder kann mit der realen Identität und vollständigen lokalen Referenzen arbeiten. + +Vor einem externen Modellaufruf entsteht daraus eine zweite Repräsentation: + +## 7.1 Internal Context + +Beispiel: + +- reale Personennamen, +- reale Orte, +- vollständige Provenance, +- interne IDs, +- vollständige Verbindungen. + +## 7.2 External Model Context + +Beispiel: + +- `[[SELF]]` +- `[[PERSON:PARTNER]]` +- `[[PERSON:CHILD_01]]` +- `[[PERSON:COLLEAGUE_03]]` +- `[[ORG:EMPLOYER]]` +- `[[PLACE:HOME_CITY]]` +- `[[PLACE:VACATION_01]]` + +Der External Model Context enthält nur Informationen, die für die konkrete Aufgabe erforderlich sind. + +--- + +# 8. Pseudonymisierung und symbolische Platzhalter + +## 8.1 Stabile Pseudonyme + +Pseudonyme sollen innerhalb sinnvoller Kontexte stabil sein. + +Dies ermöglicht dem externen Modell, Beziehungen zwischen Personen oder Orten korrekt zu verstehen, ohne die reale Identität zu kennen. + +Beispiel: + +`[[PERSON:PARTNER]]` + +soll in zusammengehörenden Modellkontexten dieselbe Person bezeichnen. + +## 8.2 Keine unnötig sprechenden Aliase + +Pseudonyme sollen nicht mehr Information transportieren als fachlich erforderlich. + +Zu vermeiden wären beispielsweise: + +- `[[PERSON:INDIAN_WIFE]]` +- `[[PERSON:SON_WITH_MEDICAL_CONDITION]]` +- `[[ORG:GERMAN_RESEARCH_EMPLOYER]]` + +wenn diese zusätzlichen Informationen für die Aufgabe nicht notwendig sind. + +## 8.3 Lokale Mapping-Tabelle + +Die Zuordnung: + +`Pseudonym → reale Identität` + +bleibt ausschließlich lokal. + +Sie wird nicht Bestandteil: + +- externer Prompts, +- Modellmetadaten, +- Logdaten, +- Provider-Konfigurationen. + +## 8.4 Demasking + +Nach Rückkehr einer Modellantwort erfolgt die Wiederherstellung realer Namen beziehungsweise lokaler Begriffe ausschließlich innerhalb der Trusted Zone. + +--- + +# 9. Kontextabhängige Datenminimierung + +Nicht jede personenbezogene Information muss pauschal maskiert werden. + +Ziel ist: + +> **So wenig Identifizierbarkeit wie möglich, so viel semantischer Kontext wie für eine hochwertige Antwort notwendig.** + +Beispiele: + +### Möglicherweise entbehrlich + +Für eine Reflexionsfrage zur eigenen Erholung ist die konkrete private Adresse vermutlich irrelevant. + +### Möglicherweise relevant + +Der Unterschied zwischen: + +- Urlaubsort, +- Arbeitsplatz, +- Zuhause, +- Trainingsumfeld + +kann für eine Reflexion sehr relevant sein. + +Dann kann statt des echten Ortsnamens ein semantisch sinnvoller Platzhalter verwendet werden. + +--- + +# 10. Indirekte Re-Identifikation + +Das Privacy Gateway soll nicht nur Klarnamen erkennen. + +Es soll perspektivisch auch das Re-Identifikationsrisiko eines External Model Context bewerten. + +Mögliche Risikofaktoren: + +- genaue Kombination aus Alter + Beruf + Ort, +- seltene Rollen, +- konkrete Arbeitgeber, +- exakte Ereignisdaten, +- ungewöhnliche Familienkonstellationen, +- seltene biografische Ereignisse, +- wiederkehrende Kombination mehrerer Quasi-Identifikatoren. + +Die konkrete Bewertung wird später technisch spezifiziert. + +Fachliches Ziel ist nicht mathematisch garantierte Anonymität, sondern eine deutliche Reduzierung unnötiger Identifizierbarkeit. + +--- + +# 11. Externe Provider-Policy + +Externe KI-Dienste dürfen nicht allein aufgrund von Modellqualität ausgewählt werden. + +Privacy-Eigenschaften sind Teil der Routing-Policy. + +## 11.1 Zero Data Retention + +Für persönliche Kanshō-Kontexte soll grundsätzlich ein Zero-Data-Retention-Modus beziehungsweise ein funktional gleichwertiger Providerzustand verlangt werden. + +Für OpenRouter ist aktuell dokumentiert, dass ZDR auf unterschiedlichen Ebenen erzwungen werden kann und nur entsprechend gekennzeichnete Endpoints verwendet werden. + +## 11.2 Kein Training mit Kanshō-Inhalten + +Provider beziehungsweise Routen, bei denen Input/Output für Training oder Produktverbesserung genutzt werden dürfen, sollen für persönliche Kanshō-Kontexte nicht zugelassen werden. + +## 11.3 Kein freiwilliges Prompt Logging + +OpenRouter dokumentiert aktuell, dass eigene Prompt-/Response-Speicherung opt-in ist. + +Für Kanshō soll diese freiwillige Speicherung nicht aktiviert werden. + +## 11.4 EU-/Region-Routing + +Wenn ein geeigneter Provider und ein geeignetes Modell verfügbar sind, soll regionale Verarbeitung innerhalb der EU bevorzugt beziehungsweise – abhängig vom späteren Policy-Level – erzwungen werden können. + +Modellqualität, Verfügbarkeit und Datenschutzanforderung müssen dabei transparent gegeneinander abgewogen werden. + +## 11.5 Fail Closed + +Für sensitive oder persönliche Kontexte gilt als bevorzugtes Prinzip: + +> **Ist kein Endpoint verfügbar, der die erforderliche Privacy Policy erfüllt, wird die Anfrage nicht stillschweigend an einen weniger geschützten Provider weitergereicht.** + +Stattdessen: + +- lokale Fallback-Funktion, +- weniger leistungsfähige lokale Verarbeitung, +- spätere Wiederholung, +- oder transparente Meldung an den Nutzer. + +Die konkrete Fallback-Strategie wird später definiert. + +--- + +# 12. OpenRouter als möglicher Routing-Dienst + +OpenRouter ist derzeit ein naheliegender Kandidat, weil es: + +- unterschiedliche Modellprovider bündeln kann, +- Zero Data Retention unterstützen kann, +- Provider- und Privacy-Routing ermöglicht, +- Daten- und Provider-Policies konfigurierbar macht. + +Wichtig: + +OpenRouter ist **kein fixer Architekturzwang**. + +Guardrails werden providerunabhängig formuliert, damit später: + +- OpenRouter, +- direkter Providerzugriff, +- EU-basierte Inferenz, +- eigene GPU-Infrastruktur, +- oder lokale Modelle + +austauschbar bleiben. + +--- + +# 13. Tool- und Web-Egress + +LLM-Inferenz und externe Tools werden getrennt betrachtet. + +Ein persönlicher Kontext, der für einen ZDR-LLM-Endpunkt freigegeben wurde, darf nicht automatisch an: + +- Web Search, +- Plugins, +- externe Agenten, +- Analytics, +- Speech-Dienste, +- Transkriptionsdienste + +weitergereicht werden. + +Jeder Egress-Typ benötigt eine eigene Policy. + +Dies gilt insbesondere, weil Provider-ZDR-Regeln nicht automatisch auf externe Tools oder weitere Dienste übertragbar sind. + +--- + +# 14. Response Validation und Rehydration + +Die Antwort eines externen Modells wird nicht unmittelbar als vertrauenswürdiger lokaler Inhalt behandelt. + +Vor Demasking sollte die lokale Schicht mindestens prüfen können: + +- Sind bekannte Platzhalter korrekt erhalten? +- Wurden Platzhalter verwechselt? +- Sind neue, unbekannte Pseudonyme entstanden? +- Hat das Modell versucht, reale Identitäten zu erraten? +- Enthält die Antwort unerwartete identifizierende Informationen? +- Enthält sie Inhalte, die gegen die Egress-/Privacy-Policy verstoßen? + +Erst danach erfolgt: + +1. lokale Rehydration, +2. fachliche Weiterverarbeitung, +3. Anzeige beziehungsweise Speicherung. + +--- + +# 15. Beziehung zu Lived Experience / Digital Twin + +Die Privacy-Architektur muss mit dem Lived-Experience-Layer konsistent bleiben. + +Insbesondere gilt: + +- vollständige Dialoge bleiben Primärquellen, +- externe Modelle benötigen nicht automatisch vollständige Primärquellen, +- Context Builder und Privacy Gateway wählen nur notwendige Ausschnitte, +- Pseudonymisierung verändert nicht die lokale Originalquelle, +- Demasking findet ausschließlich lokal statt, +- Re-Grounding arbeitet lokal mit Originalquellen und erzeugt für externe Inferenz erneut einen minimierten External Model Context. + +Damit kann ein reicher digitaler Zwilling lokal erhalten bleiben, ohne vollständig an externe Dienste übertragen zu werden. + +--- + +# 16. Beziehung zu Thread Resurfacing und Reflection Saturation + +Resurfacing und Saturation dürfen Privacy Guardrails nicht umgehen. + +Beispiele: + +- Ein wieder auftauchender Thread darf nur den dafür notwendigen historischen Kontext extern verfügbar machen. +- Eine hohe Reflection Saturation rechtfertigt keine umfassendere Datenweitergabe. +- Bei Re-Grounding muss anschließend erneut minimiert und pseudonymisiert werden. +- Explizite Nutzeranfragen ändern nicht automatisch die Egress-Klasse sensibler Daten. + +--- + +# 17. Rollen und Transparenz + +Die Admin-/Developer View soll perspektivisch Privacy-Entscheidungen inspizierbar machen. + +Mögliche Informationen: + +- welche Entitäten maskiert wurden, +- welche Datenklasse angewendet wurde, +- welcher Provider beziehungsweise Endpoint gewählt wurde, +- ob ZDR erzwungen wurde, +- welche Policy einen Request zugelassen oder blockiert hat, +- welche Informationen vor Egress entfernt wurden, +- ob Output-Validation Auffälligkeiten gefunden hat. + +Die echte Mapping-Tabelle soll auch in dieser Ansicht nur soweit sichtbar sein, wie dies für eine besonders berechtigte Rolle tatsächlich erforderlich ist. + +--- + +# 18. Logging und Audit + +Privacy- und Security-Audit benötigen Metadaten, ohne selbst neue sensible Langzeitlogs zu erzeugen. + +Bevorzugt gespeichert werden: + +- Request-ID, +- Zeitpunkt, +- verwendete Policy, +- Provider-/Modellkennung, +- ZDR-/Region-Status, +- Anzahl beziehungsweise Typ maskierter Entitäten, +- Ergebnis der Egress-Prüfung, +- Ergebnis der Response-Prüfung, +- Fehler-/Fallback-Status. + +Nicht automatisch in Audit Logs gespeichert werden sollen: + +- vollständige externe Prompts, +- vollständige Modellantworten, +- echte Namen, +- Identity Mapping. + +--- + +# 19. Guardrail-Priorität + +Guardrails haben Vorrang vor: + +- Modellqualität, +- Kostenoptimierung, +- Latenz, +- Komfort, +- automatischem Provider-Fallback. + +Ein Modellaufruf darf abgelehnt oder degradiert werden, wenn die Privacy Policy nicht erfüllt werden kann. + +--- + +# 20. Konfigurierbarkeit + +Nicht jede Art von Inhalt benötigt identische Schutzstufen. + +Perspektivisch kann es konfigurierbare Privacy Profiles geben, beispielsweise: + +- **Strict** +- **Balanced** +- **Low-Identity / Generic** + +Die konkrete Ausprägung ist offen. + +Wichtig: + +Der Nutzer soll nicht bei jeder Anfrage technische Provider-Parameter entscheiden müssen. + +Die Konfiguration soll weitgehend als Policy hinterlegt sein. + +--- + +# 21. Noch offene Fragen + +1. Welche Entitätstypen werden standardmäßig pseudonymisiert? +2. Welche Daten sind zwingend Local Only? +3. Wie werden Quasi-Identifikatoren erkannt? +4. Wie wird ein Re-Identifikationsrisiko bewertet? +5. Wie stabil beziehungsweise kontextgebunden sind Pseudonyme? +6. Wie werden mehrere Nutzer und Mandanten getrennt? +7. Welche Provider sind für welche Privacy-Profile zugelassen? +8. Wird EU-Routing verpflichtend oder bevorzugt? +9. Welche lokale Fallback-Funktion wird benötigt? +10. Wie wird Voice/Transcription in dieselbe Trust-Architektur integriert? +11. Welche Policies gelten für Web Search und Plugins? +12. Wie werden Retention und vollständiges Löschen umgesetzt? +13. Wie wird das Identity Mapping verschlüsselt und gesichert? +14. Welche Funktionen benötigt die Admin-/Developer View? +15. Welche Guardrails müssen deterministisch sein und welche dürfen KI-gestützt arbeiten? +16. Wie wird verhindert, dass eine KI über den pseudonymisierten Kontext reale Identitäten erschließt? +17. Wie wird Egress bei besonders sensiblen Kategorien zusätzlich eingeschränkt? +18. Welche rechtliche Bewertung beziehungsweise Datenschutz-Folgenabschätzung ist bei einer späteren Mehrbenutzer-/Produktnutzung erforderlich? + +--- + +# 22. Entscheidungsstand + +| Thema | Entscheidung / Arbeitsstand | +|---|---| +| Externe KI | für leistungsfähige Kanshō-Funktionen grundsätzlich vorgesehen | entschieden | +| Lokale Modelle | aktuell nicht als alleinige leistungsfähige Basis vorausgesetzt | entschieden | +| Privacy Gateway | zwingende lokale Vertrauensgrenze vor persönlichem externem AI-Egress | entschieden | +| Identität | bleibt lokal | entschieden | +| Klarnamen | vor externem AI-Egress symbolisch pseudonymisieren, soweit relevant | entschieden | +| Identity Mapping | ausschließlich lokal | entschieden | +| Datenminimierung | zusätzlich zur Pseudonymisierung erforderlich | entschieden | +| Pseudonymisierung vs. Anonymität | keine Behauptung vollständiger Anonymität | entschieden | +| External Model Context | getrennte, minimierte Repräsentation des internen Kontextes | entschieden | +| ZDR | für persönliche externe KI-Kontexte grundsätzlich erforderlich | bevorzugte verbindliche Policy | +| Prompt Logging | für persönliche Kanshō-Kontexte nicht aktivieren | entschieden | +| Provider-Training | persönliche Kanshō-Kontexte nicht für Training freigeben | entschieden | +| Fail Closed | kein stillschweigender Fallback auf weniger geschützte Provider | bevorzugte Richtung | +| EU Routing | bevorzugt / mögliche strengere Policy später | offen in Ausprägung | +| Tool Egress | getrennte Policy von LLM Egress | entschieden | +| Response Validation | lokale Prüfung vor Demasking | entschieden | +| Rehydration | ausschließlich lokal | entschieden | +| Guardrails | providerunabhängig definieren | entschieden | + +--- + +# 23. Externe Referenzquellen + +Für die weitere technische und rechtliche Ausarbeitung wurden unter anderem folgende Primärquellen als Ausgangspunkt verwendet: + +- OpenRouter – Data Collection / Privacy + https://openrouter.ai/docs/guides/privacy/data-collection + +- OpenRouter – Zero Data Retention + https://openrouter.ai/docs/guides/features/zdr + +- OpenRouter – Provider Logging / Data Retention Policies + https://openrouter.ai/docs/guides/privacy/provider-logging + +- OpenRouter – Guardrails + https://openrouter.ai/docs/guides/features/guardrails + +- OpenRouter – Sovereign AI / EU Routing + https://openrouter.ai/docs/guides/features/sovereign-ai + +- European Data Protection Board – Guidelines 01/2025 on Pseudonymisation + https://www.edpb.europa.eu/public-consultations/guidelines-012025-on-pseudonymisation_en + +- Regulation (EU) 2016/679 (GDPR) – EUR-Lex + https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng + +Diese Quellen dienen als fachlicher Ausgangspunkt. Vor einer späteren produktiven Mehrbenutzer- oder kommerziellen Nutzung sind die dann gültigen Providerbedingungen und rechtlichen Anforderungen erneut zu prüfen. + +# 24. Migrierte Architekturverweise + + + +### 2.13 Privacy Gateway und External-AI-Guardrails + +Für leistungsfähige Kanshō-Funktionen ist externe KI-Inferenz grundsätzlich zulässig und aufgrund der aktuell begrenzten lokalen Modellleistung voraussichtlich notwendig. + +Gleichzeitig verarbeitet Kanshō besonders sensible, langfristige autobiografische und dialogische Daten. + +Daraus folgt die verbindliche Architektur-Invariante: + +> **Identität bleibt lokal. Externe Intelligenz erhält nur den notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.** + +Persönliche externe AI-Aufrufe müssen deshalb über eine lokale Privacy-Gateway-/Egress-Schicht laufen. + +Diese Schicht muss mindestens berücksichtigen: + +- Datenminimierung, +- Pseudonymisierung und symbolische Platzhalter, +- ausschließlich lokale Identity-Mappings, +- getrennten Internal und External Model Context, +- Provider-/ZDR-Policy, +- Fail-Closed-Verhalten, +- getrennte Policies für LLM-, Tool- und Web-Egress, +- lokale Response-Validation und Rehydration, +- Auditierbarkeit ohne vollständige Prompt-Logs. + +Die vollständige fachliche Herleitung und Guardrail-Spezifikation wird in `guardrails.md` geführt. Spätere Kapitel zu AI Architecture, Data Architecture, Privacy, Security, Voice, Web/Tool-Nutzung, Memory und Integrationen müssen damit konsistent bleiben. + + + +### Guardrails und externe KI + +Kanshō soll leistungsfähige externe KI-Dienste nutzen können, ohne deshalb die vollständige reale Identität und den lokalen digitalen Zwilling ungefiltert nach außen zu übertragen. + +Dafür gilt als querschnittliche Produkt- und Architektur-Invariante: + +> **Identität bleibt lokal. Externe Intelligenz erhält nur den für die Aufgabe notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.** + +Klarnamen und andere identifizierende Informationen sollen vor persönlichem externem AI-Egress durch eine lokale Privacy-Gateway-Schicht erkannt, minimiert beziehungsweise durch symbolische Platzhalter ersetzt und nach Rückkehr der Antwort ausschließlich lokal wiederhergestellt werden. + +Die vollständige Herleitung, Datenklassen, Provider-Policies, ZDR-Anforderungen, Tool-Egress-Regeln und offenen Fragen werden im eigenständigen Fachkapitel `guardrails.md` geführt. + diff --git a/docs/architecture/functional/integrations.md b/docs/architecture/functional/integrations.md new file mode 100644 index 0000000..8c1a6ac --- /dev/null +++ b/docs/architecture/functional/integrations.md @@ -0,0 +1,184 @@ +--- + title: "Kanshō – Integrationen und Produktgrenzen" + status: "Arbeitsstand" + date: "2026-08-18" + product_family: "Jinkendo" + document_role: "Fachkapitel / Jinkendo Integrations / Product Boundaries" + parent_document: "fachliche_zielarchitektur.md" + --- + + # Kanshō – Integrationen und Produktgrenzen + +Dieses Dokument ist das kanonische Home für die Rollen der bestehenden Jinkendo-Komponenten, Integrationsgrenzen und fachlichen Übergaben. + + + +## 2. Ausgangslage + +Innerhalb der Jinkendo-Produktfamilie existieren bereits mehrere Anwendungen mit klar abgegrenzten Aufgabenbereichen. + +Die neue Anwendung entsteht daher **nicht als isoliertes Einzelprodukt**, sondern als weitere Komponente eines bereits vorhandenen persönlichen digitalen Ökosystems. + +Bereits vorhandene Systeme übernehmen insbesondere folgende Aufgaben: + +### 2.1 Kairo + +Kairo ist primär für Planung, Steuerung und persönliche Entwicklung zuständig. + +Dazu gehören unter anderem: + +- Ziele, +- Vorhaben, +- Initiativen, +- Projekte, +- persönliche Entwicklungspfade, +- Rituale, +- Roadmaps, +- Meilensteine, +- Aufgaben und Next Best Actions. + +Für die neue Anwendung bedeutet dies: + +**Planung ist nicht ihre Kernaufgabe.** + +Erkenntnisse aus Reflexionen können später an Kairo übergeben werden, wenn daraus eine Absicht, ein Ziel, ein Ritual oder eine konkrete Maßnahme entsteht. + +--- + +### 2.2 mindnet + +mindnet bildet das persönliche Wissensnetz. + +Der derzeitige Schwerpunkt liegt auf: + +- Obsidian als menschenlesbarer Wissens- und Notizbasis, +- Qdrant als semantischer Retrieval-Schicht, +- semantischer Suche, +- Beziehungen zwischen Wissenselementen, +- Edges wie beispielsweise `belongs_to`, `next`, `prev`, `references` und `backlink`, +- perspektivisch der Abbildung tieferer Bedeutungs- und Zusammenhangsstrukturen. + +mindnet ist für die neue Anwendung besonders relevant, weil dort langfristig unter anderem folgende Informationen liegen oder liegen können: + +- Erfahrungen, +- Erlebnisse, +- Entscheidungen, +- Erkenntnisse, +- Werte, +- Leitbild, +- persönliche Prinzipien, +- autobiografische Zusammenhänge, +- noch ungeklärte oder unvollständige Beziehungsketten. + +Die neue Anwendung soll Informationen aus mindnet für Reflexionen nutzen und umgekehrt relevante Ergebnisse wieder in das langfristige Wissenssystem überführen. + +--- + +### 2.3 Shinkan + +Shinkan ist für Training und Trainingsorganisation zuständig. + +Dazu gehören unter anderem: + +- Übungen, +- Trainingsvorlagen, +- Trainingsplanung, +- Programme, +- Medien, +- Trainingsmethodik. + +Für die neue Anwendung bedeutet dies: + +**Trainingsplanung und Übungsverwaltung werden nicht dupliziert.** + +Reflexionen zu Training, Lernen, Kampfkunst oder persönlichen Erfahrungen im Training können jedoch Bestandteil eines Reflexionsdialogs sein. + +--- + +### 2.4 Mitai + +Mitai bildet körperliche Entwicklung und Gesundheitskontext ab. + +Dazu gehören unter anderem: + +- körperliche Entwicklung, +- Fitness, +- Ernährung, +- Essverhalten, +- Vitalwerte, +- gesundheitsbezogene Verläufe. + +Für die neue Anwendung bedeutet dies: + +**Körper- und Gesundheitsdaten werden nicht nochmals als eigenes Tracking-System aufgebaut.** + +Kanshō kann solche Informationen jedoch – abhängig von Berechtigungen und Kontext – in Reflexionen einbeziehen. + +--- + + + +## 20. Integrationsprinzipien + +### 20.1 Kairo + +Kanshō kann: + +- relevante Ziele oder Entwicklungskontexte lesen, +- Handlungsabsichten erkennen, +- Action Candidates erzeugen, +- Übergabe an Kairo anbieten. + +Kanshō übernimmt keine dauerhafte Aufgaben- oder Zielverwaltung. + +--- + +### 20.2 mindnet + +Kanshō kann: + +- relevantes persönliches Wissen abrufen, +- Werte und Leitbild einbeziehen, +- frühere Erfahrungen finden, +- ähnliche Themen erkennen, +- offene Zusammenhänge aufnehmen, +- neue Reflection Memories erzeugen, +- Knowledge Deltas vorschlagen. + +--- + +### 20.3 Obsidian + +Obsidian soll weiterhin eine zentrale menschenlesbare Wissens- und Tagebuchbasis darstellen. + +Kanshō soll insbesondere: + +- Tagebucheinträge erzeugen, +- strukturierte Reflexionen ablegen, +- bestehende Inhalte referenzieren, +- kein proprietäres geschlossenes Archiv erzeugen. + +Der genaue Ablage- und Synchronisationsmechanismus ist noch zu bestimmen. + +--- + +### 20.4 Shinkan + +Shinkan kann Kontext liefern, wenn Reflexionen mit Training oder persönlicher Entwicklung im Training zusammenhängen. + +Kanshō übernimmt keine Trainingsplanung. + +--- + +### 20.5 Mitai + +Mitai kann – bei entsprechendem Kontext und Berechtigung – körperliche oder gesundheitsbezogene Informationen liefern. + +Kanshō übernimmt kein Vital-, Ernährungs- oder Gesundheitstracking. + +--- + + +## Querverweis auf Action Candidates + +Die fachliche Definition von `Action Candidate` und die Übergabe aus Reflexionen wird in `reflection_outputs.md` geführt; Kairo bleibt für die Operationalisierung zuständig. diff --git a/docs/architecture/functional/interview_plan.md b/docs/architecture/functional/interview_plan.md new file mode 100644 index 0000000..f023acc --- /dev/null +++ b/docs/architecture/functional/interview_plan.md @@ -0,0 +1,1014 @@ +--- + title: "Kanshō – Interviewplan und Konzeptfortschritt" + status: "Arbeitsstand" + date: "2026-08-18" + product_family: "Jinkendo" + document_role: "Interview Plan / Progress / Definition of Done" + parent_document: "fachliche_zielarchitektur.md" + --- + + # Kanshō – Interviewplan und Konzeptfortschritt + + + +## 4. Kapitelplan und Interviewreihenfolge + +Die folgende Reihenfolge ist nicht identisch mit der späteren Ordnernummerierung. Sie ist danach geordnet, welche Entscheidungen aufeinander aufbauen. + +--- + +## Phase A – Identität und Lebenskontext + +### A1. Produktvision und Produktidentität + +**Status:** weitgehend begonnen + +**Ziel des Interviews:** + +- die bewusst stärker KI-kollaborative Rolle von Kanshō innerhalb der Jinkendo-Familie erhalten und weiter schärfen, +- Produktkern endgültig schärfen, +- Nutzenversprechen definieren, +- Rolle innerhalb Jinkendo abgrenzen, +- Begriffe festlegen. + +**Leitfragen:** + +- Was soll Kanshō langfristig für einen Menschen sein? +- Welche Veränderung soll durch jahrelange Nutzung entstehen? +- Was soll die App ausdrücklich niemals werden? +- Woran erkennt man, dass eine Funktion „zu Kanshō gehört“? +- Was ist der Unterschied zwischen Reflexion, Coaching, Therapie, Journaling und Achtsamkeit innerhalb des Produkts? + +**Zieldateien:** + +- `product_vision.md` +- `product_identity.md` +- `product_principles.md` +- `scope_and_non_goals.md` +- `jinkendo_product_boundaries.md` + +--- + +### A2. Zielnutzer und Nutzung über Jahre + +**Ziel:** + +Nicht nur einzelne User Stories, sondern die langfristige Beziehung zwischen Mensch und Anwendung definieren. + +**Leitfragen:** + +- Ist Kanshō zunächst primär für den Ersteller selbst gedacht oder bereits als generisches Produkt? +- Welche Voraussetzungen muss ein Nutzer mitbringen? +- Wie verändert sich Kanshō nach einem Monat, einem Jahr und zehn Jahren? +- Welche Inhalte sind sehr privat? +- Welche Situationen führen spontan zur Nutzung? +- Welche Situationen führen zu geplanten Reflexionen? + +**Zieldateien:** + +- `target_users.md` +- `usage_situations.md` +- `lifecycle_and_long_term_use.md` + +--- + +## Phase B – Reflection Spaces und Dialog + +### B1. Reflection Contexts, Reflection Spaces und Reflection Intent + +**Ziel:** + +Das zentrale Kontextmodell definieren und klar zwischen dem thematischen Lebenskontext und der aktuellen Nutzungsabsicht unterscheiden. + + +**Zusätzliche fachliche Leitplanken:** + +- Kanshō soll Strukturierungsarbeit weitgehend im Hintergrund übernehmen. +- Nicht jedes Seitenthema wird automatisch zu einem sichtbaren Thread oder Reflection Space. +- Die KI darf Zusammenhänge erkennen und Vorschläge zur Trennung oder Konsolidierung machen. +- Der Grad der KI-Autonomie bei Anlage und Konsolidierung soll konfigurierbar sein. +- Der Nutzer muss falsche Strukturierungen korrigieren können. +- Die konkrete technische Heuristik zur Bewertung von Relevanz, Wiederkehr, Tiefe oder Dauer wird in dieser Phase noch nicht festgelegt. +- Interne Struktur darf deutlich detaillierter sein als die sichtbare Nutzerstruktur. +- Für Entwicklung und Test muss diese interne Struktur in einer berechtigten Diagnoseansicht inspizierbar sein. + + +**Vorläufige sichtbare Baseline eines geöffneten Reflection Space:** + +- **Aktueller Stand** +- **Was ist noch offen?** +- **Weiterdenken** +- **Bisheriger Weg** + +Diese vier Elemente sind ein akzeptierter Ausgangspunkt und dürfen in späteren Dialog- und UX-Kapiteln konkretisiert werden. + +Weitere bereits beschlossene Leitplanken: + +- Reflection Spaces können sowohl über Tage/Wochen als auch langfristig über Monate oder Jahre relevant sein. +- Bedeutung und fortdauernde Relevanz sind wichtiger als eine feste Mindestdauer. +- aktuell nicht relevante Spaces dürfen in der normalen Oberfläche zurücktreten und später wieder hervorgeholt werden. +- verdichtete Aussagen müssen für den Nutzer auf ihre zugrunde liegenden Inhalte aufklappbar sein. +- diese Nutzer-Provenance ist von internem Re-Grounding der KI zu unterscheiden. + +**Leitfragen:** + +- Welche übergeordneten Lebensräume gibt es? +- Welche davon sind stabil? +- Welche entstehen dynamisch? +- Kann ein Erlebnis mehreren Räumen gleichzeitig angehören? +- Wie werden Räume erzeugt, zusammengeführt, beendet oder archiviert? +- Wie unterscheiden sich Kontext, Thema, Projekt, Rolle und Lebensbereich? +- Wie werden Kairo-Objekte und mindnet-Knoten verknüpft? +- Welche Reflection Intents gibt es? +- Welche Intents werden explizit gewählt und welche automatisch erkannt? +- Kann sich der Intent während eines Dialogs ändern? +- Wie beeinflusst der Intent das Verhalten der KI? + +**Zieldateien:** + +- `reflection_contexts.md` +- `reflection_spaces.md` +- `reflection_space_model.md` + +--- + +### B2. Gesprächseinstieg + +**Ziel:** + +Definieren, wie Kanshō einen Dialog beginnt. + +**Bereits entschieden:** + +- Default ist ein kontextbezogener Fortsetzungsvorschlag. +- Kanshō priorisiert einen Hauptvorschlag und zeigt nur wenige Alternativen. +- Der Nutzer kann jederzeit frei sprechen/schreiben oder gezielt navigieren. +- Der Einstieg folgt damit fachlich dem Muster **Contextual Continuation → Free Reflection / Explicit Navigation**. +- Die Startoberfläche soll Kontinuität des Dialogs zeigen und nicht primär ein Funktions-Dashboard sein. + +**Leitfragen:** + +- Öffnet der Nutzer die App ohne konkrete Absicht? +- Kann Kanshō einen Einstieg vorschlagen? +- Welche Informationen darf Kanshō für eine Einstiegsfrage verwenden? +- Wann ist eine frühere offene Frage wichtiger als das aktuelle Tagesgeschehen? +- Wie direkt oder zurückhaltend soll die KI sein? +- Darf Kanshō proaktiv schwierige Themen ansprechen? + +**Zieldateien:** + +- `dialogue_entry.md` +- `home_and_entry_points.md` + +--- + +### B3. Geführte Reflexion + +**Ziel:** + +Die eigentliche Gesprächsmethodik definieren. + +**Leitfragen:** + +- Welche Arten von Fragen stellt Kanshō? +- Wann spiegelt die KI? +- Wann fasst sie zusammen? +- Wann widerspricht sie? +- Wie tief darf sie nachfragen? +- Wie erkennt sie, dass ein Thema noch nicht ausreichend verstanden ist? +- Wie verhindert man mechanische Coaching-Fragen? + +**Zieldateien:** + +- `dialogue_model.md` +- `guided_reflection.md` +- `reflection_model.md` + +--- + +### B4. Dialogfäden und Branching + +**Ziel:** + +Mehrere parallele Denkfäden modellieren. + +**Leitfragen:** + +- Wann entsteht ein Thread? +- Muss der Nutzer ihn sehen? +- Wie erkennt die KI einen neuen Faden? +- Wann schlägt sie eine Trennung vor? +- Wie wird ein Faden geparkt? +- Wann wird ein alter Faden wieder angeboten? +- Wie werden Threads miteinander verbunden? + +**Zieldateien:** + +- `threads_and_branching.md` +- `dialogue_data_model.md` + +--- + +### B5. Abschluss eines Dialogs + +**Ziel:** + +Festlegen, was am Ende einer Reflexion geschieht. + +**Leitfragen:** + +- Muss jeder Dialog einen expliziten Abschluss haben? +- Welche Zusammenfassung sieht der Nutzer? +- Welche Erkenntnisse werden vorgeschlagen? +- Was wird gespeichert? +- Was wird verworfen? +- Was wird an andere Apps übergeben? +- Wann entsteht ein Tagebucheintrag? + +**Zieldateien:** + +- `dialogue_closure.md` +- `reflection_outputs.md` + +--- + +## Phase C – Gedächtnis, Identität und Langzeitbezug + +### C1. Memory Architecture + +**Ziel:** + +Die Gedächtnisebenen endgültig definieren. + +**Leitfragen:** + +- Was gehört in Working Context? +- Was gehört in Thread Memory? +- Was wird episodische Erinnerung? +- Was wird dauerhaftes Wissen? +- Was darf automatisch gespeichert werden? +- Was benötigt Bestätigung? +- Was darf später vergessen werden? + +**Zieldateien:** + +- `memory_architecture.md` +- `working_context.md` +- `thread_memory.md` +- `episodic_memory.md` + +--- + +### C2. Self Model + +**Ziel:** + +Definieren, wie Kanshō stabile persönliche Informationen repräsentiert. + +**Leitfragen:** + +- Was gehört zum Self Model? +- Was sind Werte? +- Was ist Leitbild? +- Was ist Rolle? +- Was ist Eigenschaft? +- Was ist nur momentane Selbstbeschreibung? +- Wie wird eine Hypothese bestätigt? +- Wie werden Widersprüche behandelt? +- Darf sich ein Wert verändern? + +**Zieldateien:** + +- `self_model.md` +- `values_and_inner_alignment.md` +- `identity_and_profile_model.md` + +--- + +### C3. Writing Profile + +**Ziel:** + +Eine persönliche Stimme über Jahre erhalten. + +**Leitfragen:** + +- Welche Texte gelten als authentische Stilreferenz? +- Wie stark soll Kanshō stilistisch imitieren? +- Was darf sprachlich geglättet werden? +- Wie viel Unperfektheit soll bewusst erhalten bleiben? +- Wie erkennt man Stiländerungen im Laufe des Lebens? +- Soll ein Tagebuchtext verschiedene historische Schreibstile respektieren? + +**Zieldateien:** + +- `writing_profile.md` +- `personal_writing_style.md` + +--- + +### C4. Zeit, Erinnerung und Widerspruch + +**Ziel:** + +Verhindern, dass das System vergangene und aktuelle Wahrheiten vermischt. + +**Leitfragen:** + +- Wie wird Zeit an Erinnerungen modelliert? +- Wie unterscheidet Kanshō „damals glaubte ich“ von „heute glaube ich“? +- Was passiert mit falschen Erinnerungen? +- Wie werden Korrekturen propagiert? +- Wie stark verlieren alte Informationen an Gewicht? +- Was bedeutet bewusstes Vergessen? + +**Zieldateien:** + +- `temporal_memory.md` +- `conflicts_forgetting_and_correction.md` +- `versioning_and_provenance.md` + +--- + +### C5. Context Builder + +**Ziel:** + +Definieren, welcher Kontext für eine konkrete LLM-Anfrage zusammengestellt wird. + +**Leitfragen:** + +- Welche Informationsquellen gibt es? +- Welche haben Priorität? +- Wie viel Working Context? +- Welche Erinnerungen? +- Welche Werte? +- Welche offenen Threads? +- Welche Informationen aus Mitai, Shinkan oder Kairo? +- Wie verhindert man Context Pollution? +- Wie wird Unsicherheit transportiert? + +**Zieldatei:** + +- `context_builder.md` + +--- + +## Phase D – Reflexionsintelligenz und Outputs + +### D1. Beobachtung, Interpretation und Hypothese + +**Ziel:** + +Ein erkenntnistheoretisch sauberes Modell schaffen. + +**Leitfragen:** + +- Wie unterscheiden wir Tatsache, Nutzerinterpretation und KI-Hypothese? +- Welche Confidence benötigen unterschiedliche Aussagen? +- Wer darf eine Hypothese bestätigen? +- Wie wird eine Hypothese später verworfen? +- Wie verhindert man scheinbare psychologische Gewissheit? + +**Zieldateien:** + +- `observation_interpretation_hypothesis.md` +- `versioning_and_provenance.md` + +--- + +### D2. Reflection Frontiers + +**Ziel:** + +Offene Bedeutungs- und Erkenntnisräume aus mindnet nutzbar machen. + +**Leitfragen:** + +- Was genau ist ein offenes Ende? +- Wie wird es erkannt? +- Wie wird Relevanz bewertet? +- Wann darf Kanshō es wieder aufgreifen? +- Wie verhindert man obsessives Wiederholen? +- Wann gilt eine Frontier als geschlossen? + +**Zieldatei:** + +- `reflection_frontiers.md` + +--- + +### D3. Muster und Entwicklung + +**Ziel:** + +Langfristige Entwicklung sichtbar machen, ohne vorschnelle Persönlichkeitsdiagnosen. + +**Leitfragen:** + +- Ab wann ist etwas ein Muster? +- Welche zeitliche Mindestbasis braucht es? +- Welche Rolle spielt Nutzerbestätigung? +- Wie werden Gegenbeispiele einbezogen? +- Welche Entwicklungen sollen sichtbar werden? +- Wie präsentiert Kanshō Veränderungen über Jahre? + +**Zieldateien:** + +- `pattern_detection.md` +- `longitudinal_development.md` + +--- + +### D4. Reflection Outputs + +**Ziel:** + +Definieren, welche Artefakte aus einem Dialog entstehen können. + +**Kandidaten:** + +- Journal Entry, +- Reflection Memory, +- Knowledge Delta, +- Action Candidate, +- aktualisierter Thread, +- neue oder geänderte Hypothese. + +**Leitfragen:** + +- Was entsteht automatisch? +- Was benötigt Zustimmung? +- Wo wird was gespeichert? +- Welche Outputs sind sichtbar? +- Welche existieren nur intern? + +**Zieldateien:** + +- `reflection_outputs.md` +- `journal_entries.md` +- `reflection_memories.md` +- `knowledge_deltas.md` +- `action_candidates.md` +- `confirmation_and_human_in_the_loop.md` + +--- + +## Phase E – Journaling, Achtsamkeit und Meditation + +### E1. Journaling + +**Ziel:** + +Das Tagebuch als hochwertigen Bestandteil ausformen, ohne Kanshō darauf zu reduzieren. + +**Leitfragen:** + +- Welche Funktionen des vom Nutzer explizit genannten Referenzrahmens **Day One im „Gold“-Abo** werden benötigt? +- Welche dieser Referenzfunktionen sollen bewusst anders gelöst oder nicht übernommen werden? +- Welche Funktionen sind für Kanshō zusätzlich erforderlich, weil Journaling hier in einen KI-gestützten Reflexionsdialog eingebettet ist? +- Welche Medien? +- Welche Metadaten? +- Welche Timeline? +- Welche Suche? +- Welche Rückblicke? +- Wie wird der aus einer täglichen Reflexion **generierte Tagebucheintrag** erzeugt, bestätigt, bearbeitet und abgelegt? +- Welche weiteren automatisch erzeugten Inhalte? +- Wie viel Nachbearbeitung durch den Nutzer? + +**Zieldateien:** + +- gesamter Ordner `journaling/` + +--- + +### E2. Achtsamkeit + +**Ziel:** + +Ein eigenes Achtsamkeitsverständnis für Kanshō definieren. + +**Leitfragen:** + +- Was bedeutet Achtsamkeit im Produkt? +- Welche Rolle spielt Wahrnehmung? +- Welche Rolle spielt Akzeptanz? +- Welche Rolle spielt Reflexion? +- Was unterscheidet Kanshō von klassischen Mindfulness Apps? +- Welche kurzen situativen Übungen sind sinnvoll? + +**Zieldateien:** + +- `mindfulness_concept.md` +- `contextual_micro_interventions.md` + +--- + +### E3. Meditation + +**Ziel:** + +Meditation funktional und methodisch definieren. + +**Leitfragen:** + +- vorgefertigt oder generiert? +- personalisiert oder allgemein? +- Stimme und Audio? +- Länge? +- aktuelle Lebenssituation als Kontext? +- sichere Grenzen? +- Nachreflexion? +- Historie? + +**Zieldateien:** + +- `meditation_concept.md` +- `guided_meditations.md` +- `post_meditation_reflection.md` + +--- + +## Phase F – Integration und technische Architektur + +### F1. mindnet und Obsidian + +**Ziel:** + +Die langfristige Wissens- und Archivarchitektur festlegen. + +**Leitfragen:** + +- Welche Informationen liest Kanshō aus mindnet? +- Welche schreibt es zurück? +- Was bleibt kanonisch in Obsidian? +- Was bleibt strukturiert in Datenbanken? +- Wie werden IDs und Backlinks erzeugt? +- Welche Edges werden benötigt? +- Wie werden Reflection Frontiers repräsentiert? + +**Zieldateien:** + +- `mindnet_integration.md` +- `obsidian_integration.md` + +--- + +### F2. Kairo, Mitai und Shinkan + +**Ziel:** + +Klare Integrationsverträge statt Funktionsduplikation. + +**Leitfragen:** + +- Welche Daten darf Kanshō lesen? +- Welche Daten darf es schreiben? +- Was wird nur vorgeschlagen? +- Was benötigt Bestätigung? +- Welche Events sind relevant? +- Welche Daten gehören fachlich weiterhin ausschließlich in die Quellanwendung? + +**Zieldateien:** + +- `kairo_integration.md` +- `mitai_integration.md` +- `shinkan_integration.md` +- `integration_principles.md` + +--- + +### F3. AI Architecture + +**Ziel:** + +Die technische Umsetzung der kollaborativen KI definieren. + +**Leitfragen:** + +- ein Modell oder mehrere Rollen? +- Reflection Agent? +- Memory Agent? +- Context Builder? +- Journal Writer? +- Critic/Verifier? +- Model Routing? +- lokale Modelle? +- Cloud Modelle? +- Prompt Registry? +- Evaluation? + +**Zieldateien:** + +- gesamter Ordner `ai_architecture/` + +--- + +### F4. Datenarchitektur + +**Ziel:** + +Kanonische Datenmodelle definieren. + +**Leitfragen:** + +- Conversation +- Message +- Thread +- Reflection Space +- Memory +- Hypothesis +- Insight +- Journal Entry +- Context Reference +- Action Candidate +- Writing Profile +- Self Model + +**Zieldateien:** + +- gesamter Ordner `data_architecture/` + +--- + +## Phase G – Experience, Voice, PWA und Offline + +### G1. Mobile-First Experience + +**Ziel:** + +Die Hauptnutzung auf dem Smartphone definieren. + +**Leitfragen:** + +- Was sieht der Nutzer beim Öffnen? +- Wie schnell kann eine Reflexion beginnen? +- Sprache oder Text? +- Einhandbedienung? +- Wie werden lange Dialoge dargestellt? +- Wie erscheinen frühere Threads? +- Wie vermeidet man Informationsüberladung? + +**Zieldateien:** + +- `experience_principles.md` +- `mobile_first.md` +- `home_and_entry_points.md` +- `conversation_ui.md` + +--- + +### G2. Desktop Experience + +**Ziel:** + +Desktop nicht nur als vergrößerte Mobile UI behandeln. + +**Leitfragen:** + +- Welche Tätigkeiten sind auf Desktop besser? +- Welche Mehrspaltenansichten? +- Journal und Dialog nebeneinander? +- Recherche in alten Reflexionen? +- Mindnet-Verbindungen? + +**Zieldatei:** + +- `desktop_experience.md` + +--- + +### G3. Sprache und Transkription + +**Ziel:** + +Voice als primäre mobile Interaktion prüfen. + +**Leitfragen:** + +- Push-to-talk? +- kontinuierliche Aufnahme? +- Live-Transkription? +- Audio speichern oder nach Transkription löschen? +- Korrektur vor Übergabe? +- offline? +- Unterbrechungen? +- Mischform Text + Sprache? + +**Zieldateien:** + +- gesamter Ordner `voice_and_media/` + +--- + +### G4. PWA und Offline + +**Ziel:** + +Festlegen, was ohne Netz noch funktioniert. + +**Leitfragen:** + +- lokale Journaleinträge? +- lokale Dialoge? +- lokale Transkription? +- lokale kleine Modelle? +- Sync Queue? +- Verschlüsselung? +- Konfliktauflösung? +- Installation auf iOS/Android/Desktop? + +**Zieldateien:** + +- gesamter Ordner `pwa_and_offline/` + +--- + +## Phase H – Datenschutz, Sicherheit und Vertrauen + +### H1. Privacy by Design + +**Ziel:** + +Besonders sensible persönliche Langzeitdaten schützen. + +**Leitfragen:** + +- Welche Daten sind besonders kritisch? +- Verschlüsselung at rest und in transit? +- lokale Speicherung? +- Cloud Verarbeitung? +- Export? +- vollständiges Löschen? +- selektives Vergessen? +- Zugriff anderer Jinkendo-Apps? + +**Zieldateien:** + +- `privacy_principles.md` +- `sensitive_personal_data.md` +- `encryption_and_access.md` +- `export_delete_and_portability.md` + +--- + +### H2. Memory Transparency + +**Ziel:** + +Der Nutzer muss verstehen und kontrollieren können, was Kanshō über ihn „weiß“. + +**Leitfragen:** + +- Kann man gespeicherte Memories ansehen? +- Quelle anzeigen? +- Confidence? +- korrigieren? +- löschen? +- Herleitung anzeigen? +- Self Model editieren? + +**Zieldatei:** + +- `memory_transparency.md` + +--- + +### H3. Safety Boundaries + +**Ziel:** + +Grenzen bei psychisch belastenden, medizinischen oder anderweitig hochriskanten Themen definieren. + +**Zieldateien:** + +- `ai_safety_boundaries.md` +- `crisis_and_high_risk_scenarios.md` +- `conversation_safety_and_boundaries.md` + +--- + +## Phase I – MVP und Delivery + +### I1. MVP-Schnitt + +**Ziel:** + +Nach vollständiger fachlicher Konzeption eine erste vertikale Produktversion definieren. + +Wichtig: + +Der MVP soll nicht dadurch entstehen, dass beliebige Features gestrichen werden. Er soll eine **vollständige kleine Reflexionsschleife** ermöglichen. + +Eine mögliche spätere vertikale Scheibe könnte sein: + +1. Reflexionsraum auswählen oder erkennen, +2. kontextbezogenes Gespräch starten, +3. Dialog führen, +4. Thread Memory erzeugen, +5. Tagebucheintrag generieren, +6. Nutzer bestätigt, +7. Eintrag nach Obsidian überführen, +8. Reflection Memory in mindnet schreiben. + +Dies ist noch keine endgültige MVP-Entscheidung. + +**Zieldateien:** + +- gesamter Ordner `product_delivery/` + +--- + +## Phase J – Research und Benchmarking + +Diese Phase kann parallel zu den anderen Phasen laufen. + +Zu untersuchen sind insbesondere: + +- Day One, +- KI-Journaling-Produkte, +- Reflection Apps, +- Mindfulness Apps, +- Meditation Apps, +- Personal Memory Systeme, +- Long-Term-Memory-Architekturen, +- Voice Journaling, +- Privacy Patterns, +- Personal AI. + +**Zieldateien:** + +- gesamter Ordner `research/` + +--- + +## 5. Empfohlene Reihenfolge des weiteren Interviews + +Die unmittelbar nächste Sequenz sollte lauten: + +1. **Reflection Spaces** — fachliche Baseline abgeschlossen, spätere Konkretisierung möglich +2. **typische Nutzungssituationen** — nächster Interviewblock +3. **Gesprächseinstieg** +4. **Dialogmethodik** +5. **Threads und Branching** +6. **Dialogabschluss und Outputs** +7. **Memory Architecture** +8. **Self Model** +9. **Writing Profile** +10. **Context Builder** +11. **Reflection Frontiers** +12. **Journaling** +13. **Achtsamkeit** +14. **Meditation** +15. **Integrationen** +16. **AI Architecture** +17. **Mobile UX / Voice** +18. **Offline** +19. **Privacy / Safety** +20. **MVP** + +Diese Reihenfolge verhindert, dass technische Entscheidungen zu früh getroffen werden, bevor klar ist, welches Verhalten das Produkt tatsächlich benötigt. + +--- + +## 6. Interviewmethode + +Für jedes Kapitel wird derselbe Arbeitsmodus empfohlen. + +### Schritt 1 – Ausgangshypothese + +Auf Basis der bisherigen Entscheidungen wird eine erste strukturierte Hypothese formuliert. + +### Schritt 2 – gezielte Fragen + +Es werden nur Fragen gestellt, die echte Produktentscheidungen verändern können. + +### Schritt 3 – Szenarien + +Die Entscheidung wird anhand konkreter Situationen geprüft. + +### Schritt 4 – Gegenbeispiele und Grenzfälle + +Bewusst problematische oder widersprüchliche Situationen werden getestet. + +Zusätzlich wird bei strukturellen Vereinfachungen ein **Capability-Check** durchgeführt, damit keine bereits vorgesehenen Kernfähigkeiten unbeabsichtigt verloren gehen. + + +### Schritt 5 – Entscheidung + +Ergebnis wird klassifiziert als: + +- entschieden, +- bevorzugte Richtung, +- Hypothese, +- offen, +- verworfen. + +### Schritt 6 – Dokumentation + +Das betreffende Kapitel wird als eigene Datei aktualisiert. + +--- + +## 7. Definition of Done für ein Konzeptkapitel + +Ein Kapitel gilt konzeptionell als ausreichend bearbeitet, wenn mindestens folgende Punkte beantwortet sind: + +- Zweck, +- Begriffe, +- fachliche Verantwortung, +- zentrale Regeln, +- Nutzerinteraktion, +- Daten-/Informationsbedarf, +- Schnittstellen zu anderen Bereichen, +- Edge Cases, +- offene Punkte, +- getroffene Entscheidungen, +- bewusste Nicht-Ziele. + +Technische Kapitel erhalten zusätzlich: + +- Datenmodell, +- API-/Event-Bedarf, +- Persistenz, +- Fehlerfälle, +- Security-/Privacy-Auswirkungen, +- Offline-Auswirkungen, +- Testbarkeit. + +--- + +## 8. Aktueller Fortschrittsstatus + +| Themenbereich | Status | +|---|---| +| Produktvision | weitgehend geklärt; spätere Präzisierungen möglich | +| Produktidentität | weitgehend entschieden | +| Produktgrenzen zu Jinkendo | weitgehend entschieden | +| Reflection Spaces | fachliche Baseline vorläufig ausreichend geklärt; spätere Konkretisierung aus Dialog-, UX- und Memory-Kapiteln vorgesehen | +| Nutzungssituationen | Typologie mit elf Situationen als vorläufig vollständige Baseline festgelegt | +| Erleben festhalten | vorläufig ausreichend geklärt | +| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage und Resurfacing weitgehend geklärt | +| Dialogmodell | wesentliche Baseline vorhanden; weitere Nutzungssituationen noch auszuarbeiten | +| Threads | Grundmodell vorhanden; technisches State Model bewusst offen | +| Thread Resurfacing | querschnittliches Fachkonzept entschieden | +| Reflection Saturation | querschnittliches Fachkonzept entschieden; konkrete technische Berechnung später | +| Memory Architecture | erstes Schichtenmodell vorhanden | +| Context Fidelity / Re-Grounding | Root Cause und fachliche Invariante entschieden | +| mindnet-Rolle | Grundrichtung vorhanden | +| Self Model | erste verbindliche Prinzipien vorhanden | +| Lived Experience / Point-in-Time Self | als zusätzliche Ebene des digitalen Zwillings entschieden | +| Writing Profile | erste Prinzipien vorhanden | +| Reflection Frontiers | Konzeptidee vorhanden | +| Journaling | Kernanforderungen und zweistufige Generierung vorhanden | +| Meditation | nur grob | +| Achtsamkeit | nur grob | +| UX | fachliche Leitplanken vorhanden; Detailkonzept offen | +| Voice/Transkription | Anforderung vorhanden | +| Offline | Anforderung vorhanden | +| Integrationen | Produktgrenzen vorhanden, technische Verträge offen | +| Guardrails / Privacy Gateway | fachliche Baseline angelegt; Pseudonymisierung, lokale Identität und External-AI-Egress als Invarianten entschieden | +| AI Architecture | offen | +| Data Architecture | offen | +| Security / Privacy Detailarchitektur | offen; Guardrail-Baseline vorhanden | +| MVP | offen | + +--- + +## 9. Nächster Interviewblock + +Aktiv ist weiterhin die Nutzungssituation **2. Tagesreflexion**. + +Bereits geklärt sind insbesondere: + +- der Einstieg mit einem intelligent priorisierten Hauptimpuls, +- wenige sichtbare Alternativen plus explizit aufrufbarer Themenkatalog, +- Vorrang der aktuellen Nutzerintention, +- grundsätzlich aktueller Tag vor älteren Threads, +- ältere Themen nur bei expliziter Fortsetzung oder erkennbarem aktuellem Bezug, +- adaptive Anpassung an persönlichen Denk-, Antwort- und Reflexionsstil, +- Vermeidung flacher und repetitiver Fragen, +- explizite Wiedervorlage für später / morgen / nächsten passenden Kontext, +- Thread Resurfacing als querschnittliches Konzept, +- Reflection Saturation als Erkennung von möglicher Abschlussreife, +- der Nutzer behält das letzte Wort über Weiterführen, Vertiefung, Wiedervorlage und Abschluss. + +### Als Nächstes: Abschluss und Outputs der Tagesreflexion + +Noch fachlich zu entscheiden beziehungsweise zu bestätigen sind insbesondere: + +1. Welche sichtbaren Ergebnisse entstehen standardmäßig am Ende einer Tagesreflexion? +2. Welche internen Outputs entstehen immer, welche nur bei Relevanz? +3. Wie verhalten sich Session Output, Journal Entry, Reflection Memory, Knowledge Delta und Action Candidate zueinander? +4. Soll die Trennung **`Session Lifecycle ≠ Thread Lifecycle`** als verbindliche Architekturregel übernommen werden? +5. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt? + +Nach vorläufigem Abschluss der Tagesreflexion folgt: + +### Nutzungssituation 3 – Spontaner Gedanke / Moment + +Danach werden die verbleibenden Nutzungssituationen schrittweise nach derselben Interviewmethode ausgearbeitet. + +## Migrationshinweis + +Dieses Dokument ist seit der Dokumentenaufteilung das kanonische Home für Interviewreihenfolge, Interviewmethode, Definition of Done und Fortschrittsstatus. Inhaltliche Aktualisierungen erfolgen künftig hier. diff --git a/docs/architecture/functional/manifest.json b/docs/architecture/functional/manifest.json new file mode 100644 index 0000000..dfe9045 --- /dev/null +++ b/docs/architecture/functional/manifest.json @@ -0,0 +1,125 @@ +{ + "generated": "2026-08-18", + "files": [ + { + "file": "context_fidelity_and_regrounding.md", + "bytes": 10578, + "lines": 228, + "sha256": "befab673fce876d916698c3627c1aeff507044045fa54e09950e104554945ac0" + }, + { + "file": "dialogue_model.md", + "bytes": 8894, + "lines": 230, + "sha256": "e7117b411f23c141756020a33eb3991344ba3c7751547642dca1c070d8f042b3" + }, + { + "file": "documentation_index.md", + "bytes": 3083, + "lines": 82, + "sha256": "0075d73bd4eceb5abe435208c76919d0c518c28971e6512c17523ab4874a8cb5" + }, + { + "file": "fachliche_zielarchitektur.md", + "bytes": 11310, + "lines": 268, + "sha256": "86a002ec71f98c422c8c39815ad168b0de89a4e8cbdcae67fbf04c50a220ad0b" + }, + { + "file": "guardrails.md", + "bytes": 24882, + "lines": 719, + "sha256": "c2686cfb2954e33b0f9a812e56d7c78434083c8d227b59e3d61635d6f58ff260" + }, + { + "file": "integrations.md", + "bytes": 5222, + "lines": 184, + "sha256": "40921765f383d86734c59b34b8fb6d0ee229362f4c31fbba7413d8465e025b27" + }, + { + "file": "interview_plan.md", + "bytes": 25791, + "lines": 1014, + "sha256": "430eac10284061dd8a48e579d38d753d816eaa3cd23f1c65d54461fc174190ce" + }, + { + "file": "memory_and_context.md", + "bytes": 4080, + "lines": 140, + "sha256": "d8b0b01380b2bdba44d10e8eab7cb07ec8656c9e5fc8b465c7f3a1c34c1fcfe6" + }, + { + "file": "migration_mapping.md", + "bytes": 5656, + "lines": 75, + "sha256": "c1a1887cef9383221bf80bfd1b35232acb1cfce391043f5e7788c5d07edc1dda" + }, + { + "file": "produktvision_und_produktidentitaet.md", + "bytes": 22403, + "lines": 514, + "sha256": "e1367c0388a32e54c2ee5c0dd8e0bd940cbd057d2d7793c97f1592e4e30bdfd8" + }, + { + "file": "reflection_intelligence.md", + "bytes": 2564, + "lines": 72, + "sha256": "f840eed92dcc29395e980eb547caef6baa3b0645311482230ecb198a40beedca" + }, + { + "file": "reflection_outputs.md", + "bytes": 2712, + "lines": 99, + "sha256": "63520b1642b239dc43c52ef4fcf7c7a041b309db9688426b287effc0f25cef55" + }, + { + "file": "reflection_spaces.md", + "bytes": 10307, + "lines": 224, + "sha256": "c81feaa50df70c96e87f7ad4a65c0b2df36c6df13a258f1de072f2664e84f779" + }, + { + "file": "resurfacing_and_saturation.md", + "bytes": 7236, + "lines": 175, + "sha256": "555df7855c498bb136d6012b2fae5584897641f20a1d7455e8a037099b967d9e" + }, + { + "file": "self_model_and_lived_experience.md", + "bytes": 9859, + "lines": 247, + "sha256": "5df74eb5c3ab6d98c250c3b339aed0bf5da26c394d3704b72ecf0d63c3f552ec" + }, + { + "file": "usage_situations.md", + "bytes": 25559, + "lines": 706, + "sha256": "485fe3a8848d4ef0892614998c48cc311f23bd9624fbb24e69d93770c424a26d" + }, + { + "file": "writing_profile_and_journaling.md", + "bytes": 3488, + "lines": 103, + "sha256": "e043c1d212de249127ba4b8e41bb58e846aab27c92f165e2e032b00ec65712ee" + } + ], + "source_checkpoint": { + "fachliche_zielarchitektur.md": { + "sha256": "711317032724e46ac545d213b6e246f962662a547731ec7949dc61d146d59fb6", + "bytes": 51488 + }, + "produktvision_und_produktidentitaet.md": { + "sha256": "f46358a730ac46eb817cb61a3afa7d0dfb83f4cfffd04484332939826300d216", + "bytes": 63647 + }, + "usage_situations.md": { + "sha256": "92007021fdd6feccdf2db3bf534f2c3909f971d2a6036e43d03cc2ac90154d34", + "bytes": 24883 + }, + "guardrails.md": { + "sha256": "8f4732f0ab309c551740c0135ca9cc92a8032323e5becf81adb1845d8e292dde", + "bytes": 22198 + } + } +} \ No newline at end of file