Reports #012 and #013 validated TTP inside a real PostgreSQL mutation boundary. Report #014 moves one step outward: business state can be committed while an external effect is executed separately and its acknowledgement is lost.

BUSINESS DBOUTBOXWORKEREXTERNAL EFFECT

The unsafe boundary duplicated the external effect.

The business transition committed once at COMMITTED / version=101. The first external request then committed its effect, but a synthetic crash removed the acknowledgement. Recovery created a new request identity and sent again.

01

Business commitOne PostgreSQL state transition reached version 101.

02

External effect #1Request key unsafe:attempt:1 was applied.

03

ACK lostRecovery could not prove whether the effect happened.

04

New identityunsafe:attempt:2 was treated as a new request and applied again.

The database was correct. The cross-boundary trajectory was not: one business commit became two external effects.

Transactional outbox closes the database-side gap.

The safe adapter writes the business transition and the durable delivery intent in the same PostgreSQL transaction.

state → COMMITTED/v101+outbox → PENDINGONE DB COMMIT

A synthetic crash before that commit rolled both pieces back: ABSENT / v100 / 0 outbox rows. A successful commit persisted both together, including the stable key op-1:external-effect:v1.

Stable identity makes redelivery safe.

The first worker delivery was applied by the synthetic external service, but its acknowledgement was lost, so the outbox remained pending.

attempt 1 → APPLIEDACK LOSTPENDING

The worker then delivered the same logical message again with the same idempotency key. The external boundary returned DEDUPLICATED. The final external effect count remained one and the outbox moved to DELIVERED.

attempt 2same stable keyDEDUPLICATED1 effect

Reconciliation can avoid even the duplicate call.

The stronger recovery path queried the external ledger after the acknowledgement disappeared. It found COMMITTED, marked the outbox delivered and made no second external call.

UNKNOWN ACKRECONCILECOMMITTEDNO RE-EXECUTION

The cross-boundary TTP rule

BUSINESS TXOUTBOX INTENTCOMMIT
DELIVER WITH STABLE IDACK / UNKNOWNRECONCILEPROVE
01

Unsafe boundary duplicate · 2/2One DB transition produced two external effects when retry identity changed.

02

Atomic outbox intent · 2/2State and outbox rolled back or committed together.

03

Stable-key redelivery · 2/2Second delivery was deduplicated; one effect remained.

04

Reconcile before retry · 2/2External COMMITTED was discovered before any second external call.

05

Cross-boundary proof · 2/2Safe trajectories ended with one business transition and one external effect.

New invariants

DB COMMITTEDEXTERNAL ACKNOWLEDGED
REDELIVERYPRESERVE LOGICAL EFFECT IDENTITY

Transactional outbox removes a lost-intent gap. Stable idempotency and reconciliation address ambiguous delivery. None of these mechanisms should be advertised as universal exactly-once delivery.

Interpretation boundary

The external service is a synthetic ledger reached through a separate PostgreSQL transaction. That creates a real transaction boundary but does not reproduce a production payment rail, broker, blockchain, SaaS API, network partition, failover topology or arbitrary distributed system.

  1. Transactional Trust Protocol v1.0
  2. Canonical GitHub Actions run
  3. Benchmark harness
  4. Machine-readable result

Evidence artifact digest: sha256:7732375332cfee2507eda5ec72df190cbe94c1ee18bd3f1bc86ec1a5884562e2.

Verdict: one committed business transition became two external effects when acknowledgement loss was followed by a new request identity. Transactional outbox, stable idempotency and external reconciliation preserved one effect in both safe recovery paths.

RESONANCE Verified Report #014

commit intent → deliver → reconcile → prove.

Read TTP v1.0