mindnet/docs/03_Technical_References/03_tech_data_model.md

doc_type	audience	scope	status	version	context
technical_reference	developer, architect	database, qdrant, schema	active	2.9.1	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:

{
  "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:

{
  "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:

{
  "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