diff --git a/findings/RISK-F-0008-audit-retention-legal-basis-assumed.md b/findings/RISK-F-0008-audit-retention-legal-basis-assumed.md
index 5e30b1e..32fec65 100644
--- a/findings/RISK-F-0008-audit-retention-legal-basis-assumed.md
+++ b/findings/RISK-F-0008-audit-retention-legal-basis-assumed.md
@@ -126,3 +126,103 @@ and therefore has to be decided early or not at all.
 - **2026-08-19** — promoted from note, graded, escalated. Open at review:
   has the basis been established or the assumption recorded; has anything
   changed about what categories `audit-core` stores.
+
+## Suggested disposition — 2026-08-20, proposed by risk-nexus
+
+Offered because this repo owns the finding and the operator asked for a
+direction. It is not legal advice, and this repo cannot make it into one: what
+follows is a *route to an answer* and a hedge against the answer being no.
+
+### The reframe: the expensive thing is not the legal question
+
+`audit-core` asks whether the exemption holds. That question is cheap to
+answer badly and expensive to answer properly, and the temptation is to
+schedule the proper version and wait.
+
+But the cost of a "no" is not fixed — it grows daily. The remedy they name,
+encrypt-then-hash at accept time, cannot be retrofitted onto events already
+accepted. **Every day the estate accepts events under the current scheme, the
+un-erasable set grows by one day.** So the decision that actually needs taking
+now is not "is it exempt" but "do we keep manufacturing records we could never
+erase while we find out".
+
+That splits the finding into two decisions with very different prices.
+
+### 1. Establish the basis internally, now, for the cost of an afternoon
+
+Not a legal opinion — a **written determination** that says which ground is
+being relied on, for which category of data, and for how long. Today the
+estate has no such document; that is the whole finding.
+
+The shape it should take, per category of personal data in the audit trail:
+
+| Category | Likely ground | The part that is actually arguable |
+| --- | --- | --- |
+| Operator and agent identifiers | Art 6(1)(f) legitimate interest in security, with Recital 49 squarely on point | little — this is the ordinary case |
+| Counterparty or end-user identifiers in event payloads | Art 17(3)(e), defence of legal claims; Art 6(1)(f) | **duration**, not existence |
+| Commercial records that happen to pass through audit | Art 17(3)(b) plus German §257 HGB / §147 AO retention | scope — retention duties cover books and invoices, not application logs generally |
+
+Where such determinations usually fail is **not** the ground. It is the
+retention period: a blanket "we keep audit forever under legitimate interest"
+is much weaker than "we keep these fields for N months because X". That lands
+precisely on `audit-core`'s question 2 — the real horizon being the maximum
+across every co-resident on `platform-pg` rather than the declared value.
+
+Recording the determination converts an assumption into a position that can be
+argued with. That is what this register exists to produce, and it does not
+require a lawyer to write down.
+
+### 2. Stop the un-erasable set from growing — a cheaper hedge than the redesign
+
+`audit-core`'s stated obstacle is precise and correct: their chain commits to
+`SHA-256(cleartext)`, audit records are low-entropy, so the retained hash
+survives key destruction as a confirmation oracle. Guess, hash, compare.
+
+The oracle exists because the commitment is over cleartext with no secret in
+it. A **keyed commitment** removes it: replace the digest with an HMAC (or a
+hash over record plus a high-entropy per-subject salt) where the key or salt
+lives outside the audit store and is destroyable per subject.
+
+What that buys, and why it is cheaper than the redesign they costed:
+
+- Destroying the per-subject key makes the commitment untestable — no guess
+  can be confirmed. That is crypto-shredding restored, which their analysis
+  correctly found unavailable under a plain hash.
+- The integrity chain still verifies. It chains over commitment values, and
+  those persist after key destruction; what is lost is the ability to
+  re-derive a commitment from cleartext, which is exactly what erasure means.
+- It is a change at accept time only. No re-processing of stored events, no
+  new storage layer, no change to the read path.
+
+This is a suggestion to `audit-core`, not an instruction, and they own whether
+it is sound — they know their chain and this repo does not. The claim worth
+testing with them is narrow: **does a keyed commitment restore erasability
+without breaking chain verification?** If yes, the expensive redesign becomes a
+contingency rather than a plan, and the daily accrual stops.
+
+### 3. Buy the real answer only when something triggers it
+
+An external determination costs money and needs a real question. Propose three
+triggers, any of which fires it:
+
+- the estate first holds a real person's data;
+- a counterparty contract requires a stated erasure position;
+- an actual Art 17 request arrives.
+
+Until one fires, the internal determination plus the hedge is a proportionate
+posture, and `severity_at_production: high` plus `production_rescore: true`
+already guarantee this is re-read before production completes.
+
+### What this repo would record if the operator agrees
+
+`status: accepted` with the determination attached, `escalation` answered as
+`rule`, and the review kept at 90 days. The finding stays open and visible
+until the determination exists — an accepted risk with no written basis is the
+same assumption it started as, wearing a different word.
+
+### Also worth saying, because it is the cheapest fix of all
+
+Every field of personal data that never enters the audit trail is a field with
+no erasure question. Where an opaque subject identifier would carry the same
+evidentiary weight as a name or an address, the identifier is strictly better,
+and that is a `audit-core` design choice available today at no legal cost.