mindnet/docs/01_User_Manual/01_knowledge_design.md

doc_type	audience	scope	status	version	context
user_manual	user, author	vault, markdown, schema, agentic_validation, note_scope, section_types, intra_note_edges	active	4.6.0	Regelwerk für das Erstellen von Notizen im Vault. Die 'Source of Truth' für Autoren. Inkludiert WP-24c Phase 3 Agentic Edge Validation, automatische Spiegelkanten, Note-Scope Zonen und WP-26 Section Types mit Intra-Note-Edges.

Knowledge Design Manual

Quellen: knowledge_design.md, types.yaml

⚡ Die 6 Goldenen Regeln (TL;DR)

1. Atomare Gedanken: Eine Notiz = Ein Thema. Vermischung führt zu "Context-Pollution", wodurch die KI unpräzise berät.
2. Explizite Typen: Der type im Frontmatter ist der wichtigste Hebel. Er entscheidet über die mathematische Gewichtung im System.
3. Semantische Links: Nutze das Vokabular aus der 01_edge_vocabulary.md. Ersetze einfache Verweise durch funktionale Beziehungen wie caused_by oder based_on.
4. Werte & Ziele definieren: Ohne explizite Kriterien (type: value) fehlt dem System der Maßstab für eine Bewertung.
5. Emotionales Bridging: Dokumentiere deine Gefühle. Begriffe wie „Druck“ oder „Euphorie“ sind die Schnittstelle für die Empathie-Logik.
6. Narrative Tiefe (Fleisch am Knochen): Ein „Was“ ohne „Warum“ ist für die KI nur ein Fakt, für dich als Mensch aber bedeutungslos. Dokumentiere die Intention hinter deinen Taten.

---

1. Zweck & Scope

Mindnet ist mehr als eine Dokumentablage. Es ist ein vernetztes System, das deine Persönlichkeit abbildet. Die Markdown-Dateien in deinem Vault sind die einzige Quelle der Wahrheit ("Source of Truth"). Was nicht im Markdown steht, existiert für das System nicht.

---

2. Note-Struktur & Frontmatter

Jede Notiz benötigt einen YAML-Header (Frontmatter).

Pflichtfelder:

---
id: 20251212-projekt-alpha     # Eindeutige Kennung (YYYYMMDD-slug empfohlen)
title: Projekt Alpha           # Sprechender Titel
type: project                  # Steuert Chunking & Wichtigkeit
status: active                 # active, archived, draft
created: 2025-12-12            # ISO 8601
tags: [ki, entwicklung]        # Taxonomie
aliases: [KI Projekt, Codename Quickhack]
---

2.1 [NEU] Naming Convention: Intuitiv vs. Technisch

Für die Benutzerfreundlichkeit und die intuitive Navigation in Obsidian wird die Nutzung von menschenlesbaren Titeln bevorzugt (z. B. Mein Persönliches Leitbild 2025 statt leitbild_identity).

• Die technische Eindeutigkeit wird primär über die id im Frontmatter sichergestellt.
• Die KI nutzt die Semantik des Dateinamens als zusätzlichen Kontext-Vektor.

2.2 Advanced Overrides: Die KI-Steuerung übernehmen

In 95% der Fälle setzt der type (z.B. "concept") automatisch die richtigen Einstellungen. In Spezialfällen kannst du diese manuell im Frontmatter überschreiben, um das Verhalten der KI zu erzwingen.

A. retriever_weight: Die Sichtbarkeit steuern

Dieser Faktor (Default: 1.0) ist ein Multiplikator für das Ranking in der Vektorsuche. Er entscheidet, welche Notiz "gewinnt", wenn zwei Texte inhaltlich ähnlich sind.

• Standard (1.0): Normale Wichtigkeit.
• Boost (1.2 - 2.0): "Das hier ist die Wahrheit."
  • Einsatz: Finale Entscheidungen, Kernprinzipien, die "Single Source of Truth".
  • Effekt: Verdrängt weniger wichtige Notizen (z.B. Meeting-Protokolle) aus dem Kontext-Fenster der KI.
• Deboost (0.5 - 0.8): "Nur Kontext, keine Fakten."
  • Einsatz: Glossare, externe Quellen (source), reine Datensammlungen.
  • Effekt: Die Notiz wird nur gefunden, wenn man sehr spezifisch danach sucht.

B. chunking_profile: Die Zerstückelung steuern

