RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
---
id: RISK-F-0006
type: finding
title: "apps-pg has no backup configured at all: R0 means no recovery"
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
status: fixed
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
reported_by: railiance-platform
reported_via: flex-auth
routed_by: risk-nexus
date_reported: "2026-08-17"
date_filed: "2026-08-19"
system: railiance-platform
environment: production
fix_owner: railiance-platform
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
fix_tracking: RPF-WP-0019 (finished)
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
related: [RISK-F-0001]
# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
severity: high
severity_at_production: critical
impact: I4
likelihood: L2
fidelity_modifier: false
production_rescore: true
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
disclosure: public
publication: pending-handover
embargo_lifted: "2026-08-20 — backup live, restore demonstrated with matching row counts"
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
embargo_since: "2026-08-19"
embargo_review: "2026-09-18"
2026-08-19 23:48:09 +02:00
escalation: answered
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
escalation_trigger: 3
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
escalation_status: answered
date_fixed: "2026-08-20"
2026-08-19 23:48:09 +02:00
escalation_answered: "2026-08-19"
escalation_answered_by: the-custodian
escalation_act: approve
decision: "spend for apps-pg backup storage approved; no ceiling stated"
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
last_checked: "2026-08-21T07:32:09Z"
next_check: "2026-08-21T07:32:09Z"
cadence: instant
clean_streak: 0
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
graded_by: risk-nexus
ruling: RISK-RULING-2026-08-19-B
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
checked_by: "risk-nexus"
RISK-WP-0001-T07: rule on what was waiting outside the register
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:33:08 +02:00
---
# RISK-F-0006 — the platform database cannot be recovered
## What is true, as reported
`apps-pg` (`railiance-platform` ) has no backup configured at all: no
`barmanObjectStore` , no retention policy, and `BestEffort` QoS on the pod.
Reported in the same round as `RISK-F-0001` , whose author noted that `R0` here
means **no recovery** , not merely no erasure policy.
Not verified by this repo. `railiance-platform` owns it.
## Why it is graded highest of the round despite being the least exciting
The other findings in this round are about someone reaching something. This one
is about nothing coming back. There is no attacker in it and no clever step —
an ordinary node failure, a lost volume, a mistaken `DROP` , and the data that
was in `apps-pg` is gone.
`BestEffort` QoS makes the pod the first candidate for eviction under memory
pressure. Eviction alone is an availability event and recoverable. What is not
recoverable is anything that damages the volume, and that is the case with no
answer today.
## Register ruling — 2026-08-19
`high` today (`I4` × `L2` , non-adversarial reading), `critical` at production,
embargoed, and **escalated on trigger 3 (spend)** .
`I4` : `apps-pg` is shared platform infrastructure, so the loss is not confined
to one system, and it is unrecoverable rather than degraded. `L2` on the
non-adversarial reading the scale gained for this finding: irrecoverable loss
needs a volume or corruption event, which is an ordinary failure the estate
has seen the shape of but not an expected weekly occurrence.
`production_rescore: true` : at production this is `L3` , because the surface
area of ordinary operational events grows with real traffic and real operators.
**Escalation, trigger 3.** Object storage for backups is recurring spend that
is not currently committed, and no repo can authorise it for itself. The ask
is narrow: approve a backup target and its cost, or state that the estate
accepts running `apps-pg` with no recovery and for how long. The second is a
legitimate answer in build mode and needs saying out loud rather than
happening by default.
The disclosure condition deliberately includes a demonstrated restore. A
backup nobody has restored from is a claim, not a control — the same class of
error as the gate in `RISK-F-0002` .
## Reviews
- **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.
2026-08-19 23:48:09 +02:00
## 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.
2026-08-20 12:03:12 +02:00
- **2026-08-20** — clean check: checked against the inbox and the owner's record; nothing moved. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.
Five owner replies worked through: one fix closed, two grades corrected, one control retired
RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.
RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.
RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.
RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.
RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 09:32:32 +02:00
## Check — 2026-08-21: fixed, and the evidence was read rather than taken
`railiance-platform` finished `RPF-WP-0019` on 2026-08-20. This register read
their evidence file rather than accepting the report:
`railiance-platform/docs/evidence/RPF-WP-0019-backup-restore-2026-08-20.md` .
- Governed target live at `s3://railiance-platform-pg-backup/platform-pg/apps-pg/` ,
30-day retention, continuous WAL.
- `apps-pg-daily-20260820204148` completed in 8s, `LastBackupSucceeded=True` .
- **A separately named scratch cluster restored both consumer databases in 56s,
with exact database sizes and all 13 `coulomb_social` user-table row counts
matching.** The scratch namespace was deleted; production stayed `Ready` .
**The embargo condition required a demonstrated restore and got one.** That
condition existed because a backup nobody has restored from is a claim, not a
control — and the demonstration is the difference between this finding closing
and merely appearing to.
They also fixed something the grading had cited but not asked for: `apps-pg-1`
moved from `BestEffort` to `Burstable` QoS, with requests and limits, which was
part of why `L2` rather than `L1` . And their evidence records a failed first WAL
attempt against the wrong prefix rather than only the successful one, which is
the standard this register keeps asking of reporters.
`fixed` , `public` , escalation closed. The spend approved on 2026-08-19 has a
real target behind it.
- **2026-08-21** — not clean: owner replied; see the dated check section Cadence 1h → instant; checked again immediately.
