Companions Before the Record
A landing event often references companion artifacts: the materialized brief, reviewer requests and outputs, reconciliation, and perhaps a destination receipt. The event should become canonical only after those targets are durable. Otherwise one successful append can point forever at a file that never saved.
The safe order is prepare, validate, persist companions, then append or commit the landing record under one serialized operation. If companion persistence fails, no landed event is emitted. If the final event fails, the unreferenced companions can be retried or garbage-collected according to explicit policy.
File and database atomicity cannot always share one transaction. Design a staging protocol: write companions to final immutable names or a temporary area, verify digests, then move or mark them ready before the canonical append. The trail records identifiers rather than fragile process-local paths.
Idempotency matters during retry. A repeated landing request should resolve the same companion identities and avoid duplicate events. Stable content-derived or delegation-derived keys make recovery predictable.
No Dangling Proof
Inject failure after each landing step. After every failure, inspect whether canonical history can reference a missing target or whether a retry creates duplicates. Fault injection reveals ordering promises a happy path hides.
Serialize the final transition through one writer. Companion preparation may happen earlier, but the moment status becomes landed and references become visible must have one owner.