Das Profil bestimmt, wie der Text für die Datenbank zerschnitten wird. Falsches Chunking zerreißt den Kontext. Wähle das Profil basierend auf der Struktur deines Textes.

Profil-Name	Strategie	Einsatzzweck & Wirkung
sliding_standard	Sliding Window	Der Allrounder. Für Fließtexte (Tagebuch, Artikel). Der Text wird in überlappende Fenster geschnitten. Gut, wenn der Inhalt von oben nach unten fließt.
sliding_short	Sliding Window (Klein)	Für Dichte. Für Texte mit sehr hoher Informationsdichte (Glossare, Task-Listen), wo jeder Satz wichtig ist. Erzeugt viele kleine Chunks.
sliding_smart_edges	Sliding + AI	Der Intelligente. Wie Standard, aber das LLM analysiert jeden Chunk zusätzlich auf implizite Querverweise. Standard für concept und project.
structured_smart_edges	Heading Split (Soft)	Für Strukturierte Texte. Trennt an Überschriften (H2). Besonderheit: Wenn ein Abschnitt sehr kurz ist, wird er mit dem nächsten verschmolzen ("Soft Mode"), um den Kontext zu wahren.
structured_smart_edges_strict	Heading Split (Hard)	Für Listen & Kataloge. Trennt zwingend an jeder H2-Überschrift. Verhindert das Verschmelzen. Wichtig für: decision (Option A darf nicht mit Option B verschmelzen), value, profile.

Beispiel für ein Override:

---
title: Sammlung meiner Passwörter-Regeln
type: list
# Wir erzwingen eine strikte Trennung, damit Regel 1 nicht mit Regel 2 vermischt wird.
chunking_profile: structured_smart_edges_strict
# Extrem wichtig, soll immer beachtet werden.
retriever_weight: 1.5
---

---

3. Frontmatter Felder und ihre Bedeutung

3.1 Typ-Referenz & Stream-Logik

Das System euriert Informationen in funktionalen Streams. Wähle den Typ danach aus, in welchem "Gedächtnis-Bereich" die Information landen soll.

3.1 Identity Stream (Der Kern / Das „Warum“)

Dieser Stream definiert deine stabilen Merkmale und inneren Kompasse.

Typ	Gewicht	Chunking Profil	Zweck & Inhalt
value	1.00	structured_strict	Fundamentale Werte und moralische Maßstäbe.
principle	0.95	structured_strict_L3	Handlungsleitlinien mit tiefer Hierarchie (H3-Split).
trait	1.10	structured_strict	Charakterliche Stärken und Talente.
belief	0.90	sliding_short	Tiefe Überzeugungen über dich und die Gesellschaft.
profile	0.70	structured_strict	Rollenidentitäten (z. B. Vater, Mentor, Unternehmer).
need	1.05	sliding_smart_edges	Psychologische Grundbedürfnisse (z. B. Autonomie, Bindung).
motivation	0.95	sliding_smart_edges	Innere Antreiber und Quellen deiner Energie.
boundary	0.90	sliding_smart_edges	Deine persönlichen Grenzen und Integritäts-Leitplanken.
bias	0.80	sliding_short	Bekannte kognitive Verzerrungen und Denkfallen.

3.1.2 Action Stream (Die Dynamik / Das „Was“)

Dieser Stream umfasst alles, was auf Umsetzung, Planung und aktuelle Zustände zielt.

Typ	Gewicht	Chunking Profil	Zweck & Inhalt
project	0.97	sliding_smart_edges	Aktive Vorhaben mit Mission und Zielsetzung.
goal	0.95	sliding_smart_edges	Strategische Nordsterne und Zielzustände.
decision	1.00	structured_strict	Getroffene Entscheidungen (ADR-Logik).
risk	0.85	sliding_short	Potenzielle Gefahren und Bedrohungsszenarien.
obstacle	1.00	structured_strict	Aktuelle Hürden, Ängste und Blockaden.
task	0.80	sliding_short	Operative Aufgaben und Definition of Done.
skill	0.90	sliding_smart_edges	Fertigkeiten, Lernpfade und Meisterschaft.
habit	0.85	sliding_short	Routinen, Automatismen und Verhaltensmuster.
idea	0.70	sliding_short	Flüchtige Einfälle und Rohmaterial für Projekte.
state	0.60	sliding_short	Momentane Verfassung, Stimmung und Energielevel.

3.1.3 History & Basis Stream (Die Evidenz / Das „Wann“)

