WEBVTT

00:00:00.000 --> 00:00:05.520
Imagine a worker in your AI workflow

00:00:05.520 --> 00:00:08.160
returns a corrupted result.

00:00:08.160 --> 00:00:11.760
The important question is, what happens next?

00:00:11.760 --> 00:00:13.440
Which decision changed, which boundary

00:00:13.440 --> 00:00:16.240
was crossed and can useful work recover?

00:00:16.240 --> 00:00:18.200
Antigense Daisy starts with a device

00:00:18.200 --> 00:00:20.560
and keeps that incident inspectable.

00:00:20.560 --> 00:00:22.800
ChatGPT/OpenAI orchestrates; Claude works

00:00:22.800 --> 00:00:25.120
in an independent execution lane.

00:00:25.120 --> 00:00:27.520
This demonstration injects a software fault

00:00:27.520 --> 00:00:30.480
[This is a software-injected fault, not a physical hardware failure.]

00:00:30.480 --> 00:00:33.280
The integrity check detects changed bytes,

00:00:33.280 --> 00:00:38.400
but a teaching fixture reveals an unsafe fallback.

00:00:38.400 --> 00:00:42.720
Failed worker health allows an unauthorized request.

00:00:42.720 --> 00:00:45.200
Semgrep identifies that fallback.

00:00:45.200 --> 00:00:48.000
Our pinned repair rejects unauthorized requests

00:00:48.000 --> 00:00:50.560
while preserving healthy authorized work.

00:00:50.560 --> 00:00:54.160
AI advice has no authority to apply a patch.

00:00:54.160 --> 00:00:55.920
Each step has a custody address,

00:00:55.920 --> 00:00:57.680
as the replay advances.

00:00:57.680 --> 00:00:59.360
You can inspect the recorded output,

00:00:59.360 --> 00:01:01.680
checks, and Merkle commitments.

00:01:01.680 --> 00:01:04.160
The browser independently recomputes the proof.

00:01:04.160 --> 00:01:05.600
Integrity preserves the record.

00:01:05.600 --> 00:01:08.480
It does not prove that everything is true.

00:01:08.480 --> 00:01:11.600
ClickHouse stored eleven checkpoints

00:01:11.600 --> 00:01:13.040
from the same incident.

00:01:13.040 --> 00:01:15.280
We replayed the insertion and read back

00:01:15.280 --> 00:01:16.960
exactly the same records.

00:01:16.960 --> 00:01:21.600
The measured readback query took about 161 milliseconds.

00:01:21.600 --> 00:01:24.160
Akash now runs the analysis workload.

00:01:24.160 --> 00:01:26.560
Our agent created a GPU deployment,

00:01:26.560 --> 00:01:28.640
selected a lease and loaded Qwen.

00:01:28.640 --> 00:01:31.520
It returns structured advice about the unsafe fallback

00:01:31.520 --> 00:01:33.760
in about three and a half seconds.

00:01:33.760 --> 00:01:35.520
The model's advice remains untrusted

00:01:35.520 --> 00:01:37.840
and cannot authorize a patch.

00:01:37.840 --> 00:01:39.520
This is a separate custody branch.

00:01:39.520 --> 00:01:42.480
All 11 leaves verify, including the closed request,

00:01:42.480 --> 00:01:43.840
which returned success.

00:01:43.840 --> 00:01:46.160
The server reported GPU memory use,

00:01:46.160 --> 00:01:48.880
but we do not claim hardware attestation.

00:01:48.880 --> 00:01:52.160
[We do not claim] a verified final closed state or measured cost savings.

00:01:52.240 --> 00:01:54.720
Earlier failures remained in the record.

00:01:54.720 --> 00:01:57.120
On Magic Pro, OS polling is live.

00:01:57.120 --> 00:02:00.000
On the public website, this is a recorded replay.

00:02:00.000 --> 00:02:02.240
Lower troubleshooting and inference costs

00:02:02.240 --> 00:02:04.560
are goals we still need to measure.

00:02:04.560 --> 00:02:07.200
Credentials and proprietary internal state stay private.

00:02:07.200 --> 00:02:10.480
Original explanatory content carries our attribution,

00:02:10.480 --> 00:02:13.520
non-commercial, and no derivatives notice.

00:02:13.520 --> 00:02:15.840
Antigense makes the path from error to recovery

00:02:15.840 --> 00:02:19.120
easier to inspect, including where the system still needs work.