This doesn't make sense to me-- if the regular tables don't capture the true state, then the audit tables based on them will not magically become a source of truth either.

Exactly. If they agree, then there was no point to introducing a second source of truth. If they disagree, then which one do you trust?

> Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables,

The regular table is the source of truth, the audit table is just a historical record of what changed and when.

So what do you do if a balance has $30 and the audit table shows two deposits of $20?

The same as if you didn't have an audit table and the balance was wrong. You declare some kind of incident and investigate until you find this critical bug. Hopefully you can use the audit trail to determine what the right answer is and fix everyone's balance.

How do you know which one to trust? By reading the code and figuring out what the bug is.

If you’re recording events as intent, then the event table is the source of truth and the state of the database is effectively snapshot of the state. In principle, you should be able to replay the events to produce the current state. If it calculates wrong, go fix your calculator, assume your events table isn’t wrong, and replay.

If you’re storing a log of database changes (what’s usually meant by an audit table), as in

(Table_Name, Column_Name, Old_Value, New_Value, Timestamp)

Then the database state is the source of truth, and the audit table is simply a record of changes ever occurred that reached that state.

In either case, there’s a single source of truth.