Dieser Stream speichert deine Erlebnisse, Fakten und externes Wissen als Belege.

Typ	Gewicht	Chunking Profil	Zweck & Inhalt
insight	1.20	sliding_smart_edges	Hochrelevante Erkenntnisse und Verhaltensmuster.
experience	1.10	sliding_smart_edges	Biografische Lektionen und prägende Erlebnisse.
event	0.60	sliding_standard	Chronologische Protokolle und Ereignisse.
journal	0.80	sliding_standard	Tägliche Logs und ungefilterte Gedanken.
person	0.50	sliding_standard	Kontaktprofile und soziale Vernetzung.
source	0.50	sliding_standard	Externe Quellen wie Bücher, Videos oder Artikel.
concept	0.60	sliding_smart_edges	Fachbegriffe, Theorien und zeitloses Wissen.
glossary	0.40	sliding_short	Kurze Begriffsdefinitionen.
default	1.00	sliding_standard	Fallback für alle nicht klassifizierten Notizen.

3.2 Status und Bedeutung

Status	Bedeutung	Auswirkung auf die KI
stable	Geprüftes Wissen. Die Notiz ist inhaltlich korrekt, finalisiert und verlässlich (Gold-Standard).	🚀 Bevorzugt (Bonus): Die KI vertraut diesen Inhalten mehr (+20% Relevanz-Score). Bei widersprüchlichen Infos gewinnt stable.
active	Standard. Aktuelle Arbeitsnotizen, Projekte oder Dokumentationen (Default, wenn leer).	🔵 Neutral: Standard-Gewichtung (Faktor 1.0).
draft	Entwurf. Brainstorming, unstrukturierte Mitschriften oder rohe Ideen.	🔻 Gedämpft (Malus): Die KI nutzt diese Infos nur, wenn es keine besseren Treffer gibt (Relevanz auf 50% reduziert). Reduziert "Rauschen" in den Antworten.
system	Intern. Konfigurationsdateien, technische Logs oder Admin-Skripte.	❌ Ignoriert (Hard Skip): Die Datei wird nicht in den Suchindex aufgenommen und ist für den Chat unsichtbar.
template	Vorlage. Leere Gerüste für neue Notizen (z.B. für Obsidian).	❌ Ignoriert (Hard Skip): Verhindert, dass leere Vorlagen als Suchergebnisse auftauchen.

Wann nutze ich welchen Status?

1. Ideenfindung: Setzen Sie neue Ideen immer auf draft. So können Sie frei schreiben, ohne dass die KI sofort "Halbwissen" als Fakten verkauft.
2. Finalisierung: Sobald eine Entscheidung getroffen oder ein Konzept fertig ist, ändern Sie den Status auf stable.
3. Konfiguration: Nutzen Sie system für Dateien wie die 01_edge_vocabulary.md, damit die KI nicht die Definition der Kanten zitiert, wenn Sie eigentlich nach Inhalten suchen.

3.3 Aliases (Synonyme & Verlinkung)

Nutze aliases: [Synonym] für:

1. Flüssiges Schreiben: [[RAG]] statt [[Retrieval Augmented Generation]].
2. Semantische Anker: Der Chat findet die Notiz auch über den Alias-Begriff.

Das optionale Feld aliases erlaubt es dir, einer Notiz alternative Titel oder Synonyme zu geben. Dies ist ein mächtiges Werkzeug für die Usability und die Suche.

---
title: Leitbild – Handlungsprinzipien
aliases: [Prinzipien, Handlungsleitlinien, Entscheidungsprinzipien]
---

**Best Practices für Aliases**

Damit dein System sauber bleibt, beachte diese Regeln:

* ✅ **Akronyme & Abkürzungen:**
    Nutze Aliases für technische Kürzel.
    * *Note:* `Retrieval Augmented Generation`
    * *Alias:* `[RAG, RAG-Architektur]`
    * *Vorteil:* Du tippst im Fließtext nur `[[RAG]]` und bist fertig.

* ✅ **Projekt-Codenamen:**
    Verbinde den offiziellen Titel mit dem Flur-Namen.
    * *Note:* `Projekt Phoenix – Cloud Migration`
    * *Alias:* `[Phoenix, Cloud-Projekt]`

