AdaWorldAPI · AdaWorldAPI · Apr 29, 2026 · Apr 29, 2026
diff --git a/.claude/IDEA_JOURNAL_2026_04_29_STREAMING_HYDRATION.md b/.claude/IDEA_JOURNAL_2026_04_29_STREAMING_HYDRATION.md
@@ -0,0 +1,168 @@
+# Streaming-Hydration & Family-Bound Fractal Codec — Idea Journal
+
+**Stand:** 2026-04-29
+**Kontext:** Session nach Pillar 6 (EWA-Sandwich, PR #289). Zwei Ideen wurden in einem Atemzug formuliert; sie sind beide substanziell, lösen aber verschiedene Probleme. Dieses Dokument hält sie fest, bevor sie sich verdünnen.
+
+**Status:** **Notizen, kein Implementierungsplan.** Jede Idee hat einen Reife-Grad. Implementierung erst wenn explizit beauftragt.
+
+---
+
+## Idee 1 — Safetensor-Streaming als ndimensionale Bedeutungsakkumulation
+
+### Die rohe Formulierung
+
+> einen safetensor einfach durch diesen Bound zu streamen und dann durch die aktive pertubation "irgendwas" während des haltens aller möglichen bedeutungen in einem bedeutungsraum gleichzeitig entweder vor der wiederverwendung als ndimensionale bedeutungsakkumulation aka holographische hydrierung im 16k^n raum mit signed bits, string theorie / quantum applied "Work"
+
+### Was konkret darin steckt
+
+Ein safetensor (Modell-Gewichte, typisch 1-100 GB) wird **nicht in den Speicher geladen**, sondern Tile-für-Tile durch eine Pipeline gestreamt. Während der Stream läuft:
+
+1. Aktuelles Tile (cache-friendly Größe, etwa 256×256 bf16 ≈ 128 KB, L2-resident) wird Hadamard-rotiert
+2. Σ wird via `fractal_descriptor` extrahiert (MFDFA + Hurst + Fraktal-Dimension)
+3. Σ wird via EWA-Sandwich (Pillar 6) gegen den existierenden 16k-Substrat-Zustand propagiert
+4. Resultat akkumuliert in `holograph::width_16k::SchemaSidecar` Block 14/15
+
+Output: nicht "Modell geladen" sondern "Modell als Bedeutungs-Akkumulation **integriert**". **Holographisch** weil jedes Tile gegen alle vorherigen propagiert (multi-source resonance). **Hydration** weil die abstrakte Modell-Information in volle Substrat-Auflösung expandiert wird.
+
+### Konkrete Größenordnungen
+
+| Modell-Größe | safetensor-Bytes | Tile-Anzahl @ 128 KB | Geschätzte Streaming-Zeit |
+|---|---|---|---|
+| 1B params bf16 | 2 GB | 16 384 | ~33 s |
+| 7B params bf16 | 14 GB | 114 688 | ~3.8 min |
+| 70B params bf16 | 140 GB | 1.15 M | ~38 min |
+
+(Geschätzt mit gemessenen 2 ms / Sandwich aus Pillar 6. **Nicht validiert** für volle Hydrations-Pipeline — der Hadamard-Rotation-Schritt und der Sidecar-Schreiber kommen on top.)
+
+### Was schon existiert und passt
+
+- `bgz-tensor::fractal_descriptor` macht Hadamard-Rotation + MFDFA pro Row (200 LOC, fertig)
+- `ewa_sandwich` (Pillar 6) macht Σ-Push-Forward mit PSD-Erhaltung (zertifiziert, PR #289)
+- `holograph::width_16k::SchemaSidecar` hat Block 14/15 reserviert (existiert)
+- `bgz-tensor::cascade` (HHTL) kennt L1/L2/L3-Cache-Tile-Größen (fertig)
+
+### Was fehlt
+
+- safetensors-Reader-Integration (`safetensors` crate ist auf crates.io)
+- Glue-Layer der pro Tile die Pipeline orchestriert
+- Sidecar-Schreiber der die akkumulierte Σ in Block 14/15 persistiert
+- Per-Modell-Stream-Time-Budget und -Resumability (für 70B-Klasse)
+
+### Vorgeschlagener nächster Schritt: Pillar 7 — "Streaming-Hydration erhält KS-Bound"
+
+**Beweis-im-Code, kein produktiver Code.** Synthetisches "kleines safetensor" (1000 Rows × 768 Cols bf16, ≈1.5 MB), Tile-Größe 128, pro Tile Hadamard-rotieren + Σ extrahieren + Sandwich propagieren. Messen: bleibt akkumulierte Σ konsistent mit Köstenberger-Stark-Konzentrations-Bound?
+
+PASS-Kriterium: gemessene Tightness ≤ 1.75 (gleiches Regime wie Pillar 6).
+
+~250 Zeilen pure Rust, ~1h Arbeit. Zertifiziert die mathematische Zulässigkeit. Production-Code separat danach.
+
+### Vagheits-Punkte (ehrlich markiert)
+
+Drei Begriffe in der rohen Formulierung sind **noch nicht konkrete Operationen**:
+
+1. **"String-Theorie / quantum applied Work"** — schöne Analogie, aber keine direkt implementierbare Mathematik. Wenn gemeint: Quanten-Superposition als VSA-Bundle, Operator-Algebra als Sandwich-Kette — das ist schon zertifiziert (Pillar 5+, 5++, 6). Wenn etwas anderes gemeint, müsste konkretisiert werden.
+
+2. **"signed bits in 16k^n"** — n=2 ergibt 16k×16k = 256M Cells (32 MB als Bits, L3-resident — sinnvoll). n=3 ergibt 16k³ = 4 TB (DRAM-Sprengung). n=4 ist nicht implementierbar. **Vermutete Lesart**: n=2 oder dynamisch n=variable für verschiedene Substrat-Layers; zu spezifizieren.
+
+3. **"holographische Hydrierung"** — der `holograph` Crate hat eine konkrete Bedeutung (BitVec, XOR-Bind, 16k-Width). "Holographisch" hier vermutlich gemeint als "jedes Tile resoniert gegen alles vorherige" (multi-source bind). Das ist konkret und implementierbar.
+
+---
+
+## Idee 2 — Family-Bounds als globale räumlich-fraktale Codierung/Dekodierung
+
+### Die rohe Formulierung
+
+> oder die hydrierung durch die gesamtheit aller family bounds als globales räumlich hydrierbare Fraktalcodierung / dekodierung
+
+### Was konkret darin steckt
+
+`HighHeelBGZ` Container haben "family basins" (Q/K, V, Gate, FFN). Jeder family basin ist ein kompakter 2 KB Container mit 240 CausalEdge64. Die **Gesamtheit aller family basins** über alle Knoten/Kanten im Substrat bildet eine globale Hierarchie.
+
+Wenn die Hierarchie selbst-ähnlich ist (Mandelbrot/MFDFA-Eigenschaft), dann ist sie als **Fraktal kodierbar**. Konsequenz: pro Anfrage muss nicht das ganze Substrat materialisiert werden — die nötigen Sub-Bounds können **on-demand fraktal dekodiert** werden.
+
+Eingabe: Query-Hypothese (16k-Fingerprint).
+Ausgabe: nur die family basins die für diese Hypothese relevant sind, generiert on-demand aus dem fraktalen Codec.
+
+### Was schon existiert und passt
+
+- `bgz-tensor::fractal_descriptor` misst Selbst-Ähnlichkeit pro Row (Hadamard + MFDFA + Hurst + Fraktal-Dim)
+- `lance-graph-contract::high_heel` definiert das 2-KB-Container-Format
+- `bgz-tensor::cascade` hat HHTL-Pruning (HEEL → HIP → TWIG → LEAF), das die Hierarchie schon implizit traversiert
+
+### Was fehlt — und wo das Risiko sitzt
+
+**Die Behauptung "globales Substrat ist fraktal" ist eine Hypothese, kein gemessener Fakt.**
+
+`fractal_descriptor` misst Selbst-Ähnlichkeit *pro Row*. Die *globale* Selbst-Ähnlichkeit über alle family basins ist **nicht gemessen**. Wenn sie nicht da ist, bricht die ganze Idee.
+
+Außerdem: MFDFA ist ein **Analyse-Tool**, nicht ein bidirektionaler Codec. On-Demand-Dekodierung würde eine **Inverse** brauchen, die mathematisch nicht trivial ist. Mögliche Pfade:
+- Iterierte Funktionssysteme (IFS) — wenn die fraktale Struktur tatsächlich durch ein IFS erzeugt ist, kann sie durch das IFS rekonstruiert werden
+- Wavelet-basierte Multi-Resolution-Synthesis — würde eine Wavelet-Codec-Schicht zusätzlich zu MFDFA erfordern
+- Direkte Mandelbrot-style Iteration — wenn z_{n+1} = f(z_n) das Substrat erzeugt, ist Dekodierung = Iteration mit dem richtigen f
+
+Keiner dieser drei Pfade ist heute existent. Idee 2 ist **mehrere Größenordnungen spekulativer** als Idee 1.
+
+### Vorgeschlagener nächster Schritt: Diagnostik-Probe (kein Pillar)
+
+Bevor irgendeine Dekodierungs-Engine gebaut wird, **eine Messung**: ist die Substrat-Hierarchie überhaupt fraktal?
+
+1. Sammle (synthetisch generierte) family bounds über ~1000 Knoten
+2. Berechne MFDFA-Spektrum auf der **Verteilung der family bounds** (nicht pro Bound)
+3. Prüfe ob die Verteilung Multi-Skalen-Selbst-Ähnlichkeit zeigt (Hurst-Exponent ≠ 0.5, fraktale Dimension > 1, Spektrum-Breite > 0)
+4. PASS: ja, Hurst ≠ 0.5 mit signifikanter Spektrum-Breite → Fraktal-Codec ist mathematisch sinnvoll
+5. FAIL: Verteilung ist white noise oder Brownian → Fraktal-Codec ist Hammer-sucht-Nagel
+
+Das ist eine **Diagnostik**, nicht ein Pillar. ~150 Zeilen, baut auf existing `fractal_descriptor`. Pass/Fail entscheidet ob Idee 2 weiterverfolgt wird.
+
+### Wenn der Probe pass't
+
+Dann erst die Codec-Frage: welcher der drei Pfade (IFS / Wavelet / Mandelbrot-Iteration) passt zur gemessenen fraktalen Struktur. Das ist eine separate Forschungs-Phase, kein Engineering.
+
+### Wenn der Probe fail't
+
+Dann ist Idee 2 ehrlich verworfen. Substrat ist nicht global fraktal — die per-Row-Selbst-Ähnlichkeit aus `fractal_descriptor` ist eine *lokale* Eigenschaft, nicht eine *globale*. Idee 1 (Streaming-Hydrierung) bleibt unbeeinflusst, weil sie die fraktale Annahme nicht braucht.
+
+---
+
+## Beziehung zwischen den beiden Ideen
+
+| Aspekt | Idee 1 (Streaming-Hydration) | Idee 2 (Fraktal-Codec) |
+|---|---|---|
+| Problem | wie integrieren wir externe Modelle ohne sie zu laden | wie repräsentieren wir das gesamte Substrat ohne es zu materialisieren |
+| Mathematische Basis | Pillar 5+, 5++, 6 (alle merged/PR) | Annahme globaler Fraktalität (ungemessen) |
+| Konkretheit | hoch — Tile-Größen bekannt, Latenzen gemessen | spekulativ — Codec-Pfad nicht klar |
+| Risiko | gering | hoch |
+| Voraussetzung | keine | Diagnostik-Probe muss pass'en |
+| Was es freisetzt | Modell-Integration in Minuten statt Stunden | Substrat-Operationen ohne DRAM-Limit |
+| Hammer-sucht-Nagel-Risiko | gering — klare Anwendung | mittel — kann zu generischer Engine ausarten |
+
+**Wichtig:** beide Ideen haben die *gleiche mathematische Form* (Streaming-Hydrierung mit Sandwich-Propagation), aber **verschiedene Use-Cases**. In einem PR zusammenfassen wäre Hammer-sucht-Nagel.
+
+---
+
+## Empfohlene Sequenz (wenn implementiert wird)
+
+1. **Pillar 7** — Streaming-Hydration erhält KS-Bound (Idee 1, mathematische Zertifizierung)
+2. **Production-Code** — Streaming-Glue mit safetensors-Reader (Idee 1, Engineering)
+3. **Fraktal-Diagnostik-Probe** — ist das Substrat global fraktal? (Idee 2, Vorbedingung)
+4. **(Bedingt)** Codec-Forschung wenn Probe pass't, sonst Idee 2 verworfen
+
+Schritt 1 und 3 können **parallel** laufen, weil sie unabhängige Zertifizierungen sind. Schritt 2 erst nach 1. Schritt 4 erst nach 3.
+
+---
+
+## Was nicht in dieses Dokument gehört
+
+- Implementierungs-Code (separate PR)
+- Architektur-Entscheidungen die nicht mit diesen zwei Ideen zu tun haben
+- Theoretische Spekulation jenseits dessen was konkret messbar ist
+
+---
+
+## Wann dieses Dokument aktualisiert wird
+
+- Wenn Pillar 7 gebaut/gepasst → Status "implementiert" eintragen, Latenzen/Bounds dokumentieren
+- Wenn Diagnostik-Probe gelaufen → Resultat eintragen, Idee 2 entweder verfeinern oder verwerfen
+- Wenn neue verwandte Ideen kommen → eigenes Kapitel hinzufügen, nicht in bestehende vermischen
+
+**Zweck dieses Dokuments:** Ideen festhalten *bevor sie sich verdünnen*. Nicht: Ideen-Sammlung als Feature-Liste behandeln. Jede Idee hat ihren eigenen Reife-Pfad.