diff --git a/machine-docs/REVIEW-2.md b/machine-docs/REVIEW-2.md
index d5ab3f4..853ec81 100644
--- a/machine-docs/REVIEW-2.md
+++ b/machine-docs/REVIEW-2.md
@@ -1495,3 +1495,50 @@ a postgres-backup recipe-PR rather than §7.1 sign-off). No `drone` volumes rema
 Still no gate CLAIMED awaiting Adversary; `/etc/timezone` still absent → drone Q4.10 still operator-blocked.
 I'll cold-verify immich P4 when the Builder claims the recipe-PR green (the open P4-restore gap stays
 unsigned until then).
+
+---
+## Q3.5 immich — PASS @2026-05-30T~00:35Z (COLD, first-hand, my clone /root/adv-verify @origin/main)
+Re-ran the FULL harness myself cold: `RECIPE=immich PR=1 REF=a846cf38 SRC=recipe-maintainers/immich
+cc-ci-run runner/run_recipe_ci.py` from my own clone. Log `/root/adv-immich-cold.log`. This gate closes
+the P4-restore RED I myself flagged (BACKLOG-2 Q3.5) — the Builder fixed it via recipe-PR (the stronger
+route), not a §7.1 sign-off. **All 5 tiers + 3 custom GREEN; deploy-count=1; clean teardown.**
+
+- **RUN SUMMARY:** `deploy-count = 1 (expect 1)`; install/upgrade/backup/restore/custom **all pass**.
+- **P4 (headline crux) — restore PASSED.** `tests/immich/test_restore.py::test_restore_returns_state
+  PASSED` — the postgres `ci_marker` survives the recipe's real backup→restore. The test is
+  **non-vacuous**: `ops.pre_restore` `DROP TABLE ci_marker` AND asserts `to_regclass=NULL` (the drop
+  took) before restore; so a no-op restore would FAIL. `test_backup_captures_state PASSED` (marker=
+  `original` at backup time). The DB genuinely round-trips through `abra app backup`/`restore`.
+- **Recipe-PR is a REAL fix (audited the checkout `~/.abra/recipes/immich` @ a846cf3).** `pg_backup.sh`
+  does `pg_dump | gzip` on backup and on restore terminates connections → `DROP DATABASE WITH (FORCE)`
+  → `createdb` → `gunzip | psql -1 -v ON_ERROR_STOP=1`. `compose.yml` adds the `database`-service
+  backupbot pre-hook(`/pg_backup.sh backup`)/post-hook(`/pg_backup.sh restore`)/`volumes.postgres.path
+  =backup.sql` + the `pg_backup` config mounted at `/pg_backup.sh`. `abra.sh` PG_BACKUP_VERSION=v1.
+- **Negative control — confirmed STATICALLY.** The published parent commit `7eb3937` (1.6.0+v2.7.5) has
+  **NO backupbot labels on the `database` service**, and the `app` service excludes all its volumes
+  (`backupbot.volumes.{model-cache,uploads,external_storage}=false`) → the published recipe backs up no
+  DB → a restore yields an empty DB (the silent total-metadata-loss bug). The PR (`a846cf3 fix(backup):
+  back up the postgres database (was unprotected)`) is exactly the repair. (Did not need a separate
+  PR=0 deploy: the bug is provable from the diff + the non-vacuous test design.)
+- **Upgrade — real crossover (HC1).** `upgrade→PR-head: head_ref=a846cf38 chaos-version=a846cf38
+  version=1.5.1+v2.6.3→1.6.0+v2.7.5` (head_ref==chaos-version). Genuine prev→PR-head, not a no-op.
+- **P2 parity:** `health_check.py`→`functional/test_health_check.py` (PASSED). `oidc_login.py` non-port
+  justified (authentik-specific; operator SSO policy = keycloak default, immich OIDC optional; the §4.3
+  asset flow uses immich's first-run local admin, no SSO) — documented in PARITY.md. Accepted.
+- **P3 — 2 SEPARATE non-vacuous functional tests (both PASSED):** `test_asset_upload` (upload `POST
+  /api/assets` → read-back id+type IMAGE → poll `GET .../thumbnail` for the generated derivative) +
+  `test_asset_processing` (a DISTINCT microservice path: poll `exifInfo` until metadata-extraction
+  populates 1×1 dims, then `GET /api/assets/statistics` images/total≥1). Real app-state assertions,
+  not 200/health stand-ins. Distinct code paths (storage+thumbnailer vs metadata-extraction+catalog).
+- **P5/P6 — N/A justified.** immich self-contained (no deps); characteristic behaviour covered via the
+  API (upload/derivative/metadata/catalog), no browser-only UX owed.
+- **Teardown:** post-run `docker stack ls`→no `immi-*`; no `immi-*` volumes or secrets. Clean.
+
+**Verdict: Q3.5 immich PASS.** Full lifecycle GREEN cold, deploy-count=1, real upgrade crossover, the
+P4 data-integrity gap is genuinely closed by a real pg_dump-based recipe-PR (the restore test is
+non-vacuous and the published-recipe bug is statically confirmed), 2 distinct non-vacuous P3 tests,
+clean teardown. **The previously-OPEN Q3.5 P4-restore RED is CLOSED.** No `## VETO`.
+
+**Isolation note:** verdict formed from the plan + code (ops/test_backup/test_restore + the 2 functional
+tests + recipe-PR `pg_backup.sh`/`compose.yml`) + the STATUS claim verification info + my own cold
+full-lifecycle re-run + direct recipe-checkout inspection. JOURNAL-2 not consulted before this verdict.