24 KiB
BrandLoop – Projekt-Übersicht (Knowledge Base)
Stand: 25. Juli 2026 · konsolidiert aus allen bisherigen Arbeitsdokumenten · erweitert um Bild-Modus, Feed & Ordner (§15) Zweck: Ein Dokument, das den kompletten Projektstand hält – Basis für die nächsten Arbeitsschritte.
1. Was wir bauen (in einem Absatz)
Eine App, in der Brands einen Prompt eingeben und 3–6 KI-generierte Werbevideos bekommen – jedes von einem anderen Top-Videomodell. Der Owner wählt das beste, die Ad läuft, und jedes Ergebnis (Vote + echte Ad-Performance) fließt in eine wachsende Brand Knowledge Base zurück. Jedes weitere Video startet mit allem, was bisher funktioniert hat.
Seit Juli 2026 daneben: ein zweiter, entkoppelter Bild-Modus mit Feed. Bilder statt Videos, ein festes Bildmodell, kein Vote-Loop – dafür ein öffentlicher Feed, aus dem man fertige Rezepte kopiert und in eigene Ordner sortiert. Der Bild-Modus ist der günstige Einstieg und löst den Kaltstart; Video bleibt das Kernprodukt. Details: konzept-bilder-feed.md, Zusammenfassung in §15.
Sprachregelung – gilt für die gesamte Doku und den Code: „Modell" (auch: Asset) = Person, Produkt, Kulisse oder Logo – das, was in einem Bild oder Video zu sehen ist. Tabelle
assets. „KI-Modell" = Seedance, Veo, Sora, Wan, das Bildmodell. Immer ausgeschrieben, nie nur „Modell". Wo im Text unten noch „Modell" im Sinne von KI-Modell steht, ist das ein Altbestand aus der Zeit vor dem Bild-Modus – im Zweifel gilt diese Regel.
Pitch: „Deine Ads lernen aus jedem ausgegebenen Euro. Generische Tools erstellen Videos – wir bauen ein Ad-Gedächtnis für deine Brand."
Arbeitstitel: BrandLoop (Platzhalter, noch nicht final)
Zielgruppe: ursprünglich D2C-Kosmetik-Brands. Mit dem Feed branchenoffen (Nischen-System) und über den Bild-Modus auch für Creator und Privatnutzer – siehe offene Punkte in §11.
2. Die drei tragenden Ideen
| Idee | Kern | Warum es der Moat ist |
|---|---|---|
| Ad-Gedächtnis pro Brand | Strukturierte Wissensdatenbank pro Kunde, wird bei jeder Generierung als Kontext injiziert | Konkurrenz generiert, wir lernen → Wechselkosten steigen mit der Nutzungsdauer |
| Modellunabhängigkeit | Kein Fine-Tuning eines Modells; Wissen liegt in Text/DB, nicht in Gewichten | Besseres Modell erscheint → wird eingetauscht, Knowledge Base bleibt |
| Performance-Loop | Meta/TikTok-Ads-Daten (CTR, Thumbstop, ROAS) gewichten das Scoring stärker als Bauchgefühl-Votes | Aus „schöne Videos" wird „Videos, die nachweislich verkaufen" |
Wichtige Abgrenzung: Wir trainieren kein Modell neu. Ausnahme ist nur die Konsistenz von Gesicht/Produkt (Character-Reference-Features bzw. LoRA auf Referenzbildern).
3. Der Produkt-Loop
Runde 1 (Kaltstart): Prompt → 3 Videos von 3 Modellen → Owner wählt → Vote = erstes Trainingssignal. Runde 2+: Neuer Prompt → wird vor der Generierung automatisch mit Brand-Wissen angereichert → Videos starten nicht bei null → Vote + Ad-Performance aktualisieren die Knowledge Base.
Kostenlogik im Ablauf: Nutzer sieht erst das Script und bestätigt – erst danach wird generiert (Kosten entstehen nach Bestätigung; Script-Änderungen sind zusätzliches Lernsignal).
4. Brand Knowledge Base – Datenmodell-Logik
Zwei Ebenen
- Regeln (kein Score, gelten immer): cleaner Hintergrund, „nur zeigen was verlangt ist", Logo-Schutz, „Referenzen nie 1:1 kopieren". Liegen im Developer-Modus, für den Nutzer unsichtbar → Betriebsgeheimnis.
- Attribute (mit Elo-Score, konkurrieren): location, licht, farben, kamera, voice, geraeusche, texte-hooks, handlungen.
Weitere Objekte
- Modelle / Assets (Gesicht, Produkt, Kulisse, Logo): versioniert nach Release-Prinzip – Videos und Bilder nutzen immer eine freigegebene Version, kein schleichender Drift. „Modell" meint in diesem Projekt durchgehend das Asset, nie das KI-Modell.
- Videos: ein Eintrag pro generiertem Video (Prompt, Tags, verwendete Asset-Versionen, Vote, Performance).
- Posts: das Pendant im Bild-Modus – ein Slot-Rezept mit Bilderkette (§15).
- Ordner: privater Wissens-Scope. Attribut-Scores werden je Ordner geführt (§15).
- Logs: append-only, jeder Score-Change mit Grund und Scope.
Drei Textebenen je Attribut
Beschreibung (was ist das) · Was es ausmacht (gelernte Essenz) · Details (Drehorte, Licht/Tageszeit, Farbwelt, Sound, fertige Prompt-Bausteine + Negativ-Prompts). Schreibt das System selbst; der Nutzer sieht davon nichts.
5. Scoring (Elo) – die Kernmechanik
Problem: Attribution. Gewinnt Video A (Kaiserslautern) gegen B (Köln), kann der Grund auch Licht, Stimme oder das Modell sein.
Lösung – 5 Mechanismen:
- Elo statt Fixpunkte – Sieg gegen ein starkes Attribut bringt mehr. Skala 0–10.000.
- Verteilte Punkte – alle Tags des Gewinner-Videos gewinnen anteilig, alle des Verlierers verlieren anteilig. Über viele Runden kristallisiert sich der echte Treiber heraus.
- Gezielte Fragen – „Welche Stadt war besser?" wirkt isoliert auf ein Attribut → schnellstes sauberes Signal.
- System-Favorit mit Anchoring-Schutz – Favorit wird markiert, aber: Bestätigung ×0,3 · Abweichung ×1 · Ad-Performance ×2. Übereinstimmungsrate Vorhersage↔Wahl ist die zentrale Qualitätsmetrik.
- LLM-Inhaltsvergleich – nach jedem Vote wird analysiert, was besser war, und in beide Attribut-Dateien geschrieben. Ggf. entsteht ein Unter-Attribut (kaiserslautern → --stadion).
Startwerte: Neuer Eintrag startet beim Kategorie-Durchschnitt (nicht bei 5000), sonst gilt Ungetestetes automatisch als „schlechter als alles". Nur der allererste Eintrag einer Kategorie startet bei 5000. Unsicherheit steckt im K-Faktor (32 neu → 8 etabliert).
Archivieren statt löschen – ein schlechter Score ist auch Wissen.
6. UI / Funktionsumfang
Homescreen → Feed · Erstellen (Szene / Post / Modell) · Ordner · Verbessern (jederzeit auf jedes Modell) · Knowledge Base (Ansicht) · Developer-Modus (versteckt, intern).
| Bereich | Inhalt |
|---|---|
| Feed | Posts anderer Nutzer, gefiltert nach Nische, sortiert nach Feed-Score → Post-Detail → Kopieren (Slot-Chips) oder in einen Ordner speichern |
| Erstellen → Szene (Video) | Prompt → automatische Anreicherung → Script-Anzeige & Bestätigung → 3–6 Videos → Auswahl → optionale gezielte Frage → Upload/Veröffentlichung → Live-Performance |
| Erstellen → Post (Bild) | Ordner wählen → Format → Slots füllen → ein Bildmodell generiert die Bilderkette → privat behalten oder aktiv veröffentlichen |
| Erstellen → Modell | Person/Produkt/Kulisse beschreiben + Referenzbilder → Modell wird erstellt → direkt „Verbessern" möglich |
| Ordner | Sammlungen anlegen (Zweck + Startwerte), eigene und fremde Posts einsortieren, Reifegrad sehen |
| Verbessern | Asset wählen → Text-Feedback oder Referenz-Upload (Pflichtfeld: was soll übernommen werden) → 3–5 neue Versionen → Vorher/Nachher → beste wählen → neue freigegebene Version |
| Developer-Modus | Feste Regeln · Prompt-Einblick (was wirklich ans Modell ging) · Elo-Parameter |
| Onboarding | Tutorial-artig, erscheint beim ersten Klick auf „Erstellen"; 6 Pflichtfragen (<2 Min) + optionale Uploads |
Scoring beim Verbessern: Nur Merkmale, in denen sich die Versionen unterschieden, bekommen Punkte.
Videoanzahl 3–6, Preis pro Video – Deckel bei 6, weil es nur eine Handvoll Top-Modelle gibt und bei zu vielen Videos die Auswahlqualität (= Trainingssignal) sinkt.
Onboarding-Fragen (Stufe 1, Pflicht)
- Label-Name · 2. Was verkaufst du · 3. Nische (feste Branchenliste) · 4. Zielgruppe · 5. Drei Brand-Worte · 6. Wie lange am Markt. Stufe 2 (optional): Logo, Produktbilder (3+ Winkel), bisher beste Ads, Brand-Gesicht, Kulisse. Stufe 3 (Progressive Profiling, max. 1 Frage/Sitzung): Farbwelt, Voice vs. Text-Overlay, No-Gos, Preissegment, Locations, Ad-Konten verbinden (wichtigster Moment – hier startet der Performance-Loop), Social-Konto verbinden (nach der ersten Post-Veröffentlichung), Wettbewerber.
7. Prompt-Architektur (22 Denk-Punkte, davon 19 neu zu schreiben)
Bauprinzip aller Prompts:
[STATISCHER KERN] – ändert sich nie, liegt im Dev-Modus
[SLOT: REGELN] [SLOT: ASSETS] [SLOT: ATTRIBUTE] [SLOT: USER-INPUT]
Grundregel: Kein LLM, wo Code reicht. Elo-Mathe, Archivierung, Performance-Mapping, Favorit-Berechnung sind deterministisch (⚙️).
| Phase | Prompts |
|---|---|
| Onboarding | P1 Upload-Analyst (Vision) · P2 Profil-Übersetzer |
| Szene erstellen | P3 Intent-Versteher · P4 Knowledge-Selector · P5 Script-Autor · P6 Script-Diff-Lerner · P7 Bild-Prompt-Generator ✅ · P8 Video-Prompt-Generator ✅ |
| Nach Generierung | P9 Video-Analyst/Tagger (Vision) · P10 Favorit ⚙️ · P11 Vote-Attributierer · P12 Vergleichs-Analyst · P13 Frage-Generator |
| KB-Pflege | P14 Details-Autor · P15 Kategorie-Wächter |
| Verbessern | P16 Referenz-Interpreter · P17 Versions-Chronist |
| Reporting | P18 Insight-Reporter (V2) |
| Bild-Modus & Feed | P19 Slot-Analyst · P20 Ordner-Vorschlag · P21 Werbetext-Autor · P22 Bild-Tagger (Vision) |
- Kritischer MVP-Pfad Video: P3, P4, P5, P8, P9, P11 – ohne die läuft der Loop nicht.
- Kritischer MVP-Pfad Bild: P7, P19, P21, P22 – ohne die funktioniert Kopieren nicht. P20 ist nachrüstbar.
- P19 ist der heikelste neue Prompt: zu wenig Abstraktion legt fremde Knowledge Bases offen, zu viel macht das Rezept unverständlich. Er verarbeitet fremden Text → Anti-Injection-Satz zwingend.
- P7 & P8 existieren bereits, müssen aber auf das Slot-System umgebaut werden; P8 zusätzlich pro Modell dialektisiert (ein Regie-Kern + 3–6 Adapter).
- Teuerster Prompt: P9 – läuft 1.000×/Monat bei 1.000 Videos.
8. Recherche-Ergebnisse: fertige Vorlagen (nichts von null bauen)
| Unser Prompt | Vorlage |
|---|---|
| P5/P8-Kern | Offizieller Wan-Rewriter (Alibaba, öffentlich auf GitHub) + „Master Prompt Architect"-Muster |
| P8-Adapter Seedance | Offizielle 6-Schritt-Formel, 60–100 Wörter |
| P8-Adapter Veo | 5-Teile-Formel (Kamera zuerst) + Timestamp-Prompting |
| P8-Adapter Sora | OpenAI-Cookbook-Template (Prosa + gelabelte Blöcke) |
| P7 | WearView-Rezept + Miraflow-Beauty-Templates |
| P9 | Microsoft-ISE-Pipeline (Enum-Zwang) + Gemini Structured Outputs |
| P16 | „Lock → Change → Scope"-Muster |
Die wichtigsten übernehmbaren Details:
- Anti-Injection-Satz aus dem Wan-Rewriter wörtlich übernehmen (schützt vor Manipulation durch User-Prompts).
- Seedance: nur EINE Kamerabewegung pro Shot; Rhythmus-Wörter statt Technik-Jargon; Licht ist der größte Qualitätshebel; „no music" explizit; Multi-Shot per „cut to"; echte Gesichter auf Fotos werden geblockt → stützt unsere KI-Gesichter-Regel.
- Foto-Realismus: Wörter wie „flawless", „perfect skin", sogar „ultra realistic" triggern den Beauty-Filter-Bias und verschlechtern das Ergebnis. Doppelte Negativliste (
wrinklesUNDskin too perfect). Flat-Licht versteckt Textur, gerichtetes Licht zeigt sie. - Konsistenz: 4–6 Referenzbilder optimal (>7 = feature-averaging); Identity-Lock am Anfang UND Ende des Prompts; Token-Locking – Merkmale wörtlich speichern und wörtlich wiederverwenden (gehört als Regel in die Asset-Dateien).
- P9-Tagging: Enum-Zwang ist „the highest-leverage decision"; doppelte Absicherung (Prompt-Regel + Code-Validator). Gemini ist gesetzt – einziges Modell mit nativem Video-Input inkl. Audiospur;
media_resolution: low+ 1 FPS drückt die Kosten.
Lücken (ehrlich): ByteDances interner Seedance-Rewriter ist nicht öffentlich · kein offizieller Google-Director-Prompt · Lizenzen einiger GitHub-Repos unverifiziert → Strukturen als Inspiration, Texte selbst schreiben.
9. Technik & Datenbank
Architektur: Cloud (V1), Hetzner Deutschland, DSGVO-konform. App: Web + native aus einer Codebase; Zahlung möglichst über Web-App via Stripe (App-Store-Abgabe 15–30 % umgehen). V2+: eigener MCP-Server, über den Brands ihre Knowledge Base in eigene Tools einbinden.
| Baustein | Wahl |
|---|---|
| Hosting | Hetzner Cloud (MVP CX32 ~€7 → CX42 ~€16 ab ~25 Brands) |
| Video-Speicher | Hetzner Object Storage (S3-kompatibel) |
| Backend/DB | Appwrite self-hosted (Auth+Teams, TablesDB, Functions, Realtime, Storage mit S3-Adapter, Messaging) – €0 Lizenz |
| KI-Gateway | OpenRouter (eine API für LLM und Video) |
| LLM | Claude (Scripts, Tagging, Vergleiche) · Gemini für P9 |
| Videomodelle | Seedance 2.0 + Veo 3.1 + Sora 2 / Wan |
| Payment | Stripe (Abo + metered) |
Kostenrechnung 25 Brands (~1.000 Videos/Monat): €1.300 gesamt, davon >90 % Videogenerierung (€1.200). ≈ €52/Brand/Monat → Abo ab €150–300/Brand lässt gesunde Marge. Genau deshalb funktioniert „Preis pro Video".
Datenbank-Tabellen (Appwrite)
brands (inkl. nische) · rules 🔒 · prompt_templates 🔒 (P1–P22, versioniert, mit model_adapter) · categories (avg_score als Cache, je Ordner) · attributes (nur noch die Definition: 3 Markdown-Ebenen, prompt_bausteine, negativ_prompts, self-relation für Unter-Attribute) · attribute_scores (Herzstück: score, k_factor, start_value, wins/losses – je Attribut je Ordner) · folders (zweck, startwert_modus) · score_events (append-only, mit folder_id) · assets/„Modelle" + asset_versions (released_version_id, Einwilligungs-Datei, typ inkl. kulisse) · scenes (user_prompt + selected_context + script vs. script_final = P6-Signal) · videos (prompt_sent, tags, attribute_ids, asset_version_ids, is_system_favorite) · posts (Slot-Rezept, slot_summary, sichtbarkeit, feed_score) · post_images (Bilderkette) · post_folders (m:n) · post_metrics (Feed-Signale) · video_metrics (Zeitreihe) · votes · questions · jobs (mit prompt_template_key + version → ohne das kein Prompt-Debugging; cost_usd) · usage_records.
Buckets: uploads · asset-references · generated-videos · generated-images · consents.
Functions (deterministisch): elo-update · favorit-berechnen · ads-metriken-holen (Cron) · kategorie-durchschnitt (Cron) · archivierung (Cron) · job-dispatcher · ordner-initialisieren · feed-score-berechnen (Cron) · feed-import · social-reichweite-holen (Cron).
Rechte: Brand = Appwrite-Team mit Row-Level-Permissions (Multi-Tenant ohne Extra-Code); internes Team exklusiv auf rules, prompt_templates, jobs.prompt_sent → das App-Geheimnis liegt in den Rechten, nicht nur im UI.
10. Rechtliches
- AVV mit Hetzner (Standard, kostenlos)
- EU AI Act: KI-generierte Werbevideos müssen gekennzeichnet werden
- Gesichter echter Personen nur mit dokumentierter Einwilligung (auch beim Brand Owner) → rein KI-generierte Gesichter sind der sichere Standard
- Referenzen fremder Inhalte: Merkmale beschreiben und lernen, nie 1:1 kopieren
- Impressum / AGB / Datenschutzerklärung
- Meta/TikTok-App-Reviews früh beantragen – die Freigabeprozesse dauern
11. Risiken & offene Punkte
| Risiko | Status / Gegenmaßnahme |
|---|---|
| Kosten pro Runde | Gelöst: Preis pro Video → aus Risiko wird Umsatzhebel |
| Kaltstart Runde 1 | Weitgehend gelöst: Onboarding-Uploads + Import beim Kopieren aus dem Feed (§15) – die KB ist gefüllt, bevor der erste Euro ausgegeben wurde |
| Anchoring durch Favoriten-Markierung | Vote-Gewichtung + Tracking; bei >90 % Bestätigungsrate Markierung testweise ausblenden |
| Wenig Datenpunkte für Elo | LLM-Inhaltsvergleich zieht schon aus einem einzigen Vergleich Erkenntnisse |
| Plattform-Anbindung | Meta/TikTok-API-Zugänge + Attributionsfenster technisch prüfen |
| Neu: Konvergenz durch den Feed | Wenn alle dieselben Top-Posts kopieren, wandert dasselbe Wissen in alle KBs, alle Ads sehen gleich aus und der Moat wird wertlos. Gegenmaßnahme: Ordner – Wissen wird segmentiert statt gemittelt (§15) |
| Neu: Rich-get-richer im Feed | Wer oben steht, bekommt Views und bleibt oben. Gegenmaßnahme: Zeit-Decay + fester Explorations-Slot für neue Posts |
| Neu: Manipulation des Feed-Scores | Globale Sichtbarkeit erzeugt Anreiz für Fake-Signale. Rate-Limits, Verifizierung, Ausreißer-Erkennung. Bei brand-internen Scores war das kein Thema |
| Neu: Moderation & Minderjährigenschutz | Öffentlicher Feed = nutzergenerierte Inhalte → DSA-Meldepflichten; breitere Nutzerbasis → Altersgrenzen klären |
| Offen: finaler Produktname | „BrandLoop" ist Platzhalter |
| Offen: konkrete Preisstufen | Richtwert €150–300/Brand/Monat + Preis pro Video. Passt nicht mehr zur Creator-/Privatnutzer-Zielgruppe des Bild-Modus – dort braucht es eine eigene, deutlich niedrigere Stufe oder Freemium |
12. Roadmap
Es gibt jetzt zwei Stränge, die parallel laufen können – der Bild-Strang ist billiger zu bauen und liefert früher Nutzer.
Video-Strang (Kernprodukt)
- MVP – Prompt → 3 Videos (3 Modelle) → Auswahl → einfache KB (Tags + Elo) → Anreicherung ab Runde 2. Prompts: P3, P4, P5, P8, P9, P11.
- V2 – Gezielte Vergleichsfragen, LLM-Inhaltsvergleich, Unter-Attribute, Produkt-/Gesichts-Referenzen. P12, P13, P14, P15, P16, P17.
- V3 – Meta/TikTok-Ads-Anbindung, performance-gewichtetes Scoring, Reporting-Dashboard. P18, MCP-Server.
Bild-Strang (Einstieg & Wachstum)
- B1 – Modelle anlegen (Person, Produkt, Kulisse), Post als Slot-Rezept erstellen, Bilderkette, ein festes Bildmodell. P7, P22.
- B2 – Feed: veröffentlichen, browsen nach Nische, Kopieren mit Slot-Chips. P19, P21. Feed-Score zunächst nur aus In-App-Signalen.
- B3 – Ordner mit Scores pro Ordner, Import beim Kopieren, KI-Ordner-Vorschlag. P20. Ab hier greifen Bild- und Video-Strang ineinander.
- B4 – Social-Account-Anbindung (organische Reichweite), Feed-Score mit ×2-Gewichtung, Moderation.
Abhängigkeit: B3 setzt die Auftrennung von
attributesinattribute_scoresvoraus. Diese Änderung sollte vor dem Video-MVP passieren – nachträglich eine Scope-Dimension in eine gefüllte Score-Tabelle einzuziehen ist deutlich teurer.
13. Was bereits existiert (Arbeitsstand)
| Datei | Inhalt | Reife |
|---|---|---|
konzept-ki-video-ads.md |
Gesamtkonzept Video, 12 Kapitel | ✅ durchdacht, v1 |
konzept-bilder-feed.md |
Bild-Modus, Feed, Kopieren, Ordner, Feed-Score | ✅ neu – Konzept steht, 8 offene Punkte markiert |
datenbank-aufbau.md |
Appwrite-Schema, alle Tabellen | ✅ umsetzungsreif · um Bild-Modus erweitert, attributes aufgetrennt |
prompt-inventar.md |
22 Denk-Punkte P1–P22 mit In/Out | ✅ vollständig kartiert · P19–P22 neu |
prompt-templates-research.md |
Deep Research, ~25 Quellen, Vorlagen-Mapping | ✅ Recherche abgeschlossen · deckt P19–P22 noch nicht ab |
fragenkatalog-onboarding.md |
3-stufiges Onboarding | ✅ fertig · Nische als 6. Pflichtfrage ergänzt |
prototyp-app.html |
Klickbarer Textprototyp: alle Screens vom Onboarding bis Dev-Modus | ⚠️ Video-Flow steht – Feed, Kopier-Screen und Ordner fehlen |
Noch nicht geschrieben: die eigentlichen Prompt-Texte (P1–P22). Recherchierte Vorlagen liegen für P5/P8, P7, P9 und P16 bereit (§8), für alle übrigen – inklusive P19–P22 – noch nicht. Ebenfalls offen: Code, UI-Design, Preismodell im Detail, Name, Prototyp-Screens für den Bild-Modus.
14. Naheliegende nächste Schritte
- P5/P8-Kern schreiben (Wan-Rewriter-Struktur + unsere Slots) und die 3–4 Modell-Adapter daraus ableiten – das ist der Kern des Produktversprechens.
- P9 (Video-Tagger) mit Enum-Schema + Code-Validator festlegen – ohne saubere Tags lernt die KB nichts.
- P7 auf Slot-System umbauen (bestehender Prompt) – trägt jetzt doppelt, weil er auch der Generator des Bild-Modus ist.
- Appwrite aufsetzen und das Schema aus
datenbank-aufbau.mdanlegen – inklusiveattribute_scores-Auftrennung von Anfang an (siehe Abhängigkeit in §12). - Elo-Function implementieren (deterministisch, gut testbar – guter erster Code), scope-bewusst.
- Nischen- und Typ-Tag-Enums festlegen – blockiert P19, P22 und die Kopier-Kompatibilität.
- Bildmodell auswählen – Kriterium ist Multi-Referenz-Komposition (Person + Produkt + Kulisse konsistent), nicht reine Bildqualität.
- Prototyp erweitern: Feed, Post-Detail, Kopier-Screen mit Slot-Chips, Ordner-Ansicht, Ordner anlegen (zwei Schalter).
- Entscheidungen nachziehen: Name, Preisstufen für beide Zielgruppen, Ads- **und Social-**API-Anträge starten.
15. Bild-Modus, Feed & Ordner (Zusammenfassung)
Vollständiges Konzept: konzept-bilder-feed.md. Hier nur, was man kennen muss, um den Rest des Dokuments richtig zu lesen.
Der Post
Ein Post ist kein Freitext-Prompt, sondern ein Slot-Rezept – nur deshalb ist er überhaupt kopierbar: Format (1:1 / 4:5 / 9:16) · Kulisse · Modelle (Person, Produkt) · Licht / Kamera / Farbe · Werbetext · Nische.
Dazu eine Bilderkette: mehrere Bilder, über die nur Position und Winkel variieren. Modelle, Kulisse, Licht, Farbe und Text bleiben konstant. Das Text-Overlay ist ein eigenes Bild in der Kette, keine Ebene auf dem Motiv – so lässt sich der Text tauschen, ohne die Motive neu zu generieren.
Veröffentlichen ist ein aktiver Schritt; Standard ist privat.
Kopieren
Der Original-Prompt wird analysiert (P19) und als vereinfachte Chips dargestellt: „Kulisse: Badezimmer, Morgenlicht", „Modell: kleine Kerze". Der Kopierer ersetzt die Modell-Chips durch eigene – Pflicht, nie die fremden – und kann Kulisse, Licht, Kamera, Farbe übernehmen oder ändern. Der Werbetext wird von der KI neu geschrieben (P21).
Die kritische Grenze: Der Kopier-Screen zeigt die Abstraktion, nie den Prompt im Wortlaut. Sonst wandert die Knowledge Base fremder Brands nach außen – gegen §4 und §9.
Modelle werden nie geteilt. Produkt-Modelle bilden echte Markenprodukte ab (Marken-/Designrecht); geteilte Personen-Modelle entwerten die Konsistenz. Fremde Modelle erscheinen nur als Beschriftung.
Ordner
Ein Ordner ist ein privater Wissens-Scope. Attribut-Scores werden je Attribut je Ordner geführt (attribute_scores). Beim Generieren zieht P4 nur die Attribute des gewählten Ordners – ein Ordner überschreibt die brand-weite Ebene vollständig, es wird nicht gemischt.
Er nimmt eigene und fremde Posts auf, ein Post darf in mehreren Ordnern liegen, und er wird vor der Generierung gewählt. Zwei Schalter beim Anlegen:
- Zweck:
sammlung(nur kategorisieren) ·wissens_scope(aus ihm heraus erstellen) - Startwerte:
erben(Kopie der brand-weiten Scores) ·aus_posts(nur was in den gesammelten Posts steckt)
Warum das der wichtigste neue Baustein ist: Der Feed erzeugt Konvergenz – alle kopieren dieselben Top-Posts, alle Ads sehen gleich aus. Der Ordner segmentiert das Wissen, statt es zu mitteln: statt eines Durchschnitts entstehen mehrere konkurrierende Wissensinseln. Damit kann man sich bewusst gegen einen Hype stellen, statt in ihm zu verschwinden.
Feed-Score – nicht Elo
| Elo (Knowledge Base) | Feed-Score | |
|---|---|---|
| Rankt | Attribute | Posts und Modelle (getrennt) |
| Scope | pro Brand, jetzt zusätzlich pro Ordner | global, gefiltert nach Nische |
| Sichtbar | nein | ja |
| Mathematik | echtes Elo (Paarvergleich, K-Faktor) | gewichtete Summe + Zeit-Decay |
| Signale | Vote, gezielte Frage, Ad-Performance, LLM-Vergleich | Views ×0,1 · Likes ×0,5 · Kopien ×1 · Social-Reichweite ×2 |
Elo braucht Duelle; im Feed wird summiert. Beides „Elo" zu nennen rächt sich im Code – deshalb getrennte Namen, Tabellen und Functions. Dazu drei Pflicht-Korrekturen: Zeit-Decay, Explorations-Slot für neue Posts, Manipulationsschutz.
Kopplung zur Knowledge Base
- Import beim Kopieren: Die Slots landen sofort als Attribute in der eigenen KB (Scope = gewählter Ordner). Das ist die Antwort auf den Kaltstart.
- Rückfluss nach Veröffentlichung: Läuft ein Post gut, steigen die beteiligten Attribute – ×0,3. Bewusst niedrig, weil Reichweite auch am Posting-Zeitpunkt liegen kann.
Diese Kopplung ist noch nicht final bestätigt – siehe konzept-bilder-feed.md §10.