Skip to main content

How it works

A guided review, field by field.

InsighterTraining reads a securities class-action complaint with AI, then walks a reviewer through confirming every extracted field against the source document before anything is accepted. Here is the whole flow.

The review workflow

The InsighterTraining review screen: PDF on the right, field-by-field form on the left.
The review screen: the source complaint on the right, the field-by-field form on the left.

1. Upload a complaint

Drag in a securities class-action complaint (a PDF). InsighterTraining accepts the first identified complaint for a case.

Under the hood: image-only scans are detected and rejected, because the extractor needs a real text layer to quote evidence from.

The upload screen: a drop zone for a securities class-action complaint PDF.
The upload screen: drop in a complaint PDF to begin.

2. AI extraction

The extraction model reads the filing and fills the structured fields: class period, violations, defendants, disclosures, and counsel. This takes a few seconds.

Under the hood: the model returns JSON with a verbatim evidence quote for each field, so every value is traceable back to a passage in the document.

The extraction-in-progress screen: the PDF renders on the right while a three-step tracker shows Processing document complete, Consulting the extraction model active, and Preparing form pending.
While the model works, a step tracker shows progress: the document is processed, the extraction model is consulted, then the form is prepared.

3. Review each field

This is the core of the job. Every AI-filled value must be confirmed or rejected against the source. Click a field and the PDF jumps to the exact passage it came from and highlights it. Icons show each value's origin (located in the PDF, snippet-only, manually entered, edited, or unsupported); see the icon legend at the end.

A confirmed form field with the PDF scrolled to and highlighting the source passage the value came from.
Clicking a field jumps the PDF to the exact passage the value came from and highlights it.

4. Match entities

For each plaintiff, firm, and defendant, a picker suggests existing catalog entities so you can link the row to a canonical record, or affirm "Create new". Linking keeps duplicate entities from piling up.

Under the hood: names are fuzzy-matched (and matched on canonical ID, CIK, and ticker) against a cached snapshot of a roughly 38,000-entity catalog.

The entity candidate panel suggesting catalog matches under an individual (person) row.
Matching a person: suggested catalog matches under an individual row.
The entity candidate panel suggesting catalog matches under a company defendant row.
Matching a company: suggested catalog matches under a company defendant row.

When no catalog entity fits, "Create new" opens a structured form rather than accepting a bare name, so easy-to-miss fields like a CIK still get filled in. The form adapts to what you are creating:

Create-new entity form, person shape: a structured name sub-form (plus a CIK for a director or officer defendant). Create-new entity form, company shape: an editable company name plus a CIK. Create-new entity form, third-party shape: Person and Company tabs, the person tab nesting an affiliated-company picker.
The create-new form adapts to what you are creating. Use the tabs to compare the person, company, and third-party shapes.

5. Resolve conflicts

Two screens you will occasionally see. If the catalog gained a matching entity while your draft sat open, a re-check modal surfaces it at submit so you can link instead of creating a duplicate. And if another reviewer is creating the same new entity at the same time, your submission queues rather than racing, with options to cancel and edit, skip the line, or wait for the other one to finish.

The stale-draft cache re-check modal listing newly cataloged candidates.
The cache re-check modal: a candidate appeared since the draft was started.
The submission-queue conflict modal showing an in-flight blocker and three exits.
The submission-queue modal: another reviewer is minting the same entity.

6. Submit

When every field is confirmed, submit. If the validator finds problems, a worklist appears at the top of the form with one row per issue and a prev/next stepper that jumps you straight to each field to fix.

The submit-time validation worklist at the top of the form: one row per issue with a prev/next stepper that jumps to each field to fix.
The validation worklist: one row per issue, with a stepper that jumps you to each field to fix.

How it is built

A quick look under the surface, for the curious.

AI extraction with evidence

The extraction model returns structured JSON plus a verbatim quote per field, so every value is traceable to the source.

Fuzzy entity matching

Extracted names are matched against a cached ~38,000-entity catalog to link rows to canonical records.

Concurrency-safe submission

An optimistic-concurrency queue keeps two reviewers from racing the same new entity into the database.

Deployed on AWS

Runs on Fargate behind an ALB, fronted by HTTPS at the Stanford Law subdomain.

Want the people behind it? Meet the creators.

Appendix: provenance icons

As you review, a small icon sits beside each field to show where its value came from and how far to trust it. Hover any icon for a tooltip with the details. The states:

Hovering the located-in-document pin icon on a company defendant's Section 10(b) violation reveals a tooltip with the verbatim passage the value was extracted from.
Hovering an icon shows its tooltip. Here the located-in-document pin on a company defendant's Section 10(b) violation reveals the verbatim passage the value came from.
Located in the document. The value was found in the text and mapped to an exact passage. The tooltip reads "Value found in document"; clicking the icon (or the value) scrolls the PDF to the highlighted passage. This is the strongest evidence.
Snippet only, no located passage. There is an evidence snippet, but it could not be mapped to a single passage, so nothing is highlighted in the PDF. The tooltip shows the snippet text itself. This usually means the model's evidence is a concatenation of several separate quotes pulled from different parts of the filing, so there is no one contiguous region to highlight. Copy the snippet into the viewer's search box to find the underlying passages.
Linked to a catalog entity. The reviewer matched this row to an existing cataloged entity from the picker. The tooltip shows what the model extracted and the entity it was linked to (name and ID), and offers "Show original evidence" and "Revert to extracted value".
Manually assigned ID. The reviewer pasted a canonical ID directly rather than picking a suggestion. The tooltip shows the assigned ID.
Edited. The reviewer changed the model's value. The tooltip shows both the original extracted value and the current one, and offers "Show original evidence" and "Revert to extracted value".
Manually entered. The reviewer typed this value and the model did not extract it (for example, a conditional field filled in later). The tooltip reads "Manually entered".
No evidence. The model produced a value but gave no quote and no location, and it has not been edited. The tooltip flags a high hallucination risk, a cue to verify the value by hand.
Invalid. The value fails a validation check (for example, a malformed date or ID). The tooltip explains what is wrong.

When more than one could apply, the icon shows the most significant fact about the value: a reviewer action (linked, ID, edited, manual) takes precedence over the model's own evidence (located, snippet, none).