## Problem/Motivation `audit_trail.id` is declared `serial unsigned`, which on MySQL and MariaDB is `INT UNSIGNED`: 4,294,967,295 rows. `docs/architecture.md` documents the ceiling as roughly 12 years at a million rows a day and plans the migration for 2.0. Two properties bring it closer than the raw number suggests. The id is a single sequence shared by every chain, so all chains draw on the same counter. And auto-increment never reuses a value, so archiving and live-purging reclaim table space but not numbers: the ceiling counts every row the site has ever written, not the rows it holds. The stated reason for deferring is that the schema migration is expensive on large tables. That is a cost of migrating existing installs, and there are none to migrate: the README states there are no update hooks before 1.0.0 and reinstalling is the supported way to move between releases. **It is not one column.** Nine further columns store an `audit_trail.id` value and are declared `int unsigned`, so they hold exactly the range the id was limited to and would fail on the first row past it: - `audit_trail_checkpoint.last_id` - `audit_trail_acknowledgment.from_id`, `audit_trail_acknowledgment.to_id` - `audit_trail_segment.from_id`, `audit_trail_segment.to_id` - `audit_trail_segment.transient_purged_event_id`, `archived_event_id`, `live_purged_event_id`, `file_purged_event_id` Widening the id alone would leave a chain the writer can extend and the readers cannot name. `audit_trail_outbox.id` is a sequence of its own on the same write path, never reused either, and belongs with them. The change is cryptographically inert. `id` is not in `ChainPayload::COLUMNS`, so no row hash or HMAC is computed over it. It is not among the values `SegmentSignature::computeArchiveContentHmac()` signs. Archives record ids as values and those values do not change. Nothing that has to keep verifying depends on the column's width. The cost is storage: the primary key goes from 4 bytes to 8, and InnoDB carries the primary key inside every secondary index. `audit_trail` has one unique key and seven secondary indexes, so roughly 32 additional bytes of index per row, against rows carrying JSON payload columns. ## Proposed resolution Declare every column above at `big` size. Rewrite the id-ceiling section of `docs/architecture.md` and drop the roadmap bullet that describes this as a 2.0 migration. The three remaining serials (`audit_trail_checkpoint.id`, `audit_trail_acknowledgment.id`, `audit_trail_segment.id`) stay 32-bit: they take one row per verify, per acknowledgment and per archived range, which is orders of magnitude below the event stream. ## Remaining tasks None. The merge request is up and its pipeline is green. Measured on MariaDB over 200,000 rows carrying the module's own average payload: data 260.77 to 260.83 MB, indexes 60.33 to 70.44 MB (+16.8%), whole table 321.10 to 331.27 MB (+3.2%). Keeping only the two load-bearing indexes it is +10.7% on indexes and +1.1% on the table. No read or write timing difference was measurable. `docs/architecture.md` carries the breakdown and the per-volume figures, and says that retention rather than schema is the lever for database size. ## User interface changes None. ## API changes None. ## Data model changes Eleven columns widen from 32-bit to 64-bit. No update hook, per the pre-1.0 policy stated in the README. AI-Generated: Yes (Claude Code was used to help draft this issue summary, and to write the change and its test on the merge request. I reviewed and ran the work myself before posting it.)