DFYAI · for a technical evaluator
How DFYAI works
What it does with a production, what it measures on real data, how it's set up today, and what it can't do yet — for whoever has to check our claims.
How a production gets in
DFYAI loads a production from its load file — DFYCollect's, or any other standard one. Its preparation step converts the natives to PDF, extracts their text, reads scanned pages, and can transcribe audio and video, using models that run on the same machine. The import then indexes every passage so it can be searched by words or by meaning.
It copes with a thin load file. A default custodian can be set and applied afterwards, families are recovered from the attachment columns even when they weren't mapped, dates are read in both ISO and US month-first form, and anything unreadable shows blank rather than breaking the grid.
How a production goes out
Reviewers mark what goes out as they code, each document with a designation the matter chooses. DFYAI checks the marking before anything is written, and again when Produce is pressed; anything that would stop the production is fixed, or overridden with a reason that is kept. It then numbers and writes the volume: natives with their text, or TIFF, JPEG or PDF pages stamped with their number and designation.
Families are numbered together, parent first, and a withheld member keeps its place with a slip sheet. A redacted document goes as pages only: what is under each box is taken out of the page rather than covered, its text is read back from the redacted pages, and the production stops if any of the covered words are still there. Each volume carries a privilege log and a manifest with a hash of every file in it, and the matter keeps a record of each production that cannot be changed or deleted.
How it's set up today
DFYAI runs today as a single-machine setup, installed and configured by us. It isn't yet a packaged installation, and it isn't hardened for a shared network — it isn't ready to put on a firm's network as it stands, and this page won't say otherwise until it is.
| Networked GPUs | Import and extraction can be shared with other GPU machines on the same network. DFYAI doesn't encrypt that traffic itself, so today it belongs on a network you control. |
| At rest | Evidence text, extracted facts and the search index are stored unencrypted on the machine; its disk encryption is what protects them. |
Accounts
Individual sign-ins, with two roles: administrators, who see every matter and manage accounts, and reviewers, who see the matters they own. Accounts can be disabled but never deleted, because every coding decision carries the name of the person who made it.
Performance
Measured on a real 31,233-document production, not estimated.
| Documents | 31,233 |
| Passages | 477,583 |
| Preparation | 33,954 files in 10.5 hours |
| Import, including indexing every passage | 6 h 2 m of GPU time, zero errors |
| Knowledge extraction | 3.9 seconds a passage, 923 an hour of GPU time |
| Review search | well under a second |
| People queries | tens of milliseconds |
Times are GPU time: networked GPUs share the work, so adding them shortens the wait. Extraction is the number that changes how you work — at 3.9 seconds a passage, a graph over the whole production is roughly twenty-two days of GPU time. That's why extraction is scoped to a category, a tag, a keyword or the current filter, shows the passage count and a time estimate before it starts, and why an evaluator should plan for a graph over the part of a matter that warrants one.
Current limits, stated plainly
The same section exists on the DFYCollect technical page, for the same reason: a vendor listing its own limits is the most credible thing on a website.
| 1 | Extraction is slow enough to change how you work. About twenty-two days of GPU time for a 31,000-document production, less on the clock with networked GPUs sharing it. It's built to be run over a scope. |
| 2 | Nobody checks the facts the AI extracts. DFYAI records whether each fact came from the load file or from the AI reading a document, but the graph doesn't show the difference yet. When it writes an answer, it does weigh where each fact came from. |
| 3 | Productions run while you wait. There's no progress bar and no Stop. Page-image productions need an extra component we set up; without it, only natives can be produced. |
| 4 | One way in: a load file. A Concordance-style
.dat or a CSV, one per production, and without a load file there's
nothing to review. Opticon and other image load files aren't read, so a production's
own page images aren't shown: review shows DFYAI's rendering of each document, and
its text. |
| 5 | A single-machine setup, not yet hardened for a shared network. |
| 6 | Networked GPU traffic isn't encrypted by DFYAI. |
| 7 | User administration is basic but real. Changing your own password isn't on screen yet, there are no groups, and permissions go no further than owner and administrator. |
| 8 | One import and one extraction at a time, across the whole installation; the rest queue. |
| 9 | Family and people data are only as good as the load file. Families come from the attachment-range column and relationships from the sender, recipient and custodian columns; a production without them loses the family nesting and most of the People screen. Person matching is deliberately conservative — it merges a name into an email identity only when unambiguous — so the same person under two spellings may appear twice. Resolve merges names in the AI graph, but not on the People screen. |
| 10 | The coding record shows alterations; it can't prevent them. DFYAI only ever adds to it, and each change is chained to the one before, so an alteration shows, unless the whole chain is rebuilt after it, which an export kept elsewhere would show. Someone holding the database's own credentials can still make one. |
The other half of the toolchain
DFYAI reviews what DFYCollect produces, or any other standard load file. How DFYCollect works covers the collection side: what it does with every document, measured throughput, and its own limits.
Evaluating DFYAI for your firm? We'll walk your technical team through how it works in detail. Contact us