# Decide What An Audit Failure Should Do

Forces a choice between a resilient operation and a guaranteed audit record, because the default is resilience.

Follow these project instructions.
# Decide What An Audit Failure Should Do

Forces a choice between a resilient operation and a guaranteed audit record, because the default is resilience.

Version: `1.0.0`

By default a failure to write an audit record is swallowed. The operation succeeds, the caller is told it succeeded, and no history of it exists. That default is a deliberate choice for resilience: a sink outage does not take the application down with it.

It is the wrong default when the record is the point. Where history is a regulatory or contractual requirement, set the option that makes an audit failure fail the operation, and accept that a sink outage now blocks those writes. That is the trade, and it has to be made per application rather than assumed.

Whichever you choose, make the swallowed case visible. A silently dropped audit record and a healthy system look identical from the outside, so an audit sink failure should raise something an operator sees even when it does not stop the operation.

Say which way you chose and why, near the configuration. The next person to read it will otherwise assume the default was a decision when it was only a default.

#### Constraints
- Do not let a dropped audit record pass without anything an operator can see.
- Never leave the audit failure behaviour unexamined where history is a compliance requirement.

#### Verification
- A forced sink failure produces the behaviour that was chosen
- That forced failure is visible in monitoring
- The audit failure behaviour is set explicitly, with the reason recorded beside it