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.

READ v100RACECONDITIONAL UPDATEONE WINNER

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.

A

Unconditional commitState advanced to version 101 and effect #1 was inserted.

B

Unconditional commitState advanced again to version 102 and effect #2 was inserted.

Both reads were true. The duplicate happened because the truth of the read was not enforced at the write boundary.

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:

A expected v100=current v100COMMIT v101

Node B had already read the same version 100 snapshot, but by the time its conditional UPDATE was evaluated the row had changed:

B expected v100current v1010 ROWS

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:

COMMITTED·version 101·effects 1

The final database invariant therefore held with exactly one committed effect.

01

Real PostgreSQL service · 2/2Server reported PostgreSQL 17.6.

02

Unsafe duplicate · 2/2Two independent connections produced two effects and version 102.

03

Single conditional winner · 2/2Safe path produced exactly one commit winner and one precondition failure.

04

Stale writer reconciliation · 2/2Loser reread COMMITTED / version 101 / effects 1.

05

Final database proof · 2/2Final state committed, version 101, effect count 1.

TTP now has a real storage adapter.

OBSERVEBIND VERSIONCOMPARE + COMMIT
CONFLICTRECONCILEPROVE

The database-specific invariant is simple:

COMPARE + TRANSITION + EFFECT must share the same enforced transaction boundary.

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.

  1. Transactional Trust Protocol v1.0
  2. Canonical GitHub Actions run
  3. PostgreSQL adapter harness
  4. 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