Salesforce had already done it.
TrustGate could not know that yet.

What the test established

The real external commit occurred. UNKNOWN survived restart and external process death. Equivalent and conflicting protected continuation was refused before a second protected Salesforce write.

Then we tried to break it

The bounded matrix recorded PASS for: response timeout after commit; temporarily unavailable target readback; request never reaching Salesforce; process killed after Salesforce committed; outside-custody second consequence (PASS / CONFLICT); and forged target attribution (PASS / CONFLICT). These outcomes do not all mean CONFIRMED.

Bounded failure matrix

• Response timeout after commitPASS
• Target readback temporarily unavailablePASS
• Request never reached SalesforcePASS
• Process killed after Salesforce committedPASS
• Outside-custody second consequencePASS / CONFLICT
• Forged target attributionPASS / CONFLICT

PASS means the expected safe behavior passed. PASS / CONFLICT means CONFLICT was the intended safe outcome; it does not mean the action was confirmed.

Why Salesforce itself was not saving us

In separate qualification, Salesforce accepted two ordinary Account POSTs carrying the same canonical business action identity. The absence of a second protected POST in the ambiguous proof therefore came from the TrustGate fence, not Salesforce deduplication.

What this proves

This bounded reference establishes that the described TrustGate path kept an ambiguous consequence unresolved and refused protected continuation until target-side evidence established the result.

What this does NOT prove

It is a bounded Salesforce Developer Edition reference; not a customer production deployment or certification of the full TGAP-PROD runtime. It provides no assurance over routes outside TrustGate custody, no distributed atomicity or omniscience, and no claim that TrustGate is needed where native target controls already close the lifecycle.