Ota on dbmask: Proving a Synthetic PostgreSQL Masking Lane
A merged dbmask integration shows how a declared Ota task, direct database assertions, and a negative control can make one PostgreSQL result reviewable.
A green command was not the acceptance condition
dbmask masks database content. The useful question for this integration was specific: could a declared task run the intended masking sequence and retain evidence that its result matched the observed state of a disposable PostgreSQL database? A command exiting zero would not answer that on its own.
PR #37 added a reviewable ota.yaml pinned to released Ota v1.6.28 and a separate, non-blocking Ota workflow. The existing SQLite CI stayed in place. The added PostgreSQL 16 lane uses only synthetic data.
What the lane actually checks
The lane seeds two disposable databases, scans, performs a masking dry run, applies the mask, and runs strict validation. Repository-owned assertions check that the dry run preserves both databases. After apply, they check source preservation, target primary keys and account_status, and changed target full_name and email values.
The negative control restores one original synthetic sensitive value after masking. Strict validation must then refuse that row with masking_completeness. This shows the selected validator notices a deliberate violation in the exercised fixture. Ota declares and runs the selected path; dbmask's fixture and validator own the database assertions. The workflow uploads the native and PostgreSQL lane outputs from ota-pressure/native/ and ota-pressure/postgresql/ as CI artifacts.
The released-pin fork matrix and upstream PR matrix passed the contract-to-CI drift check, the selected SQLite contributor lanes on Ubuntu, macOS, and Windows, and the synthetic PostgreSQL lane on Linux. Those checks covered PR head 9f75a339e09fa3d762094ffee2ef612f93065e41. The upstream maintainer merged the bounded integration as commit 7d8789ef4883a423ddba2f8934b95997d1aaf099 on 29 September 2026.
What this changes for Ota
The integration shows an additive, non-blocking path into an existing repository: keep established CI, add one explicit contract and one selected evidence lane, and make the proof limits reviewable. The negative control makes the PostgreSQL result more informative than a passing command alone. This case exposed no confirmed Ota Core defect in the selected lane.
The coverage remains narrow. It does not establish production-data safety, arbitrary database state, general PostgreSQL compatibility, MySQL behavior, release readiness, or repository-wide governance. The separate date-classification fix is dbmask-owned and outside this lane. The merge confirms maintainer acceptance of this contribution; it does not establish ongoing use or endorsement.
Take action