* ❌ **Vermeide generische Begriffe (Namespace Pollution):**
    Gib einer spezifischen Notiz niemals einen Alias, der ein allgemeines Wort ist.
    * *Schlecht:* Alias `[Meeting]` für `2025-10-JourFixe`.
    * *Folge:* Jedes Mal, wenn du das Wort "Meeting" tippst, schlägt Obsidian dir diesen einen alten Jour Fixe vor. Das zerstört den Schreibfluss.

* ❌ **Keine Plural-Wahn:**
    Mindnet und Obsidian finden meist auch den Plural (Fuzzy Search). Du musst nicht `[Prinzip, Prinzipien, Prinzips]` anlegen. Ein Stammbegriff reicht oft.

---

## 4. Section Types & Intra-Note-Edges (WP-26) [NEU]

### 4.0 Übersicht: Section Types

**Section Types** ermöglichen es, innerhalb einer Note unterschiedliche Typen für verschiedene Abschnitte zu definieren. Dies erlaubt präzisere semantische Verarbeitung und Intra-Note-Verbindungen zwischen Chunks.

**Kernkonzept:**
- Eine Note hat einen **Note-Type** (im Frontmatter: `type: experience`)
- Abschnitte innerhalb der Note können einen eigenen **Section-Type** haben (z.B. `insight`, `decision`)
- Der **effektive Typ** eines Chunks ist: `section_type` falls vorhanden, sonst `note_type`
- Section Types ermöglichen **Intra-Note-Edges** – semantische Verbindungen zwischen Chunks derselben Note

### 4.0.1 Section-Type-Deklaration

