Kansho/docs/architecture/technical/ai_architecture.md

title	version	status	date	product_family	document_role	parent_document
Kanshō – AI-Architektur	0.1	Arbeitsstand	2026-08-19	Jinkendo	Technical Chapter / AI Architecture	technische_zielarchitektur.md

Kanshō – AI-Architektur

Kanonisches Home für Inferenzpfad und spätere Agenten. Prompt-Engine und Registries: platform_extensibility.md. Egress und Datenklassen: privacy_gateway.md.

1. Rolle der KI

Kanshō ist bewusst stärker KI-kollaborativ als bisherige Jinkendo-Komponenten. Die KI ist Dialogpartner, nicht nur Feature.

Sie darf Zusammenhänge als Hypothese anbieten, keine künstliche Gewissheit und keinen erfundenen Wesenskern. Journalstil folgt dem Writing Profile; Inhalt und Stil sind getrennt zu erzeugen (fachlich bevorzugte Richtung).

2. Laufzeit

Thema	Stand	Status
Externe Inferenz für leistungsfähige Dialoge	vorgesehen	entschieden
Lokale große Modelle als alleinige Basis	derzeit nein	entschieden
Privacy Gateway vor persönlichem Egress	zwingend	entschieden
OpenRouter	möglicher Router	kein Zwang
Lokale kleine Modelle / Fallback	möglich	offen

Kein Router, kein Frontend und kein Prompt-String umgeht privacy_gateway.md.

3. Engine und Registries

Verbindlich gemäß platform_extensibility.md:

• ein Executor (base / pipeline / workflow)
• Prompts in der DB, Admin-CRUD, Preview, Import/Export
• Kontext-Platzhalter {{key}} ≠ Privacy-Platzhalter [[SELF]]
• LLM nur als Gateway-Callback

Fachliche Reflexions- oder Journal-Prompts sind Konfiguration, die später registriert wird – nicht Code und nicht der heutige Fachstand als fest verdrahtete Texte.

4. Agentenrollen

Interview F3 listet Reflection Agent, Memory Agent, Context Builder, Journal Writer, Critic/Verifier, Routing, Evaluation.

Status: offen. Es wird in v0.1 kein Agentengraph festgeschrieben.

Technische Mindestanforderung unabhängig von der späteren Zerlegung:

• Context Builder (wann immer er existiert) erzeugt Internal Context.
• Gateway erzeugt External Model Context.
• Antworten werden validiert und demaskiert, bevor sie lokal weiterverwendet werden.
• Untrusted Modellausgabe, die als Inhaltsquelle für eine Folgestufe dienen soll, durchläuft die lokale Provenienzprüfung (provenance_verification.md). Das gilt unabhängig vom späteren Intent; die konkrete Coverage-Policy setzt der jeweilige Adapter.
• Der aktuelle Fachstand zur Strukturierungsautonomie ändert weder Egress-Klasse noch Nutzerhoheit über Identität.

5. Context-Fenster

Der heutige Fachstand geht davon aus, dass ein LLM-Kontextfenster nicht ausreicht (memory_and_context.md). Orchestrierung von Ausschnitten und Re-Grounding bleibt an diesen Stand gekoppelt, ist aber kein vorgezogenes Speicherschema.

Journalgenerierung (2026-08-25): Für den expliziten Journalentwurf gibt es ein lokales Budgetmodell (mvp_implementation.md §16, privacy_gateway.md §9.3): Mindestfenster 32K, Output-Reserve, Sicherheitsmarge, konservative Zeichenschätzung, kein stilles Middle-Out. Das ist keine globale Token-Orchestrierung für Dialog, Memory oder Resurfacing.

Resurfacing und Saturation (aktueller Fachstand) steuern Relevanz, nicht die Egress-Menge. Guardrails bleiben vorrangig.

6. Safety

Krisen- und Hochrisiko-Grenzen sind fachlich Phase H3 und offen. Technisch v0.1: keine psychiatrische Diagnose, keine stillschweigenden Persönlichkeitsprofile. Konkrete Blocklisten und Eskalations-UX später.

7. Entscheidungsstand

Thema	Stand	Status
Extern + Gateway	ja	entschieden
Ein Executor / Gateway-Callback	ja	entschieden
Konkrete Prompt-Bibliothek	später als Config	offen
Multi-Agent-Zerlegung	–	offen
Modellwahl und Routing-Policy-Datei	–	offen
Prompt-Admin (CRUD/Preview/Export)	Mitai-Engine-Muster	entschieden
Evaluation / Qualitätsmetriken	–	offen

8. Offene Fragen

Siehe Interview F3. Zusätzlich: Wie wird das Writing Profile in die Journal-Pipeline injiziert, ohne Klasse-A-Identität zu leaken?

9. Querverweise

• Fachlich: ../functional/guardrails.md, ../functional/reflection_intelligence.md, ../functional/writing_profile_and_journaling.md
• Technisch: platform_extensibility.md, privacy_gateway.md, admin_diagnostics.md, provenance_verification.md