WEBVTT

00:00:00.300 --> 00:00:01.058
Can Grex turn

00:00:01.058 --> 00:00:02.368
public documents into

00:00:02.368 --> 00:00:03.884
a trustworthy dataset?

00:00:04.184 --> 00:00:05.356
We compared it with

00:00:05.356 --> 00:00:07.113
a competent direct workflow

00:00:07.113 --> 00:00:08.541
on 10 filing families,

00:00:08.541 --> 00:00:10.299
each containing an original

00:00:10.299 --> 00:00:12.056
document and amendments.

00:00:13.008 --> 00:00:14.394
The study asked whether

00:00:14.394 --> 00:00:16.264
orchestration and review could

00:00:16.264 --> 00:00:18.412
improve dependable extraction with

00:00:18.412 --> 00:00:19.728
less operator work.

00:00:20.028 --> 00:00:21.915
Procurement access was blocked,

00:00:21.915 --> 00:00:22.776
so the executed

00:00:22.776 --> 00:00:23.769
study switched to

00:00:23.769 --> 00:00:25.490
public securities filings.

00:00:26.467 --> 00:00:27.967
Both workflows received

00:00:27.967 --> 00:00:29.539
identical frozen text.

00:00:29.839 --> 00:00:31.027
Grex used MiniMax;

00:00:31.027 --> 00:00:33.188
the direct workflow used Claude.

00:00:33.488 --> 00:00:35.246
A separate blinded evaluator

00:00:35.246 --> 00:00:36.653
compared outputs with a

00:00:36.653 --> 00:00:37.813
sealed reference,

00:00:37.813 --> 00:00:39.079
so model differences

00:00:39.079 --> 00:00:40.485
remain a limitation.

00:00:41.467 --> 00:00:42.914
Grex passed 6 families

00:00:42.914 --> 00:00:44.438
and the direct workflow

00:00:44.438 --> 00:00:45.200
passed 5.

00:00:45.500 --> 00:00:46.967
Remaining failures centered

00:00:46.967 --> 00:00:48.551
on interpreting amendments.

00:00:48.851 --> 00:00:50.346
That small difference does

00:00:50.346 --> 00:00:51.647
not establish a general

00:00:51.647 --> 00:00:52.883
quality advantage.

00:00:53.842 --> 00:00:55.663
9 Grex corrections produced

00:00:55.663 --> 00:00:57.106
no acceptance gain.

00:00:57.406 --> 00:00:59.486
Aggregate worker time reached

00:00:59.486 --> 00:01:00.807
about 121 minutes,

00:01:00.807 --> 00:01:02.328
compared with about 16

00:01:02.328 --> 00:01:04.168
for the direct workflow.

00:01:05.133 --> 00:01:06.560
We repaired an ambiguous

00:01:06.560 --> 00:01:08.599
extraction requirement and tested

00:01:08.599 --> 00:01:10.637
context efficiency separately.

00:01:10.937 --> 00:01:12.102
The initial result

00:01:12.102 --> 00:01:13.303
remains a near-tie,

00:01:13.303 --> 00:01:14.905
with incomplete evidence

00:01:14.905 --> 00:01:15.924
about total cost

00:01:15.924 --> 00:01:17.380
and operator effort.