publication_subtitle: "The estate retains personal data in audit records on grounds nobody had actually established. Published as a question, because it is one."
decision: "identity in audit records: opaque subject ids preferred, agent identifiers where possible, operator credentials only where necessary, policy decisions tracked to the responsible party; zone-level privacy guarantees may raise the floor"
outstanding: "a defensible retention period per category (waits on audit-core's co-residency horizon), and the trigger list for buying an external answer"
## 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.
- **2026-08-20** — not clean: The determination now exists: RISK-REG-0001 states the grounds per category and names duration as the weak point. Cadence instant → instant; checked again immediately.
## Operator decision — 2026-08-20: no external determination, and a policy set instead
Ruled: **the estate will not buy an external determination while it is
building.** The internal determination (`RISK-REG-0001`) stands as the recorded
position, and the finding moves to `accepted` — deliberately carried, with a
named accepter and a condition that ends it.
That is not the same as the trigger list being rejected. The triggers survive
as what ends the acceptance: a real person's data, or a counterparty requiring
a stated position. What was declined is spending money in advance of either.
**The compensating control is the thing that makes this defensible.** Rather
than defer the question, the operator directed that the estate **define and
keep a set of legal policies for reuse**, because future work contexts will
need specific positions in place and should retrieve them rather than research
them.
`docs/regulatory/policies/` now catalogues thirteen, keyed by activation
condition. Two of them turned out to be **already active and unowned**:
commercial and tax retention (`RISK-POL-0009`), and the e-invoicing receiving
obligation (`RISK-POL-0012`), live since 2025 with no system in the estate
named as the receiving point.
Finding an unnoticed live obligation in the first hour of building the
catalogue is the argument for having built it. The reason this repo exists is
that regulation was previously "consulted and discarded"; a set that answers
"what applies if we do X" before anyone does X is the opposite of that.
**Still open under the acceptance**, and unchanged by this ruling: `audit-core`
on whether a keyed commitment restores erasability, and the `platform-pg`
co-residency horizon that decides whether the stated retention periods are
achievable. An accepted risk still gets checked.
- **2026-08-20** — not clean: Trigger list ruled: no external determination in build mode; accepted with the legal policy set as the compensating control. Cadence instant → instant; checked again immediately.
