Source Pack Persistence Decision & Schema Design

Source Pack Persistence

Diese Entscheidungsfläche hält fest, welche Source-Pack-Daten gespeichert werden dürfen, welche Daten blockiert bleiben und warum Persistenz Arbeitsstand statt Validierung bleibt.

Source Signal Intake Source Strategy Migration Plan Project Overview

Decision Foundation · keine Migration

Persistenz speichert Arbeitsstand, nicht Validierung

Source Packs werden inzwischen entlang der Hybrid-Minimal-Entscheidung vorbereitet. Diese Decision bleibt die fachliche Grenze: Persistenz speichert Arbeitsstand, nicht Validierung; Write API und Manual Create UI wurden spaeter separat entschieden, Handoff braucht weiter eine eigene Entscheidung.

Write API spaeter separat
Manual Create UI spaeter separat
kein Handoff
kein automatischer Candidate

Executive Decision

Schema-Entscheidung vor Migration

Recommended Minimal Path

Hybrid Minimal später prüfen

Empfohlen ist ein hybrider Minimalpfad: `source_packs` und `source_observations` als eigene Identitäten, flexible JSONB-Sections für Evidence Boundaries, Handoff Draft und qualitative Arbeitsstände. Das passt zur bestehenden Snapshot-/JSONB-Logik, ohne Source Packs mit Research Cases oder Candidates zu vermischen.

Entity Boundaries

Observation, Pack, Handoff, Candidate bleiben getrennt

Persistenz darf die fachliche Grenze nicht verwischen. Ein gespeichertes Source Pack ist kein Marktbeleg und kein Candidate.

Entity Boundary

Source Observation

Eine einzelne, kurze Beobachtung aus einer Quelle.

kein Proof

Darf speichern

sourceFamily
sourceContext
kurze eigene observation summary
signal types
allowed inferences
blocked inferences
missing evidence
next verification path
revenue boundary note

Darf nicht speichern / nicht wirken wie

lange kopierte Fremdinhalte
personenbezogene Daten ohne separate Entscheidung
private Kundendaten
raw scraped pages
unredigierte Community-Posts
personenbezogene Social-Kommentare
geheime oder lizenzierte Daten

Eine Observation beschreibt ein Signal. Sie ist kein Proof und keine Marktentscheidung.

Entity Boundary

Source Pack

Bündel mehrerer Observations zu einer Working Hypothesis.

kein Proof

Darf speichern

title
working hypothesis
target audience
possible offer shape
linked observations
strongest / weakest signals
missing evidence
blocked claims
recommended next step
revenue potential status

Darf nicht speichern / nicht wirken wie

validierter Markt
Launch-Freigabe
Umsatzbeleg
Score
Ranking
automatische Empfehlung

Persistenz speichert Arbeitsstand, nicht Validierung. Ein Source Pack bleibt eine Hypothese mit Evidence Boundaries.

Entity Boundary

Candidate Handoff Draft

Strukturierter Brief Richtung Offer Radar.

kein Proof

Darf speichern

candidate title draft
audience
problem
possible offer format
source-backed signals
assumptions
missing evidence
disallowed claims
recommended research next step

Darf nicht speichern / nicht wirken wie

automatische Candidate-Erzeugung
validierten Candidate
Umsatzpotenzial
Launch-Freigabe

Ein Handoff Draft erzeugt noch keinen Candidate. Er ist nur ein Brief für einen späteren expliziten Handoff-Flow.

Entity Boundary

Offer Radar Candidate

Separate Candidate-Hypothese im Main Path.

kein Proof

Darf speichern

nur über späteren expliziten Handoff-Flow
eigene Candidate-Herkunft
eigene Candidate-Grenzen
eigene Missing Evidence

Darf nicht speichern / nicht wirken wie

automatische Entstehung aus reiner Source-Pack-Persistenz
Validierung
Proof
Umsatz- oder Performance-Aussage

Ein echter Candidate entsteht erst durch eine spätere explizite Aktion. Source-Pack-Persistenz allein erzeugt keinen Candidate.

What to Store / What not to Store

Nur Signalzusammenfassung, keine Rohdaten-Sammlung

Growth OS speichert später Arbeitsstand und Grenzen. Rohdatenarchive, lange fremde Texte und personenbezogene Inhalte bleiben gesperrt.

May Store

Später speicherbar

sourceFamily
sourceContext
kurze eigene observation summary
signal types
allowed inferences
blocked inferences
missing evidence
next verification path
revenue boundary note
title
working hypothesis
target audience
possible offer shape
linked observations
strongest / weakest signals
missing evidence
blocked claims
recommended next step
revenue potential status
candidate title draft
audience
problem
possible offer format
source-backed signals
assumptions
missing evidence
disallowed claims
recommended research next step
nur über späteren expliziten Handoff-Flow
eigene Candidate-Herkunft
eigene Candidate-Grenzen
eigene Missing Evidence

