mindnet/docs/03_Technical_References/03_tech_data_model.md

---
doc_type: technical_reference
audience: developer, architect
scope: database, qdrant, schema
status: active
version: 2.9.1
context: "Exakte Definition der Datenmodelle (Payloads) in Qdrant und Index-Anforderungen. Berücksichtigt WP-14 Modularisierung und WP-15b Multi-Hashes."
---

# Technisches Datenmodell (Qdrant Schema)

## 1. Collections & Namenskonvention

Mindnet speichert Daten in drei getrennten Qdrant-Collections. Der Prefix ist via ENV `COLLECTION_PREFIX` konfigurierbar (Default: `mindnet`). Die Auflösung erfolgt zentral über `app.core.database.collection_names`.

Das System nutzt folgende drei Collections:
* `{prefix}_notes`: Metadaten der Dateien.
* `{prefix}_chunks`: Vektorisierte Textsegmente.
* `{prefix}_edges`: Gerichtete Graph-Kanten.

---

## 2. Note Payload (`mindnet_notes`)

Repräsentiert die Metadaten einer Markdown-Datei (1:1 Beziehung).

**JSON-Schema:**

```json
{
  "note_id": "string (keyword)",       // UUIDv5 (deterministisch via NAMESPACE_URL)
  "title": "string (text)",            // Titel aus Frontmatter
  "type": "string (keyword)",          // Logischer Typ (z.B. 'project', 'concept')
  "status": "string (keyword)",        // Lifecycle: 'stable', 'active', 'draft', 'system' (WP-22)
  "retriever_weight": "float",         // Effektive Wichtigkeit (Frontmatter > Type > Default)
  "chunk_profile": "string",           // Effektives Profil (Frontmatter > Type > Default)
  "edge_defaults": ["string"],         // Liste der aktiven Default-Kanten
  "tags": ["string"],                  // Liste von Tags aus Frontmatter
  "aliases": ["string"],               // Synonyme für Discovery (WP-11)
  "created": "string (iso-date)",      // Erstellungsdatum
  "updated": "integer",                // Timestamp (File Modification Time)
  "fulltext": "string (no-index)",     // Gesamter Text (nur für Recovery/Export)
  
  // Multi-Hash für flexible Change Detection (WP-15b)
  "hashes": {
    "body:parsed:canonical": "string", // Hash nur über den Text-Body
    "full:parsed:canonical": "string"  // Hash über Text + Metadaten (Tags, Title, Config)
  }
}
```

**Erforderliche Indizes:**
Es müssen Payload-Indizes für folgende Felder existieren:
* `note_id`
* `type`
* `status`
* `tags`

---

## 3. Chunk Payload (`mindnet_chunks`)

Die atomare Sucheinheit. Enthält den Vektor.

**Vektor-Konfiguration:**
* Modell: `nomic-embed-text` (via Ollama oder Cloud)
* Dimension: **768**
* Metrik: Cosine Similarity

**JSON-Schema:**

```json
{
  "chunk_id": "string (keyword)",      // Format: UUIDv5 aus {note_id}#c{index}
  "note_id": "string (keyword)",       // Foreign Key zur Note
  "type": "string (keyword)",          // Kopie aus Note (Denormalisiert für Filterung)
  "text": "string (text)",             // Reintext für Anzeige (ohne Overlap)
  "window": "string (text)",           // Text + Overlap (Basis für Embedding)
  "ord": "integer",                    // Laufende Nummer (1..N) für Sortierung
  "retriever_weight": "float",         // Geerbt von Note (für schnelles Re-Ranking)
  "chunk_profile": "string",           // Geerbt von Note (für Debugging/Filtering)
  "neighbors_prev": ["string"],        // ID des Vorgängers (Linked List)
  "neighbors_next": ["string"],        // ID des Nachfolgers
  "section": "string",                 // Pfad/Überschrift, zu der der Chunk gehört
  "source_path": "string"              // Relativer Pfad zur Datei
}
```

**Erforderliche Indizes:**
Es müssen Payload-Indizes für folgende Felder existieren:
* `note_id`
* `chunk_id`
* `type`

---

## 4. Edge Payload (`mindnet_edges`)

Gerichtete Kanten zwischen Knoten. Stark erweitert in v2.6 für Provenienz-Tracking. Seit v2.9.1 unterstützt das System **Section-basierte Links** (`[[Note#Section]]`), die in `target_id` und `target_section` aufgeteilt werden.

**JSON-Schema:**

```json
{
  "edge_id": "string (keyword)",       // Deterministischer Hash aus (src, dst, kind, variant)
                                       // variant = target_section (erlaubt Multigraph für Sections)
  "source_id": "string (keyword)",     // Chunk-ID (Start)
  "target_id": "string (keyword)",     // Chunk-ID oder Note-Titel (bei Unresolved)
                                       // WICHTIG: Enthält NUR den Note-Namen, KEINE Section-Info
  "target_section": "string (keyword)", // Optional: Abschnitts-Name (z.B. "P3 – Disziplin")
                                         // Wird aus [[Note#Section]] extrahiert
  "kind": "string (keyword)",          // Beziehungsart (z.B. 'depends_on')
  "scope": "string (keyword)",         // Immer 'chunk' (Legacy-Support: 'note')
  "note_id": "string (keyword)",       // Owner Note ID (Ursprung der Kante)
  
  // Provenance & Quality (WP03/WP15)
  "provenance": "keyword",             // 'explicit', 'rule', 'smart', 'structure'
  "rule_id": "string (keyword)",       // Traceability: 'inline:rel', 'explicit:wikilink', 'smart:llm'
  "confidence": "float"                // Vertrauenswürdigkeit (0.0 - 1.0)
}
```

**Section-Support:**
* Links wie `[[Note#Section]]` werden in `target_id="Note"` und `target_section="Section"` aufgeteilt.
* Die Edge-ID enthält die Section als `variant`, sodass mehrere Kanten zwischen denselben Knoten existieren können, wenn sie auf verschiedene Sections zeigen.
* Semantische Deduplizierung basiert auf `src->tgt:kind@sec` Key, um "Phantom-Knoten" zu vermeiden.

**Erforderliche Indizes:**
Es müssen Payload-Indizes für folgende Felder existieren:
* `source_id`
* `target_id`
* `target_section` (neu: Keyword-Index für Section-basierte Filterung)
* `kind`
* `scope`
* `note_id`
```