Operator decisions on RISK-F-0006 and RISK-F-0007

F-0006: backup spend approved, no ceiling stated. Permission is no longer
the blocker; the embargo still needs a demonstrated restore.

F-0007: pragmatic default before production — accepted (not closed, keeps
its severity, review interval and production re-score, stays visible in
the register), with a written on-request path so a named consumer
boundary can be verified when someone asks. The acceptance expires at the
production transition, which is an event and not a date.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

findings/RISK-F-0006-apps-pg-no-backup-configured.md

@@ -11,7 +11,7 @@ date_filed: "2026-08-19"
 system: railiance-platform
 environment: production
 fix_owner: railiance-platform
-fix_tracking: unset
+fix_tracking: unset (railiance-platform to open)
 related: [RISK-F-0001]
 # Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
 severity: high
@@ -24,9 +24,13 @@ disclosure: embargoed
 embargo_condition: "a backup exists and a restore has been demonstrated once"
 embargo_since: "2026-08-19"
 embargo_review: "2026-09-18"
-escalation: required
+escalation: answered
 escalation_trigger: 3
-escalation_status: pending-operator
+escalation_status: approved
+escalation_answered: "2026-08-19"
+escalation_answered_by: the-custodian
+escalation_act: approve
+decision: "spend for apps-pg backup storage approved; no ceiling stated"
 last_reviewed: "2026-08-19"
 review_by: "2026-09-18"
 graded_by: risk-nexus
@@ -86,3 +90,26 @@ error as the gate in `RISK-F-0002`.
 - **2026-08-19** — filed and graded from `RISK-F-0001`'s unfiled list.
   Open at review: has the spend been ruled on; is a backup configured; has a
   restore been demonstrated; does `railiance-platform` track it anywhere.
+
+## Operator decision — 2026-08-19: approved
+
+The spend is approved. `railiance-platform` may provision backup storage for
+`apps-pg` without returning for authorisation.
+
+No ceiling was stated, so none is recorded. The register asks
+`railiance-platform` to report the actual target and its monthly cost once
+chosen; a figure materially above the trigger-3 band (recurring €50/month)
+comes back for confirmation rather than being assumed covered. That is the
+register being careful with an open approval, not a condition on it.
+
+**What is now blocking is work, not permission.** The finding stays `open` at
+`high`, and the embargo condition is unchanged: a backup exists **and** a
+restore has been demonstrated once. A backup nobody has restored from is a
+claim, not a control.
+
+`fix_tracking` is still `unset` and is now `railiance-platform`'s to open.
+
+## Reviews
+
+- **2026-08-19** — escalation answered, spend approved. Open at review: is a
+  backup configured; has a restore been demonstrated; what does it cost.

findings/RISK-F-0007-unverified-tenant-boundary.md

@@ -2,7 +2,7 @@
 id: RISK-F-0007
 type: finding
 title: "No consumer's tenant boundary is verified anywhere"
-status: open
+status: accepted
 reported_by: net-kingdom
 reported_via: risk-nexus
 routed_by: risk-nexus
@@ -10,7 +10,7 @@ date_reported: "2026-08-19"
 date_filed: "2026-08-19"
 system: estate
 environment: build
-fix_owner: unset
+fix_owner: per-consumer, on request
 fix_tracking: unset
 related: [RISK-F-0004, RISK-F-0005]
 # Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
@@ -24,9 +24,16 @@ disclosure: embargoed
 embargo_condition: "a verification exists for at least one consumer boundary"
 embargo_since: "2026-08-19"
 embargo_review: "2026-09-18"
-escalation: required
+escalation: answered
 escalation_trigger: 4
-escalation_status: pending-operator
+escalation_status: assigned
+escalation_answered: "2026-08-19"
+escalation_answered_by: the-custodian
+escalation_act: assign
+accepted_by: the-custodian
+accepted_on: "2026-08-19"
+accepted_until: "production transition (hard expiry, not a date)"
+decision: "pragmatic default before production — carried unverified; verification of a named consumer boundary on request"
 last_reviewed: "2026-08-19"
 review_by: "2026-09-18"
 graded_by: risk-nexus
@@ -97,3 +104,52 @@ better than a routed one nobody agreed to.
 - **2026-08-19** — filed and graded. Open at review: has an owner been named;
   have any further instances been found; is the Tenancy Posture question still
   open.
+
+## Operator decision — 2026-08-19: pragmatic default, tighter control on request
+
+The custodian ruled: **before production, carry it.** Verifying every
+consumer's tenant boundary is not attempted as a programme now; a named
+boundary is verified when someone asks for it.
+
+The finding moves to `accepted` — which in this register is not `closed`. It
+keeps its severity, its review interval and its production re-score, and it
+stays in `REGISTER.md` where an accepted risk is supposed to be visible while
+it is being carried.
+
+**The acceptance expires at the production transition, and that is an event,
+not a date.** `production_rescore` is `true`: at production the same defect is
+`I4` × `L3` — `critical` — and the acceptance does not survive it. Nobody has
+to remember; `make check` lists it under what is owed at that transition.
+
+### The on-request path
+
+So that "on request" is a mechanism and not a sentiment:
+
+- **Who may ask** — any repo that consumes or is consumed by another, the
+  operator, or an outside counterparty through the operator.
+- **What they get** — verification scoped to one named consumer boundary, not
+  a general audit. The request names the consumer and what would have to be
+  true.
+- **Who does it** — the owning repo of that consumer. This register scopes and
+  records; it does not verify, and it does not fix.
+- **What it produces** — a dated verification record here. If the boundary
+  holds, that is evidence and this finding's likelihood falls for that
+  consumer. If it does not, that is a finding of its own with its own owner,
+  filed normally.
+
+Requests arrive as a message to `risk-nexus` and appear in the register within
+one review cycle.
+
+### What the register keeps saying while this is carried
+
+The two-for-two record stands: every repo that has looked at its own boundary
+this month found a defect (`RISK-F-0004`, `RISK-F-0005`). The acceptance does
+not make that less true, and this finding is the place it stays visible. If a
+third instance arrives, the pragmatic default is worth re-taking before
+production rather than at it.
+
+## Reviews
+
+- **2026-08-19** — escalation answered, accepted until production with
+  verification on request. Open at review: any request received; any further
+  instances found; whether production is close enough to re-take the default.