Latest follow-up: Configuration and data qualification raises that category to 9.5/10 and the overall engineering assessment to 9.3/10. This reliability report remains the historical baseline.

Implementation changes

1. Remove the repeated history scan. Admission reads occurrence consumption from the locked account row. An AFTER INSERT trigger increments the counter transactionally. Duplicate inserts, rejected updates and rollback do not consume occurrences; releases keep replay and occurrence consumption.
2. Preserve migration integrity. An atomic backfill counts every retained state. Account-before-reservation locking matches writers, repeated migration never reduces consumption, and the trigger checks that exactly one account was updated, including under row-level security.
3. Require WAL acknowledgement. Migration, reserve and reconciliation use transaction-local synchronous commit while preserving remote_apply. This cannot repair disabled fsync, unsafe storage or missing replicas.
4. Make reliability evidence a gate. Seven named database tests and six checker tests protect execution and evidence. CI rejects missing scenarios, low throughput, excess latency, inconsistent state or incomplete recovery evidence and retains raw JSON and logs.

Ledger implementation · Migration, qualification and deployment runbook · Acceptance gate

Measured load and recovery

Both environments used 32 callers, four ledger objects and an eight-connection pool. The finite contention scenario accepted exactly 2,048 of 4,096 initial requests and 512 later requests after settlement/release. The sustained scenario directs 80% of work to one mandate. Both scenarios finish with zero balance/count violations and no borrowed connections.

Acceptance: reserve p99 ≤ 2 seconds; a ≥ 60-second skewed workload completing ≥ 1,000 workflows with workflow p99 ≤ 5 seconds and ≤ 8 connections. These are explicit component regression thresholds, not an agreed production SLO. The one-minute run is not a long-duration soak; the four objects do not represent four independently failing hosts.

Recovery uses a verified physical base backup and archived WAL. Three post-backup records, including settlement and release evidence, survive recovery to the named target. A later record is deliberately excluded. Full row digests, replay rejection, idempotent reconciliation and new admission are checked. A corrupted backup is rejected by checksum; missing required WAL prevents writable promotion. Process-crash recovery preserves the latest acknowledged snapshot.

Recovery timers include fixture startup and assertions, not incident detection, fencing, external-journal reconciliation or production cutover. The archive is local; this does not establish remote archive durability or production RPO/RTO.

Validation and score

The exact candidate passed the full SDK build, lint/API compatibility, coverage floors, dependency inventories, 24 documentation entry points, independent VI interoperability, required-test/discovery checks, host alerts, notification delivery and build attestation. Hosted JUnit: 3,901 passed, 15 documented optional skips, zero failures/errors. Merged coverage: 57.31% line and 39.84% branch; the existing floors were retained.

Only Reliability and scale is reassessed. Category total 55.1 / 6 = 9.1833, rounded to 9.2. Scoring rationale · Measurements and evidence hashes · Previous qualification.

Evidence archive

PostgreSQL references: continuous archiving and PITR, WAL durability settings, client transaction settings.