Transactional Trust Protocol

Agent correctness becomes transactional when software can change shared state, call external systems, retry ambiguous operations and act under permissions or remembered execution history that may change while work is in flight.

1 · Observe the state that makes the action legal.

Record actor, intent, operation identity, observed state, observed state version and time. A read is a snapshot — not permanent permission.

2 · Verify the evidence behind the observation.

Check value, source, integrity, provenance and freshness. Keep UNKNOWN, ABSENT, COMMITTED and CONFLICT distinct.

3 · Authorize against current trust.

Verify authority identity and binding, activation/revocation lifecycle, trust-registry version and trust-registry freshness. A valid signature can still belong to an authority that is no longer trusted.

4 · Bind the decision to versions.

Carry the observed state version, trust epoch, verification time and invariants into the execution decision. Verified then is not authorized now.

5 · Compare at the mutation boundary.

Require the state version and trust version that authorized the action to still be current. The compare and irreversible transition must be atomic, transactional or otherwise enforced by the mutation authority.

6 · Commit once — and persist delivery intent when the effect is external.

Execute only while bound preconditions hold. If an external side effect cannot share the business transaction, persist a durable delivery intent in that same transaction, then deliver it separately with a stable logical effect identity.

7 · Reconcile ambiguity, conflicts, transport failures and restarts.

A timeout, serialization failure, dropped connection, lost acknowledgement, service restart or temporal conflict does not prove the intended effect is absent. Recovery must establish current state, current execution history and whether safety-relevant memory remains valid before replay.

8 · Prove the trajectory.

Preserve state and trust versions, database conflicts, outbox/delivery identity, transport outcome, process/restart identity, execution-memory durability, time/retention evidence, temporal epoch or watermark, remote reconciliation evidence and the final invariant result.

Database adapter rule

Verified Report #012 moved this rule into a real PostgreSQL service: two connections read the same ABSENT / v100, but a conditional update allowed one writer and converted the stale writer into a safe conflict.

Retry classification rule

Verified Report #013 showed that PostgreSQL isolation levels expose different conflict signals, but none of those signals is direct permission to replay a consequential business effect.

Cross-boundary delivery rule

Verified Report #014 crossed the PostgreSQL-to-external-effect boundary. Transactional outbox preserved durable delivery intent, while stable external identity and reconciliation preserved one effect after ambiguous acknowledgement.

HTTP transport evidence rule

Verified Report #015 made the network boundary real. The remote service committed an effect and then dropped the response; same-key redelivery was deduplicated, while authoritative status reconciliation avoided replay entirely.

Trust-memory durability rule

Verified Report #016 destroyed and recreated the HTTP container while keeping a persistent SQLite effect ledger. With process-local dedupe memory, the same stable key created a second effect after restart. With durable idempotency state, the same real redelivery returned deduplicated and preserved one effect. A third path used authoritative remote status after restart and made no second POST.

Safety memory must survive the failure window it claims to protect. A stable key is necessary but not sufficient if the execution authority forgets that it already processed it.

Idempotency retention rule

Verified Report #017 showed that durable safety memory can still expire before delayed recovery arrives. A 60-second record failed to protect a replay at +120 seconds, while a 300-second retention window deduplicated the same delayed request. After expiry, authoritative reconciliation preserved one effect without replay.

Read the Idempotency Retention Rule →

Clock authority / skew rule

Verified Report #018 showed that one durable record can be ACTIVE for one clock and EXPIRED for another while the underlying effect remains unchanged. A declared clock authority produced one decision; a bounded uncertainty interval crossing expiry preserved TIME_UNKNOWN and forced reconciliation.

Read the Clock Authority / Skew Rule →

Temporal ABA / monotonic-time rule

Verified Report #019 showed that the same retention record can visibly return ACTIVE → EXPIRED → ACTIVE when a reversible wall clock moves backward. After expiry cleanup advanced a temporal epoch, an un-fenced same-key retry created a second effect. A stale epoch was rejected with HTTP 409 / fenced_out, while a monotonic time watermark preserved EXPIRED and reconciled without another POST.

The clock value may return; execution history must not.

Read the Temporal ABA / Monotonic Time Rule →

Three conformance profiles

Interpretation boundary

TTP v1.0 is a RESONANCE experimental protocol synthesis. It is not a replacement for database transactions or consensus, not an exactly-once delivery claim, not a PKI/IAM or clock-synchronization standard, not an OpenAI Agents SDK feature claim and not an external security certification.

Canonical short form: OBSERVE → VERIFY → AUTHORIZE → BIND → COMPARE → COMMIT → RECONCILE → PROVE.