---
title: "Kanshō – AI-Architektur"
version: "0.1"
status: "Arbeitsstand"
date: "2026-08-19"
product_family: "Jinkendo"
document_role: "Technical Chapter / AI Architecture"
parent_document: "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.
- 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. Algorithmen und Token-Budgets: offen.

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`