You Want Two Shapes and You Can Only Trust One
An append-only file per subject is a beautiful record: one process writes it, each record as a single append, so no half-written record of somebody else's can corrupt it; it merges without conflict because two subjects never touch the same file; it is readable by anything, and its history is its content. It is also useless for the questions you actually ask — how many passes of this kind ran last month, which units have no verification, what did this system produce across the corpus.
A relational store answers all of those instantly and is a much worse record. So you keep both, and the entire design rests on one decision made in advance: the file is the record, the store is a derived mirror.
Why Declaring It Beforehand Is the Whole Trick
Two stores holding the same facts will disagree eventually. A write that succeeded in one and failed in the other, a schema migration that dropped a column, a rebuild that ran against a stale copy. The disagreement is not the emergency — the emergency is discovering that nobody knows which one to believe, in the middle of the incident, with a decision needed now.
Declaring the authority in advance converts that emergency into an operation. Rebuild the mirror from the record. Ten minutes, no judgment calls, no loss of the record possible, because the mirror never held anything the record does not. One honest edge: a line of the record damaged so badly it no longer parses is skipped and named by the rebuild, not guessed at — and its row in the mirror goes with it. That is the rule working, not breaking: the mirror may only hold what the record can back. A strict mode refuses on damage instead, with the mirror still standing.
The rule that follows: nothing is ever written to the mirror that is not derivable from the record. The first time somebody adds a convenient column that exists only in the store, the mirror has become a second record and the rebuild is now destructive.
The Layout Choices That Bound the Damage
One file per subject rather than one big file, so a corrupted file damages one subject's history and no more. Note what that does not buy: the unit of work is the delegation, and several delegations against one subject share a file, so parallel work still lands in the same place and the append has to be safe on its own. Newline-delimited records, so appending is a single write and reading is streamable. And a rebuild that is idempotent, so it can be run at any time by anyone who is unsure — a repair operation people are afraid of is one that does not get run.
All three buy the same property: when something goes wrong, the blast radius is decided in advance. A corrupted file costs one unit, a disagreeing mirror costs one rebuild, a half-finished write costs the last line. The storage design worth choosing is usually not the fastest one but the one whose worst case is smallest.