Blocked Storage

Nicht speichern / nicht behaupten

lange kopierte Fremdinhalte
personenbezogene Daten ohne separate Entscheidung
private Kundendaten
raw scraped pages
unredigierte Community-Posts
personenbezogene Social-Kommentare
geheime oder lizenzierte Daten
validierter Markt
Launch-Freigabe
Umsatzbeleg
Score
Ranking
automatische Empfehlung
automatische Candidate-Erzeugung
validierten Candidate
Umsatzpotenzial
Launch-Freigabe
automatische Entstehung aus reiner Source-Pack-Persistenz
Validierung
Proof
Umsatz- oder Performance-Aussage

Schema Options

Drei mögliche Pfade, noch keine Migration

Die Optionen sind Design-Entscheidungen für einen späteren Migrationsblock. Keine DDL wird ausgeführt und keine Tabelle wird angelegt.

Alternative

Option B: JSONB-first

Eine kleine `source_packs`-Identität mit JSONB-Sections für Observations, Evidence Boundaries und Handoff Draft.

Vorteile

passt zur bestehenden Snapshot-/JSONB-Logik
schnell für MVP-nahe Arbeitsstände
weniger Tabellen und weniger frühe Modellhärte

Nachteile

schwächer für spätere Adapterfähigkeit
schwieriger für einzelne Observation-Lifecycle-Regeln
Handoff- und Observation-Grenzen können im JSONB zu weich werden

Wann sinnvoll

Sinnvoll, wenn Source Packs zunächst nur interne Arbeitsstände bleiben und keine externen Adapter schreiben.

Warum jetzt nicht bauen

Auch JSONB-first braucht zuerst Redaction-, Handoff- und Retention-Entscheidung.

Risiken

Freitext kann zu viel Rohdaten aufnehmen.
Validierungsgrenzen werden schwerer maschinenlesbar.

Alternative

Option A: stärker relational

`source_packs`, `source_observations`, `source_pack_observations` und `source_pack_handoff_drafts` als getrennte Tabellen.

Vorteile

klare Entity-Grenzen
besser für Adapter, Links und spätere Review-Logik
Observation-Reuse und Handoff-Status wären sauberer modellierbar

Nachteile

zu schwergewichtig für den aktuellen Foundation-Stand
mehr Migrationsfläche
frühe Tabellen könnten falsche Architekturentscheidungen zementieren

Wann sinnvoll

Sinnvoll, wenn mehrere Adapter, Wiederverwendung von Observations und echte Review-/Lifecycle-Logik unmittelbar gebraucht werden.

Warum jetzt nicht bauen

Noch fehlen Handoff-Flow, Redaction-Policy und konkrete Adapter-Anforderungen.

Risiken

Schema wirkt schnell wie produktive Wahrheit.
Zu viele Tabellen können den Main Path vor der Handoff-Entscheidung verkomplizieren.

Option C: Hybrid Minimal

`source_packs` und `source_observations` als getrennte Identitäten; Evidence Boundaries, Handoff Draft und flexible Arbeitsstände zunächst als JSONB-Sections.

konservativer Minimalpfad

Vorteile

saubere Trennung zwischen Pack und Observation
passt zur bestehenden JSONB-Snapshot-Praxis
genug Struktur für spätere Adapterfähigkeit
vermeidet frühe Handoff-Draft-Tabelle

Nachteile

braucht klare JSONB-Validierungsregeln
Handoff Draft bleibt zunächst eingebettet
spätere relationale Ausgliederung kann nötig werden

Wann sinnvoll

Sinnvoll als erster späterer Migrationsblock, wenn Source Packs gespeichert werden sollen, aber Handoff und Adapter noch nicht produktiv sind.

Warum jetzt nicht bauen

Dieser Task ist nur Decision Foundation; die Migration braucht einen separaten Plan mit Redaction- und Schema-Prüfung.

Risiken

JSONB-Sections dürfen nicht zu Rohdaten-Ablage werden.
Pack-Persistenz darf keine Candidate-Entstehung auslösen.

Recommended Minimal Path

Hybrid passt zur bestehenden JSONB-Logik

Das bestehende Datenmodell arbeitet bereits mit Research Cases und JSONB-Snapshots. Ein hybrider Minimalpfad hält Source Pack und Source Observation als eigene Identitäten getrennt, lässt aber Evidence Boundaries und Handoff Draft zunächst als flexible Sections.

Migration Readiness

Noch nicht migrationsbereit

Redaction-Regeln sind akzeptiert.
Source Pack, Observation, Handoff Draft und Candidate bleiben getrennt.
Minimalfelder sind final geprüft.
Handoff-Flow ist als separater späterer Block bestätigt.

