tegwick
d5147bfaea
The register had nine waits in four days, one four hops deep: F-0003's embargo waited on F-0009, which waited on railiance-platform, which waited on live OpenBao verification, which waited on a credential nobody has. No single link was wrong, which is why it needed a rule. docs/method/dependencies.md: the register never waits to decide, it decides and revises. Every wait carries who, what, since, what it would change, what happens if nobody answers, and the date that default applies. Depth one — a record never waits on a record that is itself waiting. Defaults are dates and are pessimistic: silence costs the grade the evidence supports rather than buying a softer one, and owners are told the default in advance because a default nobody was warned about is an ambush. Applied: F-0009's embargo now lifts on railiance-platform reporting coverage, with live verification as a refinement rather than a condition, cutting the F-0003 chain from four hops to two. All eight open waits are typed with defaults. make check reports them with age, owner and default date, flags defaults come due, and catches depth-two violations. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.1 KiB
| id | type | title | status | reported_by | reported_via | routed_by | date_reported | date_filed | system | environment | fix_owner | fix_tracking | related | severity | severity_at_production | impact | likelihood | fidelity_modifier | production_rescore | disclosure | embargo_condition | embargo_since | embargo_review | escalation | escalation_trigger | escalation_status | escalation_answered | escalation_answered_by | escalation_act | decision | last_checked | next_check | cadence | clean_streak | waiting_on | graded_by | ruling | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RISK-F-0006 | finding | apps-pg has no backup configured at all: R0 means no recovery | open | railiance-platform | flex-auth | risk-nexus | 2026-08-17 | 2026-08-19 | railiance-platform | production | railiance-platform | unset (railiance-platform to open) |
|
high | critical | I4 | L2 | false | true | embargoed | a backup exists and a restore has been demonstrated once | 2026-08-19 | 2026-09-18 | answered | 3 | approved | 2026-08-19 | the-custodian | approve | spend for apps-pg backup storage approved; no ceiling stated | 2026-08-20T10:02:42Z | 2026-08-20T11:02:42Z | 1h | 1 |
|
risk-nexus | 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; doesrailiance-platformtrack 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.
- 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.