## Problem Four caller-supplied values reach columns narrower than a caller has to know about: `channel` (64), `action` (64), `resource` (255) and `correlation_id` (128). The writer cuts each to fit rather than failing the write, which is the right call: failing takes down the operation being recorded, which is what #3620337 fixed for `channel`. Three of those four are in `Chain\ChainPayload::COLUMNS`, so the **cut value is the one that gets signed**. The row verifies perfectly while recording something the caller never supplied, and nothing anywhere says so. For a log that is a rounding; for a tamper-evident trail it is the signature vouching for a value that was never sent. `resource` is the sharp end, because it is the field that says what the event was about. `audit_trail.install` documents bridges writing `entity:<type>/<id>`, `webdav:<path>`, `system:<event>`. A WebDAV path over 255 characters is cut, signed, and the record now names a different file. `AuditTrailEntriesController::buildEntityRefFromResource()` parses that column back into an entity reference, so the detail page can resolve it to the wrong thing or to nothing. Knowing only *that* a value was cut does not recover it. For `resource` the evidence is gone. ## What changes When the writer cuts a value it preserves the original in the row's permanent context, under a writer-owned key, beside the two that already live there (`_audit_trail_write_mode` and `_audit_trail_rolled_back`): ```json {"_audit_trail_shortened": {"resource": "webdav:/the/full/original/path/..."}} ``` Keyed by column, and written only for a column that overflowed, so a row where everything fit carries no such key and a site where nothing is ever too long pays nothing at all. It is signed with the rest of the permanent bucket, never purged, and carried into the archive. That bucket is a `text` column that is never purged, so the preserved original is capped, or this moves the unbounded string one column over. `shortened_original_length` is that cap, in characters: a site-wide default of `1024`, deep enough for a long file path, with a per-chain override. `0` preserves nothing, which is what the module did until now. The cap is judged per column: a column is recorded only when the cap exceeds that column's own width, since a prefix of what the row already carries says nothing new. Both forms refuse anything from `1` to `255`, because a form is filled in long before anyone knows which column a future entry will overflow, and below 255 nothing at all is recovered for `resource`. The writer takes the cap as `?int $shortened_original_length`, so it gains no knowledge of chain configuration: a caller that already holds a chain passes that chain's figure, and `NULL` means the site's. The site default is read only on a write that actually had to cut something, so an ordinary write pays no configuration read for it. ### The writer's keys are the writer's The permanent bucket is signed raw and never purged, and a caller reaches it through `_audit_trail_permanent`, a contributor through its `permanent` output. Either could use one of the three names the writer stamps its own statements under, and the row would then carry a signed claim the module never made, including a forged `_audit_trail_shortened` offered as the evidence of what a cut value really was. The writer claims all three names and strips them from the bucket it is handed, the way the `audit_trail` context key is claimed on the ingress side (#3620330). ## Not in scope `correlation_id` sits outside the signed column set, so a cut one was never signed and an operator can still fill the column in afterwards. #3620337 bounds `channel` correctly and needs no change; this builds on it rather than revising it. AI-Generated: Yes (Claude Code was used to write this change and to draft this issue. I reviewed all of it.)