Sources — Rohmaterial im Zwei-Ebenen-Modell

Sources sind die ungekürzte Wahrheit: Meeting-Transkripte, Emails, Dokumente, Chat-Verläufe. Destillierte Brains (projekt/kunde/knowledge) sind die lesbare Erinnerung — kurze Bullet-Points mit Zitaten zurück zur Source.

1. Warum zwei Ebenen?

Ohne Trennung entweder:

  • Brains werden unlesbar weil Transkripte + Emails drin landen → niemand findet mehr was
  • Oder Brains werden ohne Quellen destilliert → Behauptungen ohne Verankerung, Hallo-Halluzination

Mit Trennung:

  • Source (category: source) — ungekürzter Rohtext, schwer zu lesen aber vollständig
  • Destilliertes Brain — 3–5 Bullet Points pro Source-Section, mit sources: [...]-Feld im Frontmatter als Provenance-Link
  • Volltext-Suche findet beides; die Antwort kann beim destillierten Brain bleiben und nur bei Bedarf die Source öffnen

2. Schema-Regeln

Siehe SCHEMAS.md für die komplette Referenz. Kurz:

Pflichtfelder auf source:

  • type ∈ meeting | email | transcript | document | chat | call
  • date ISO YYYY-MM-DD

Optional:

  • customer (Brain-ID eines Kunden)
  • project (Brain-ID eines Projekts)
  • attendees: [], duration_min, location, channel

Body = Rohtext 1:1. Keine Kürzung, keine Umformulierung.

Optionales sources[]-Feld auf projekt, kunde, knowledge — listet Source-Brain-IDs die diese Destillation bezeugen.

3. Drei Wege, eine Source anzulegen

(a) Web-UI /new?category=source

  • Typ-Dropdown, Datum-Picker, optional Kunde + Projekt, Teilnehmer-Liste
  • Body-Textarea für den Rohtext
  • Path wird aus Titel auto-slugifiziert

(b) Assistent (Web) oder MCP-Agent (Maniak, Claude Code, ...)

Der User paste einen Roh-Text in den Chat mit kurzem Kontext:

"Hier das Nori-Standup vom 20.4. — bitte zu kuble.projekt.nori-v3 ergänzen:

[voller Transkript-Text]"

Der Agent führt die Zwei-Ebenen-Regel aus (eingebaut in System-Prompt + MCP-Server instructions):

  1. brain_write Source anlegen mit category: source, type: meeting, date: 2026-04-20, Body = 1:1 Rohtext
  2. brain_write Target-Projekt updaten:
    • Body: neuer Abschnitt ## Meeting 2026-04-20 mit 3–5 Bullet Points (Entscheidungen, Action Items, Blocker)
    • Frontmatter: sources[] um die neue Source-ID erweitern (bestehende Einträge erhalten)
  3. Antwort: "Source angelegt als <id>, Projekt-Brain um X Bullet Points ergänzt."

Niemals Rohtexte direkt in projekt/kunde/knowledge-Brain-Bodies.

(c) CLI / direct-MCP

gts add --id kuble.source.ai-marketing-2026-04-20 \
        --title "AI im Marketing Webinar" \
        --type transcript --date 2026-04-20 \
        --customer kuble.kunde.kuble --body-file transkript.md

4. UI-Behandlung

  • Sidebar → eigener Eintrag „Sources"
  • /sources — dedizierte Liste mit Filter nach Typ/Kunde/Projekt, Volltext-Suche, sortiert nach date absteigend
  • /brains-Filter — Sources werden aus „Alle" ausgeblendet (Rausch-Schutz), nur mit explizit aktiviertem Filter sichtbar
  • Brain-Detail-Seite (projekt/kunde/knowledge) — sources[] erscheint im Frontmatter-Block als klickbare Liste von Links zu den Source-Detail-Seiten

5. Löschen

Source-Delete ist blockiert, solange eine Brain in sources[] auf die Source zeigt. UI listet die referenzierenden Brains + deaktiviert den Delete-Button. User muss erst:

  1. In jedem referenzierenden Brain die Source-ID aus dem sources[]-Array entfernen, ODER
  2. Die referenzierenden Brains selbst löschen

Analog zu kunde-Delete-Schutz.

6. Sync

Sources syncen standardmäßig NICHT zwischen Personal ↔ Business. Grund: Meeting-Transkripte können sensitive Inhalte haben (Salary-Diskussionen, private Einschätzungen).

Opt-in pro Source via sync-Frontmatter wie bei anderen Brains. Selektiv syncen macht selten Sinn — entweder die ganze Source oder gar nicht. Empfehlung: mode: mirror wenn Sync gewollt.

7. Retrieval — Q&A mit Sources

Die /ask-Seite (Q&A-Modus) nutzt standardmäßig destillierte Brains als Antwort-Quelle. Wenn der destillierte Inhalt dünn ist aber sources[] eingetragen ist, liest der Agent die Sources für Original-Zitate. Antworten zitieren dann sowohl das destillierte Brain als auch die verwendeten Sources.

8. Typische Patterns

Meeting-Protokoll:

source: kuble.source.projekt.nori-v3.2026-04-20-standup
  type: meeting, date: 2026-04-20, attendees: [gustavo, roger, olivia]
  body: voller Transkript-Text

projekt: kuble.projekt.nori-v3
  sources: [kuble.source.projekt.nori-v3.2026-04-20-standup, ...]
  body:
    ## Meeting 2026-04-20
    - Entscheid: UI-Refactor auf v3-Design im Mai
    - Blocker: Payment-Provider antwortet nicht
    - Gustavo übernimmt Follow-up bei Stripe bis 2026-04-22

Kunden-Email eingegangen:

source: kuble.source.kunde.axa.2026-04-20-email-quote
  type: email, date: 2026-04-20, customer: kuble.kunde.axa
  body: voller Email-Text inkl. Header

kunde: kuble.kunde.axa
  sources: [kuble.source.kunde.axa.2026-04-20-email-quote, ...]
  body:
    ## Inbound 2026-04-20
    - Axa fragt Angebot für Team-Schulung Q3 (20 Personen)
    - Fragt explizit nach MAS-Zertifikat

Knowledge-Artefakt aus mehreren Quellen:

source: kuble.source.transcript.llm-training-whitepaper-2026
source: kuble.source.meeting.academy-review-2026-04-10

knowledge: kuble.knowledge.llm-training-best-practices
  sources: [... beide obigen ...]
  body:
    ## Overview
    - synthese aus beiden quellen, mit expliziten inline-zitaten