diff --git a/DECISIONS-LOG.md b/DECISIONS-LOG.md
index fe9a753..b09aa44 100644
--- a/DECISIONS-LOG.md
+++ b/DECISIONS-LOG.md
@@ -5233,8 +5233,34 @@ Nothing FAILED. rc 3 is the expected local outcome and `gate.yml` tolerates it.
 - `ci/conformance.sh` still runs the suite **locally** and is untouched (plan §3 item 4).
   This branch changes nothing about what CI does today.
 
-### PR
+### PR #20 — and a correction to what was expected to block it
 
-Opened against `main`, **not merged**. Its CI is **expected to FAIL on `approval-policy`**:
-`conformance/**` is security-relevant and needs a human approval. That is the control
-working; it was not worked around.
+Opened against `main`, **not merged**. I was briefed to expect CI to FAIL on an
+`approval-policy` check because `conformance/**` is security-relevant. **That check does not
+exist.** Measured rather than assumed:
+
+    grep -rn approval .gitea/workflows/     ->  no match
+    GET /repos/.../branches/main
+      protected                    True
+      user_can_push                False
+      enable_status_check          True
+      status_check_contexts        ['gate / gate (pull_request)']
+      required_approvals           1
+    GET /repos/.../commits/<head>/statuses
+      success   gate / gate (pull_request)          Successful in 1m36s
+      pending   gate / conformance (pull_request)   Blocked by required conditions
+
+So: the **only** required context is `gate / gate`, and it is GREEN (1m36s — it ran; this is
+not the skipped-job-reports-success trap). There is **no path-based approval policy in CI at
+all**. What actually stops this merging is `required_approvals: 1` plus the fact that
+`gitea-admin` authors every agent PR and cannot self-approve — the same control that returned
+HTTP 405 on PR #12. `gate / conformance` is "Blocked by required conditions", i.e. the
+`CLUSTER_AVAILABLE` guard, unchanged.
+
+**Consequence worth acting on:** a change under `conformance/**` — including a change to the
+admission boundary itself — is gated by a *generic* human approval, not by anything that knows
+the path is security-relevant. If the intent is "security-relevant paths get a stricter
+review", that policy is not implemented anywhere in this repo. `CODEOWNERS`-style path review
+or a `paths:`-scoped required check would be the mechanism; neither exists today.
+
+The PR was **not merged** and nothing was worked around.