Blocker

keine Retention-Policy
keine Handoff-Flow-Entscheidung
keine Adapter-Schreibgrenzen
keine finale Entscheidung zu JSONB-Validierung

Redaction & Data Quality Rules

Rohdaten werden nicht gesammelt

Source Pack soll Beobachtung beschreiben, nicht fremde Quellen archivieren.

Redaction & Data Quality Rules

Kurze eigene Signalzusammenfassungen

Rohdaten werden nicht gesammelt; gespeichert werden kurze eigene Signalzusammenfassungen.
Quellreferenz bleibt optional und kontrolliert.
Sensible Kundendaten brauchen einen separaten Consent-/Policy-Block.
Community- oder Social-Inhalte werden nicht unredigiert übernommen.
Lange fremde Originaltexte werden nicht gespeichert.
Spätere Adapter brauchen eigene rechtliche und technische Entscheidung.

Blocked Data

Nicht persistieren

personenbezogene Rohdaten aus Communities
private Kundendaten
lange kopierte Fremdtexte
raw scraped pages
lizenzierte oder geheime Daten
unredigierte Kommentare mit Personenbezug

Versioning Policy

Versionierung vor Überschreiben

Source Packs brauchen später einen Version- oder Snapshot-Mechanismus.
Änderungen an blocked claims, missing evidence und revenue boundary dürfen frühere Arbeitsstände nicht überschreiben.
Handoff Drafts brauchen eine eigene Version oder eingebettete Versionsnotiz.
Adapterdaten dürfen spätere manuelle Observations nicht stillschweigend ersetzen.

Evidence Boundary Policy

Evidence Boundary bleibt Pflicht

Jede persistierte Observation behält allowed und blocked inferences.
Revenue Potential Status bleibt qualitativ und ohne Zahlen.
Candidate Handoff bleibt getrennt von Candidate Creation.
Persistenz darf keine Validierungswirkung erzeugen.
Source Quality bleibt qualitative Notiz, nicht Score.

Data Retention

Minimal speichern, Rohdaten vermeiden.

Source Packs speichern Arbeitsstand und Grenzen, nicht Quellarchive.
Nicht mehr benötigte sensitive Referenzen sollten gar nicht erst persistiert werden.
Retention braucht vor echter Implementierung eine eigene Policy-Entscheidung.

Handoff Boundary

Persistenz erzeugt keinen Candidate

Ein Source Pack kann später einen Handoff Draft vorbereiten. Ein echter Offer-Radar-Candidate entsteht nur über eine explizite Aktion in einem separaten Handoff-Flow.

Handoff bleibt Brief

Source Pack → Handoff Draft → expliziter Candidate-Flow

Diese Entscheidung trennt gespeicherten Arbeitsstand, späteren Handoff-Brief und Offer-Radar-Candidate. Kein Persistenzschritt erzeugt automatisch einen Candidate.

keine automatische Candidate-Erzeugung

Source Pack bleibt Hypothese
Handoff Draft bleibt Brief
Candidate braucht expliziten Flow
keine Validierung
keine Umsatzberechnung

Open Decisions

Vor Migration noch zu klären

Diese Punkte blockieren keine Decision Foundation, aber sie gehören vor einen echten Migrationsblock.

Open Decision

Wird Handoff Draft zunächst im Source Pack gespeichert oder als eigene Entity?

Optionen

embedded JSONB im Source Pack
eigene Handoff-Draft-Tabelle

Empfehlung

Zunächst embedded JSONB, weil noch kein expliziter Handoff-Flow gebaut ist.

Open Decision

Dürfen Source References URLs enthalten?

Optionen

optional erlauben
zunächst nur Label/Notiz
nur nach Source-Family-Regel

Empfehlung

Optional, aber kontrolliert; keine personenbezogenen oder lizenzkritischen Rohdaten speichern.

Open Decision

Wie streng müssen JSONB-Sections validiert werden?

Optionen

nur TypeScript
runtime validation später
DB constraints später

Empfehlung

Für Migration Plan runtime validation entwerfen, DB constraints erst nach stabiler Feldlogik.

Not Built Yet

Dieser Block baut keine Persistenz

keine schreibende API in diesem Decision-Block
keine UI-Speicherung in diesem Decision-Block
keine Delete-API
keine Source-Pack-Handoff-Aktion
keine externe Integration
keine automatische Candidate-Erzeugung
keine Umsatzpotenzial-Berechnung

Next Build Block

Source Pack Minimal Persistence Migration Plan

Nächster sinnvoller Block ist ein Migrationsplan, nicht die Migration selbst: konkrete Tabellen-/JSONB-Felder, Validierungsregeln, Redaction-Prüfung, Handoff-Abgrenzung und Rollback-Hinweise vorbereiten.

Migration Plan ansehen