**Syntax:**
```markdown
## Überschrift ^block-id
> [!section] type-name

Beispiel:

---
type: experience
title: Konflikt im Team-Meeting
---

# Konflikt im Team-Meeting

## Situation ^sit
> [!section] experience

Am 15. Januar kam es zu einer Eskalation...

## Reflexion ^ref
> [!section] insight

Diese Erfahrung zeigt mir, dass...

## Nächste Schritte ^next
> [!section] decision

Ich werde in Zukunft früher eingreifen.

Regeln:

• Der Section-Type gilt ab der Überschrift bis zur nächsten Überschrift gleicher oder höherer Ebene
• Das [!section]-Callout kann an beliebiger Stelle innerhalb des Abschnitts stehen (muss nicht direkt unter der Überschrift sein)
• Das [!section]-Callout ist unabhängig von [!edge]-Callouts und kann separat platziert werden
• Bei Fehlen eines [!section]-Callouts gilt der Note-Type als Fallback
• Valide Section-Types müssen in types.yaml definiert sein

Automatische Section-Erkennung: Sobald eine Section auf einer bestimmten Überschriften-Ebene eingeführt wurde (z.B. H2), beginnt bei jeder weiteren Überschrift auf dieser Ebene automatisch eine neue Section – auch ohne explizites [!section]-Callout.

Beispiel:

## Situation ^sit
> [!section] experience
Text A...            → type = "experience" (explizit)

## Reflexion ^ref
<!-- KEIN [!section] Callout -->
Text B...            → type = "experience" (note_type Fallback)
                       → ABER: Neue Section erkannt, neuer Chunk!

## Learnings ^learn
> [!section] insight
Text C...            → type = "insight" (explizit)

Body-Section: Textblöcke, die vor dem ersten [!section]-Callout stehen, erhalten:

• section: "body"
• type: note_type (Fallback)
• section_type: None

4.0.2 Intra-Note-Edges (Verbindungen innerhalb einer Note)

Block-References als Link-Format:

Das bevorzugte Format für Intra-Note-Links:

> [!edge] derives
> [[#^block-id]]

Fallback (mit Einschränkungen):

> [!edge] derives
> [[#Section-Name]]

Vollständiges Beispiel:

## Situation ^sit
> [!section] experience

Die Geschichte...

## Reflexion ^ref
> [!section] insight
> [!edge] derives
> [[#^sit]]

Was ich daraus lerne...

Ergebnis:

• Chunk der Reflexion (#ref) erhält eine derives-Kante zum Chunk der Situation (#sit)
• Beide Chunks sind in derselben Note → is_internal: true
• Scope ist chunk (nicht note)

Automatische Backlinks: Für alle Intra-Note-Edges werden automatisch inverse Backlinks erzeugt:

• Forward-Edge: #ref --[derives]--> #sit
• Backlink: #sit --[derived_from]--> #ref (automatisch)

Default-Edges aus graph_schema.md: Wenn keine expliziten Intra-Note-Edges definiert sind, aber Section-Types vorhanden:

• System ermittelt Source-Type und Target-Type (benachbarte Sektionen)
• Lookup in graph_schema.md via get_topology_info(source_type, target_type)
• Erster Eintrag aus typical wird als Default-Edge-Type verwendet

Beispiel:

## Situation ^sit
> [!section] experience

## Reflexion ^ref
> [!section] insight
<!-- Kein expliziter [!edge] -->

Ergebnis: Automatische Edge experience --[resulted_in]--> insight (aus Schema)

4.0.3 Effektiver Typ & Retrieval

Kernregel: Der Section-Type (sofern vorhanden) hat immer Vorrang vor dem note_type für:

• Vektor-Embedding (Suche)
• retriever_weight Lookup
• Type-Filter in Queries
• Graph-Expansion

Beispiel: Ein Chunk mit type: "insight" und note_type: "experience" erhält:

• retriever_weight: 1.20 (aus types.yaml für insight, nicht experience)
• Wird bei filter: {type: "insight"} gefunden
• Wird bei filter: {note_type: "experience"} ebenfalls gefunden

Chunk-Payload-Struktur:

{
    "type": "insight",           # Effektiver Typ (section_type || note_type)
    "note_type": "experience",   # Ursprünglicher Note-Typ (immer vorhanden)
    "section": "Reflexion",
    "section_type": "insight",   # Expliziter Section-Type (optional)
    ...
}

---

4. Edges & Verlinkung

Mindnet versteht Zusammenhänge durch Kanten.

4.1 Inline-Relationen (Semantische Verknüpfung)

Dies ist die mächtigste Methode. Du sagst dem System explizit, wie Dinge zusammenhängen.

"Daher rel:depends_on Qdrant." "Dieses Konzept ist rel:similar_to Pinecone."

Deep-Links zu Abschnitten (v2.9.1): Du kannst auch auf spezifische Abschnitte innerhalb einer Note verlinken:

"Siehe rel:based_on Mein Leitbild#P3 – Disziplin."

Das System trennt automatisch den Note-Namen (Mein Leitbild) vom Abschnitts-Namen (P3 – Disziplin), sodass mehrere Links zur gleichen Note möglich sind, wenn sie auf verschiedene Abschnitte zeigen.

Intra-Note-Links mit Block-IDs (WP-26): Für Verbindungen innerhalb derselben Note nutze Block-References:

> [!edge] derives
> [[#^block-id]]

Dies erzeugt eine Intra-Note-Edge mit is_internal: true und scope: "chunk".

Gültige Relationen:

• depends_on: Hängt ab von / Benötigt.
• blocks: Blockiert oder gefährdet (z.B. Risiko -> Projekt).
• caused_by: Wurde verursacht durch (Kausalität).
• similar_to: Ähnelt / Ist vergleichbar mit.
• solves: Löst (Problem).
• based_on: Basiert auf (Fundament).
• prev / next [NEU]: Markiert chronologische oder evolutionäre Abfolgen (z.B. Leitbild-Evolution).

4.2 Callout-Edges (empfohlen)

Für Zusammenfassungen am Ende einer Notiz, oder eines Absatzes:

> [!edge] related_to
> [[Vector Embeddings]]
>  [[AI Agents]]

Multi-Line Support (v2.9.1): Callout-Blocks mit mehreren Zeilen werden korrekt verarbeitet. Das System erkennt automatisch, wenn mehrere Links im gleichen Callout-Block stehen, und erstellt für jeden Link eine separate Kante (auch bei Deep-Links zu verschiedenen Sections).

Verschachtelte Edge-Callouts in Containern (WP-26): Für übersichtliche Gruppierung von Edges kannst du verschachtelte Callouts nutzen:

> [!abstract] Semantic Edges
>> [!edge] derived_from
>> [[Wikilink#Abschnitt]]
>
>> [!edge] solves
>> [[Wikilink2]]

Regeln:

• Container-Callouts wie [!abstract] werden als Gruppierung erkannt, aber nicht semantisch verarbeitet
• Eingebettete >> [!edge] Callouts werden korrekt extrahiert
• Die Einrückungsebene (Anzahl >) bestimmt die Zugehörigkeit zum Block
• Leere Zeilen innerhalb des Containers (mit >) beenden den Edge-Block nicht

Format-agnostische De-Duplizierung: Wenn Kanten bereits via [!edge] Callout vorhanden sind, werden sie nicht mehrfach injiziert. Das System erkennt vorhandene Kanten unabhängig vom Format (Inline, Callout, Wikilink).

4.3 Automatische Spiegelkanten (Invers-Logik) - WP-24c v4.5.8

In Mindnet musst du Kanten nicht manuell in beide Richtungen pflegen. Das System erzeugt automatisch Spiegelkanten (Invers-Kanten) im Hintergrund.

Wie es funktioniert:

1. Du setzt eine explizite Kante: Z.B. [[rel:depends_on Projekt Alpha]] in Note A
2. System erzeugt automatisch die Spiegelkante: Note "Projekt Alpha" erhält automatisch enforced_by: Note A
3. Vorteil: Beide Richtungen sind durchsuchbar, ohne dass du beide manuell setzen musst

Deine Aufgabe: Setze die Kante in der Datei, die du gerade bearbeitest, so wie es der logische Fluss vorgibt.

• Blick zurück (Rückwärtslink): Wenn du ein Ergebnis dokumentierst, nutze derived_from, based_on oder prev.
• Blick nach vorn (Vorwärtslink): Wenn du einen Plan oder ein Protokoll schreibst, nutze resulted_in, supports oder next.

System-Logik (Beispiele):

• Schreibst du in Note A: [[rel:next Projekt B]], erzeugt das System automatisch: Projekt B prev: Note A
• Schreibst du in Note B: [[rel:derived_from Note A]], erzeugt das System automatisch: Note A resulted_in: Note B
• Schreibst du in Note A: [[rel:impacts Projekt B]], erzeugt das System automatisch: Projekt B impacted_by: Note A

Wichtig:

• Explizite Kanten haben Vorrang: Wenn du bereits beide Richtungen explizit gesetzt hast, wird keine automatische Spiegelkante erzeugt (keine Duplikate)
• Höhere Wirksamkeit expliziter Kanten: Explizit gesetzte Kanten haben höhere Priorität und Confidence-Werte als automatisch generierte Spiegelkanten
• Schutz vor Manipulation: System-Kanten (belongs_to, next, prev) können nicht manuell überschrieben werden (Provenance Firewall)

Vorteil: Keine redundante Datenpflege, kein "Link-Nightmare", volle Konsistenz im Graphen. Beide Richtungen sind durchsuchbar, was die Auffindbarkeit von Informationen verdoppelt.

4.4 Explizite vs. Validierte Kanten (Phase 3 Validierung) - WP-24c v4.5.8

Mindnet unterscheidet zwischen expliziten Kanten (sofort übernommen) und validierten Kanten (Phase 3 LLM-Prüfung).

Explizite Kanten (Höchste Priorität)

Diese Kanten werden sofort in den Graph übernommen, ohne LLM-Validierung:

1. Typed Relations im Text:

   Diese Entscheidung [[rel:depends_on Performance-Analyse]] wurde getroffen.
   

2. Callout-Edges:

   > [!edge] depends_on
   > [[Performance-Analyse]]
   > [[Projekt Alpha]]
   

3. Note-Scope Zonen:

   ## Smart Edges
   [[rel:depends_on|System-Architektur]]
   [[rel:part_of|Gesamt-System]]
   

   (Siehe auch: Note-Scope Zonen)

Vorteil expliziter Kanten:

• ✅ Sofortige Übernahme: Keine Wartezeit auf LLM-Validierung
• ✅ Höchste Priorität: Werden immer beibehalten, auch bei Duplikaten
• ✅ Höhere Confidence: Explizite Kanten haben confidence: 1.0 (maximal)
• ✅ Keine Validierungs-Kosten: Keine LLM-Aufrufe erforderlich

Validierte Kanten (Phase 3 - candidate: Präfix)

Kanten, die in speziellen Validierungs-Zonen stehen, erhalten das candidate: Präfix und werden in Phase 3 durch ein LLM semantisch geprüft:

Format:

### Unzugeordnete Kanten

related_to:Mögliche Verbindung
depends_on:Unsicherer Link
uses:Experimentelle Technologie

Validierungsprozess:

1. Extraktion: Links aus ### Unzugeordnete Kanten erhalten candidate: Präfix
2. Phase 3 Validierung: LLM prüft semantisch: "Passt diese Verbindung zum Kontext?"
3. Erfolg (VERIFIED): candidate: Präfix wird entfernt, Kante wird persistiert
4. Ablehnung (REJECTED): Kante wird nicht in die Datenbank geschrieben

Kontext-Optimierung:

• Note-Scope Kanten: LLM nutzt Note-Summary oder gesamten Note-Text (besser für globale Verbindungen)
• Chunk-Scope Kanten: LLM nutzt spezifischen Chunk-Text (besser für lokale Referenzen)

Wann nutze ich validierte Kanten?

• ✅ Explorative Verbindungen: Du bist unsicher, ob die Verbindung wirklich passt
• ✅ Experimentelle Links: Du willst testen, ob eine Verbindung semantisch Sinn macht
• ✅ Automatische Vorschläge: Das System hat Links vorgeschlagen, die du prüfen lassen willst

Wann nutze ich explizite Kanten?

• ✅ Sichere Verbindungen: Du bist dir sicher, dass die Verbindung korrekt ist
• ✅ Schnelle Übernahme: Du willst keine Wartezeit auf Validierung
• ✅ Höchste Priorität: Die Verbindung soll definitiv im Graph sein

(Siehe auch: LLM-Validierung von Links)

4.5 Note-Scope Zonen (Globale Verbindungen) - WP-24c v4.2.0

Für Verbindungen, die der gesamten Note zugeordnet werden sollen (nicht nur einem spezifischen Chunk), nutze Note-Scope Zonen:

## Smart Edges

[[rel:depends_on|Projekt-Übersicht]]
[[rel:part_of|Größeres System]]

Vorteile:

• ✅ Globale Verbindungen: Links gelten für die gesamte Note, nicht nur einen Abschnitt
• ✅ Höchste Priorität: Note-Scope Links haben Vorrang bei Duplikaten
• ✅ Bessere Validierung: In Phase 3 nutzt das LLM den gesamten Note-Kontext (Note-Summary/Text)

Wann nutze ich Note-Scope?

• ✅ Projekt-Abhängigkeiten: "Dieses Projekt hängt von X ab" (gilt für die ganze Note)
• ✅ System-Zugehörigkeit: "Dieses Konzept ist Teil von Y" (gilt für die ganze Note)
• ✅ Globale Prinzipien: "Diese Entscheidung basiert auf Prinzip Z" (gilt für die ganze Note)

Wann nutze ich Chunk-Scope (Standard)?

• ✅ Lokale Referenzen: "In diesem Abschnitt nutzen wir Technologie X" (nur für diesen Abschnitt)
• ✅ Spezifische Kontexte: Links, die nur in einem bestimmten Textabschnitt relevant sind

(Siehe auch: Note-Scope Zonen - Detaillierte Anleitung)

---

5. Schreiben für den KI-Zwilling (Szenarien)

Damit der RAG-Chat dich berät, musst du "Futter" für die Decision Engine liefern.

5.1 Szenario A: Decision Engine (DECISION)

• Ziel: Das System soll abwägen: "Passt Tool X zu mir?"

• Vorgehen: Erstelle Notizen mit type: value oder type: goal.

• Effekt: Wenn du fragst "Soll ich Notion nutzen?", lädt die Engine diese Notiz und antwortet: "Nein, Notion ist SaaS ohne E2E. Das verletzt dein Prinzip der Datensparsamkeit."

Szenario B: Empathie (EMPATHY)

• Ziel: Das System soll dich verstehen.
• Vorgehen: Erstelle type: experience mit emotionalen Brückenwörtern.

Beispiel Notiz:

---
type: experience
title: Erfahrung: Der Durchbruch nach der Krise
tags: [krise, hoffnung, grau, angst]
---
Es gibt Projektphasen, da wirkt alles **sinnlos** und **grau**.
Ich habe gelernt: Das ist oft das Zeichen kurz vor dem Durchbruch.

• Effekt: Bei "Alles ist grau" findet das System diese Notiz und spiegelt die Lektion zurück.

5.2 Szenario C: Forward-Mapping (Lücken-Analyse) [NEU]

• Ziel: Strategische Wissenslücken füllen.
• Vorgehen: Erstelle Hub-Notizen mit Forward-Links auf noch nicht existierende Dateien (z. B. [[Besten Version meiner Selbst]]).
• Effekt: Das System erkennt die semantische Bedeutung des geplanten Wissens und kann proaktiv Fragen stellen, um diese Lücken zu schließen.

5.3 Szenario D: Narratives Gedächtnis (Intention) [NEU]

• Ziel: Das System soll verstehen, warum eine Entscheidung getroffen wurde, um in ähnlichen künftigen Situationen konsistent zu beraten.
• Vorgehen: Nutze in journal- oder experience-Notizen Abschnitte für "Hintergrund" und "Interpretation".
• Beispiel: Statt "Wert: Disziplin" schreibe "Ich wähle Disziplin, weil ich in meiner Kindheit erlebt habe, wie Willkür schadet."
• Effekt: Die KI spiegelt nicht nur die Regel, sondern die Überzeugung dahinter.

5.4 Szenario C: Forward-Mapping (Lücken-Analyse)

Setze bewusst Links auf Dateien, die noch nicht existieren (z.B. [[Die beste Version meiner selbst]]). Die KI erkennt diese semantischen Lücken und stellt im Chat proaktive Fragen, um diese Felder mit dir zu füllen.

5.5 Szenario D: Narratives Gedächtnis

Dokumentiere das "Warum" (Fleisch am Knochen). Wenn du schreibst: "Ich wähle Disziplin, weil ich Willkür als Kind schmerzhaft erlebt habe", versteht die KI die emotionale Kausalität und kann dich in Krisen an diesen Ursprung erinnern.

6. Best Practices & Beispiele

6.1 Beispiel: Projekt-Notiz (Standard)

Projekte profitieren von depends_on, um Abhängigkeiten zu klären.

---
id: 20251115-proj-mindnet
title: Mindnet Implementierung
type: project
status: active
---

# Mindnet Implementierung

Wir bauen ein persönliches Wissensnetz.

## Tech Stack
Wir nutzen [[rel:depends_on Qdrant]] für die Vektorsuche und [[rel:depends_on FastAPI]] für das Backend.

## Architektur
Das Konzept basiert auf [[RAG Architecture]].

6.2 Beispiel: Advanced Tuning (Manuelles Override)

Hier zwingen wir das System, eine Entscheidung extrem kleinteilig (strict) zu zerlegen und in der Suche maximal zu priorisieren.

---
id: 20251120-adr-vektordb
title: ADR: Wahl von Qdrant
type: decision
status: final
tags: [architektur, db]
chunking_profile: structured_smart_edges_strict
retriever_weight: 1.5
---

# Entscheidung: Qdrant

Wir haben uns für Qdrant entschieden.

## Alternativen
Wir haben auch [[rel:similar_to Pinecone]] und [[rel:similar_to Weaviate]] betrachtet.

6.3 Beispiel: Section Types & Intra-Note-Edges (WP-26)

Eine Erfahrungs-Notiz mit unterschiedlichen Section-Types und Intra-Note-Verbindungen:

---
id: erlebnis-konflikt-team
title: Konflikt im Team-Meeting
type: experience
tags: [team, konflikt, learning]
---

# Konflikt im Team-Meeting

## Situation ^sit
> [!section] experience

Am 15. Januar 2026 kam es im Sprint-Review zu einer Eskalation...

## Meine Reaktion ^react
> [!section] experience
> [!edge] followed_by
> [[#^sit]]

Ich habe versucht zu deeskalieren, aber...

## Reflexion ^ref
> [!section] insight

Diese Erfahrung zeigt mir, dass ich in Konfliktsituationen...

> [!abstract] Semantic Edges
>> [!edge] derives
>> [[#^sit]]
>> [[#^react]]

## Nächste Schritte ^next
> [!section] decision

Ich werde in Zukunft:
1. Früher eingreifen
2. Neutrale Sprache verwenden

> [!edge] caused_by
> [[#^ref]]

Ergebnis:

• 4 Chunks mit unterschiedlichen Types:
  • #sit: type: experience (explizit)
  • #react: type: experience (explizit)
  • #ref: type: insight (explizit, überschreibt note_type)
  • #next: type: decision (explizit, überschreibt note_type)
• Intra-Note-Edges:
  • #react --[followed_by]--> #sit
  • #ref --[derives]--> #sit
  • #ref --[derives]--> #react
  • #next --[caused_by]--> #ref
• Alle Edges haben is_internal: true und scope: "chunk"

---

7. Virtual Schema Layer

Grundsätzlich gilt das Prinzip des Virtual Schema Layers. Die Logik (wie chunk_size) wird zentral in der types.yaml verwaltet. Aber: Als Power-User hast du über die Overrides jederzeit die Möglichkeit, aus diesem Standard auszubrechen.