# Strict generation audit Wire `config.withAudit(new GenerationAudit())` with the native generation QBit and its optional `qqq-backend-module-rdbms` dependency. The adapter writes only `document_generation_event`, a visible immutable QQQ table owned by generation. It does not use Record Files privileges, tables or audit callbacks. Normal QQQ writes/deletes are denied; reads apply current source-record access, and aggregate/count shortcuts are refused. `append` opens a fresh independent JDBC connection, checks its database identity/writability/autocommit state, starts its own transaction, inserts the event and commits before returning. It never joins or replaces the caller's QContext transaction. A caller rollback cannot undo an acknowledged event. Database failure propagates; no log-only or in-memory fallback exists. Supported strategies are file-backed H2 with `WRITE_DELAY=0` and native MySQL 8.4 under the current physical engine/settings/mapping checks in [MYSQL.md](MYSQL.md). Unsupported strategies remain disabled; this QQQ backend does not support PostgreSQL. Owned statements have five-second JDBC deadlines. Each event binds the current initiating actor, selected source, committed generation request, revision, format and exact retained/print receipt fields. Outcome checks distinguish STARTED, RETAINED, DISPATCHED and INCOMPLETE facts; PRINT_QUEUED requires an actual persisted queue receipt and does not claim physical output. The operation ID and outcome form a database unique key. A length-prefixed SHA-256 fingerprint includes every event meaning except retry timestamp. An exact retry returns the existing committed event; changed meaning conflicts. A concurrent duplicate or ambiguous commit is reconciled through a fresh connection and acknowledged only if that exact event is durable. Apply the generated schema through the host migration process. Existing installations need the new event table/index and unique operation-ID constraint on requests. QBit registration does not execute DDL. Database service-account policy, filesystem/volume durability, backup/restore, retention and external administrative tamper controls remain deployment responsibilities. Application-level append-only behavior does not make a database administrator unable to alter a table. This is a synchronous audit ledger, not an asynchronous dispatch queue. Generation requests retain uncertain state after external failures. Worker scheduling, bounded batch progress, request reconciliation and retrying print dispatch are separate generation-owned workflows; the audit table must not be presented as implementing those workflows merely because it stores events. Current verification: full 109-test clean install passed 2026-10-31 00:45:47 CDT, including nine actual MySQL audit cases plus the H2 cases. Separate connections verify commit-before-return, ambient rollback independence, exact concurrent dedupe, failed inserts, request/stage conflicts, actual durability configuration and retained/queued recovery audit identity. Evidence: `mysql-full-verification.log`. Physical database/volume disaster recovery remains deployment work. The older 33-test reconciliation result is historical evidence, not the current test count.