# NOTION SAFETY BRAIN — PROVENANCE MODEL & BACKUP MANIFEST (Mission 003)

Datum: 2026-08-25 · Red Queen · Status: **DESIGN (noch keine Implementierung)**

---

## 1. PROVENANCE-METADATEN-MODELL

Jedes zukünftige Notion-Backupobjekt trägt Herkunft erkennbar im Frontmatter/Properties:

| Feld | Typ | Beschreibung |
|---|---|---|
| `SOURCE_SYSTEM` | select | `forgejo` \| `tolaria` |
| `SOURCE_PATH` | text | Pfad im Quellsystem (Repo-Pfad / Vault-Pfad) |
| `SOURCE_OBJECT_ID` | text | Objekt-Identifikator (Dateiname / Git-Blob / Vault-Pfad) |
| `SOURCE_VERSION` | text | Git-HEAD / Vault-HEAD zum Sicherungszeitpunkt |
| `SOURCE_HASH` | text | SHA-256 des Quellinhalts |
| `SOURCE_UPDATED_AT` | date | Letzte Änderung der Quelle |
| `BACKUP_CREATED_AT` | date | Erstanlage im Notion-Safety-Brain |
| `BACKUP_UPDATED_AT` | date | Letztes Update des Backups |
| `BACKUP_RUN_ID` | text | ID des Backup-Laufs (z.B. NSB-YYYYMMDD-HHMMSS) |
| `CONTENT_TYPE` | select | `markdown` \| `note` \| `decision` \| `log` \| `adr` |
| `BACKUP_STATUS` | select | `current` \| `changed` \| `superseded` \| `source_missing` |
| `INTEGRITY_STATUS` | select | `verified` \| `unverified` \| `hash_mismatch` |

**Optional:** `FORGEJO_COMMIT`, `TOLARIA_VAULT_HEAD`, `RELATION_COUNT`, `LINK_COUNT`, `CLASSIFICATION`, `SENSITIVITY`.

## 2. BACKUP-MANIFEST (pro Lauf)

Ein Backup-Run erzeugt ein Manifest (Notion-Datenbank oder Seite):

| Feld | Beispiel |
|---|---|
| `BACKUP_RUN_ID` | `NSB-20260825-000001` |
| `TIMESTAMP` | ISO-8601 |
| `FORGEJO_HEAD` | `819fd8a` |
| `TOLARIA_HEAD` | `69aecf2` |
| `FORGEJO_OBJECTS_EXPECTED` | 30 |
| `FORGEJO_OBJECTS_BACKED_UP` | 30 |
| `TOLARIA_OBJECTS_EXPECTED` | 60 |
| `TOLARIA_OBJECTS_BACKED_UP` | 58 |
| `SKIPPED_OBJECTS` | 2 (unchanged) |
| `FAILED_OBJECTS` | 0 |
| `SECRET_BLOCKED_OBJECTS` | 0 |
| `HASH_STATUS` | `all_match` |
| `VERIFY_STATUS` | `verified` |
| `RESULT` | `BACKUP VERIFIED` |

> **Ein Backup ist NICHT allein deshalb erfolgreich, weil ein API-Write HTTP 200 lieferte.**

---

## 3. VERIFIKATIONSPRINZIP — WRITE ≠ BACKUP SUCCESS

Ein Backup-Lauf ist erst **erfolgreich**, wenn **alle** Punkte erfüllt sind:

1. **Daten geschrieben** wurden (Write = nur Schritt 1).
2. Red Queen sie **wieder aus Notion lesen** konnte.
3. **Quelle und Backup verglichen** wurden (Inhalt).
4. **Hash / Version / Manifest geprüft** (SOURCE_HASH == read-back hash).
5. **Anzahl erwarteter und gesicherter Objekte stimmt** überein.
6. **Fehler / Skipped Objects** dokumentiert.

Erst dann: **`BACKUP VERIFIED`**.

```
BACKUP RUN
  ├─ WRITE (Notion)
  ├─ READ BACK (Notion → RQ)
  ├─ COMPARE (SOURCE vs BACKUP)
  ├─ HASH / VERSION CHECK
  ├─ COUNT MATCH
  └─ ERROR / SKIP LOG
  →  BACKUP VERIFIED  (nur wenn alles grün)
```

## 4. DELETE-SAFETY (Provenance ergänzt)
- Objekt in Quelle verschwunden → **NICHT** aus Notion löschen.
- Status setzen: `SOURCE_MISSING` oder `SUPERSEDED`.
- Notion behält historische Information für den Disaster-Fall.