diff --git a/machine-docs/JOURNAL-2.md b/machine-docs/JOURNAL-2.md
index 56b004f..8f14262 100644
--- a/machine-docs/JOURNAL-2.md
+++ b/machine-docs/JOURNAL-2.md
@@ -1161,3 +1161,38 @@ INTEGRATION PLAN (execute fresh):
    for the build-trigger pipeline. SMOKE-FIRST: manually deploy gitea→create OAuth app→deploy drone wired
    →confirm /healthz, before writing test code (nail the gitea CLI/API calls).
 This is the heaviest Phase-2 integration; budget multiple iterations. Hold deploys if Adversary active.
+
+---
+## 2026-05-29T22:4x — immich Q3.5 P4 decision: recipe-PR (add postgres backup), not N/A
+
+Resumed loop. Adversary checkpoint (REVIEW-2 `af94708`) confirms my own finding: immich's P4 restore
+is RED and unsigned. Root-caused it directly on cc-ci:
+- immich's `backupbot.backup` label sits ONLY on the `app` service, whose sole data volume `uploads`
+  is `backupbot.volumes.uploads=false` (excluded), and the two other excluded names (model-cache,
+  external_storage) aren't even on `app`. → app backs up nothing.
+- the `database` (postgres, DB_USERNAME=postgres/DB_DATABASE_NAME=immich) service has NO backupbot
+  label and NO pg_dump hook. → the postgres DB is NOT backed up at all.
+- No `abra.sh`, no top-level `configs:` section. So immich-as-published produces a backup containing
+  no restorable application data. My P4 ci_marker (postgres row) therefore cannot survive restore —
+  the test correctly detected a genuine, serious upstream deficiency (immich users get NO DB backup).
+
+**WHY recipe-PR over §7.1 N/A sign-off:** immich is THE object-storage/large-volume D10 category
+recipe — its entire purpose is storing user data. A P4-N/A here (unlike mailu's mail-relay N/A) would
+be hollow: the data path is exactly what must be proven to survive. cc-ci exists to catch precisely
+this class of bug; the recipe mirror+PR flow (§0b/§4.1) is the sanctioned mechanism, and the durable
+fix was already filed as the immich Q3.5 deferral. So: author a recipe-PR adding a `database`-service
+postgres backup (mirroring matrix-synapse's `/pg_backup.sh` config-mount + backupbot pre/restore
+hooks), then `!testme`/`RECIPE=immich PR=<n>` proves P4 green on the fixed recipe.
+
+**Reference pattern (matrix-synapse compose.yml):** db service `deploy.labels`:
+`backupbot.backup.pre-hook="/pg_backup.sh backup"`, `backupbot.backup.volumes.postgres.path="backup.sql"`,
+`backupbot.restore.post-hook="/pg_backup.sh restore"`; `configs: [{source: pg_backup, target:
+/pg_backup.sh, mode: 0555}]`; top-level `configs.pg_backup.file=pg_backup.sh`. The script: backup =
+`pg_dump -U $USER $DB | gzip > /var/lib/postgresql/data/backup.sql`; restore = drop+recreate+reimport.
+
+**immich-specific risk to validate empirically BEFORE the PR:** the postgres image is VectorChord/
+pgvecto.rs (custom extensions). A naive single-DB pg_dump|psql restore may choke on the vector
+extension and on the live immich-server's held connections. So I'm deploying immich (install) now and
+will test seed→dump→drop→restore→verify directly in the `database` container to pin down the exact
+dump/restore commands (likely `pg_dumpall --clean --if-exists` and connection-termination on restore)
+that round-trip the ci_marker, then bake the proven commands into pg_backup.sh. No "should work".