WEBVTT

00:00:00.000 --> 00:00:01.600
Here is the situation.

00:00:01.920 --> 00:00:04.700
An AI workflow asks Salesforce to create an Account.

00:00:05.020 --> 00:00:06.180
Salesforce creates it.

00:00:06.580 --> 00:00:08.880
But the success response never comes back.

00:00:09.360 --> 00:00:10.580
Now you have a dangerous gap.

00:00:10.820 --> 00:00:16.240
The outside world may have changed, but the system that initiates the action
doesn't know what became true.

00:00:16.820 --> 00:00:19.740
In our real-target test, that's exactly what happened.

00:00:20.260 --> 00:00:22.640
Salesforce had already created the Account.

00:00:23.080 --> 00:00:25.740
TrustGate correctly stayed UNKNOWN.

00:00:26.240 --> 00:00:27.720
And UNKNOWN is not a shrug.

00:00:27.820 --> 00:00:28.780
It's a control state.

00:00:28.780 --> 00:00:34.760
Even after restart, TrustGate refuses an equivalent retry
and a conflicting action.

00:00:35.340 --> 00:00:38.040
No second write went to Salesforce.

00:00:38.860 --> 00:00:43.300
Then TrustGate asks Salesforce directly, what actually exists?

00:00:43.980 --> 00:00:50.380
The fresh readback had to match the action, the specific attempt,
the proof, and the expected payload.

00:00:50.780 --> 00:00:53.500
Only then did UNKNOWN become CONFIRMED.

00:00:54.700 --> 00:00:55.740
Then we make it harder.

00:00:56.180 --> 00:00:57.540
A timeout after commit.

00:00:57.540 --> 00:01:00.660
Readback unavailable, and no commit at all.

00:01:01.160 --> 00:01:04.340
A process killed after Salesforce had committed.

00:01:04.960 --> 00:01:07.760
An outside-custody second consequence.

00:01:08.300 --> 00:01:09.820
And forged attribution.

00:01:10.500 --> 00:01:12.920
The control keeps the right boundary each time.

00:01:13.560 --> 00:01:14.720
Why does this matter?

00:01:15.100 --> 00:01:19.240
Because in business systems, history is not always harmless.

00:01:19.520 --> 00:01:24.720
A duplicate can mean a second order, a second payment,
a reservation, or a change.

00:01:25.300 --> 00:01:26.780
The principle is very simple.

00:01:26.780 --> 00:01:31.060
When external reality is uncertain, don't guess what happened.

00:01:31.780 --> 00:01:32.460
Establish it.

00:01:33.860 --> 00:01:38.680
This is a bounded real-target reference proof,
not a customer production deployment

00:01:38.680 --> 00:01:40.760
or full production certification.