Reports #010 and #011 showed that a correct earlier read is not enough to authorize a later write. Report #012 asks whether that rule survives contact with a real transactional database.
The unsafe control reproduced the duplicate.
Node A and Node B used separate PostgreSQL connections. Both first observed ABSENT / version=100. After a synchronization barrier, both executed an unconditional mutation and inserted an effect.
Unsafe database result
Unconditional commitState advanced to version 101 and effect #1 was inserted.
Unconditional commitState advanced again to version 102 and effect #2 was inserted.
The PostgreSQL adapter bound the observation to mutation.
The safe workers carried the observed version into the database predicate:
UPDATE operations
SET state = 'committed',
version = version + 1,
updated_at = clock_timestamp()
WHERE id = 'op-1'
AND state = 'absent'
AND version = 100
RETURNING state, version;
Only a worker receiving a returned row could insert its effect, and that insert occurred in the same database transaction.
One connection won. The other became evidence.
In the canonical run, Node A won the conditional mutation:
Node B had already read the same version 100 snapshot, but by the time its conditional UPDATE was evaluated the row had changed:
That zero-row result was classified as PRECONDITION_FAILED, not as permission to retry blindly.
RECONCILE turned the failed write into current knowledge.
The stale writer rolled back its attempted transaction and reread the authoritative database state:
The final database invariant therefore held with exactly one committed effect.
PostgreSQL adapter score · 10/10
Real PostgreSQL service · 2/2Server reported PostgreSQL 17.6.
Unsafe duplicate · 2/2Two independent connections produced two effects and version 102.
Single conditional winner · 2/2Safe path produced exactly one commit winner and one precondition failure.
Stale writer reconciliation · 2/2Loser reread COMMITTED / version 101 / effects 1.
Final database proof · 2/2Final state committed, version 101, effect count 1.
TTP now has a real storage adapter.
The database-specific invariant is simple:
Interpretation boundary
This benchmark uses a real PostgreSQL 17.6 service container and two real independent client connections, but the business tables and effects are synthetic. It does not certify exactly-once delivery, cross-database atomicity, distributed consensus, failover behavior, every PostgreSQL isolation level, external APIs, payment rails, blockchains or arbitrary agent safety.
Reproduce / inspect
- Transactional Trust Protocol v1.0
- Canonical GitHub Actions run
- PostgreSQL adapter harness
- Machine-readable result
Artifact digest: sha256:4a9ed5a039c624acd1f0f5c0feef07c47ade79128a62050977089b0109cebaf1. PostgreSQL image digest observed during the run: sha256:ef257d85f76e48da1c64832459b59fcaba1a4dac97bf5d7450c77753542eee94.
Verdict: two independent PostgreSQL readers saw the same valid snapshot. Unconditional writes created two effects. A version-bound conditional mutation created one winner, rejected the stale writer and preserved exactly one effect.
RESONANCE Verified Report #012
observe → bind version → conditional mutation → reconcile → prove.
Read the protocol