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"
|
|
|
|
|
|
status: open
|
|
|
|
|
|
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
|
2026-08-19 23:48:09 +02:00
|
|
|
|
fix_tracking: unset (railiance-platform to open)
|
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
|
|
|
|
|
|
disclosure: embargoed
|
|
|
|
|
|
embargo_condition: "a backup exists and a restore has been demonstrated once"
|
|
|
|
|
|
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
|
2026-08-19 23:48:09 +02:00
|
|
|
|
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"
|
Adaptive check cadence: the interval is earned, not assigned
Operator ruling 2026-08-20. Severity no longer sets the review interval.
A check that comes back clean climbs one rung — instant, 1h, 8h, 24h,
48h, 96h, 7d, 14d, 1mo, 1q — and anything wrong drops straight back to
instant. A quarter is the ceiling. The operator may defer an instant
finding to a stated date; that is the only other way off the bottom rung.
The rung is the point: it says how stable the estate has been on that
matter, which is information severity does not carry. Volatile things get
attention automatically; quiet things stop consuming it; neither
judgement has to be made by a person who might be busy.
Escalation trigger 5 rebased onto the ladder — fourteen days at the
bottom rung, whether that is failing checks or no checks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 07:43:51 +02:00
|
|
|
|
last_checked: "2026-08-19T23:05:00Z"
|
|
|
|
|
|
next_check: "2026-08-19T23:05:00Z" # due now: the ladder starts at instant
|
|
|
|
|
|
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
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
# 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.
|
