Amorphic IDP

Amorphic IDP turns business documents into structured data. A user uploads invoices, contracts, or court complaints. The system runs OCR, passes the text to Claude 3.5 Sonnet through Amazon Bedrock, and returns named fields the user can query, chart, and export.

Cloudwick's engineers had the extraction working before I joined. They measured 98% accuracy on a reviewed sample. My work started on the other side of that number.

98% accuracy means two wrong values in every hundred documents, and nobody knows which two.

A procurement team pulling shipping addresses can live with that. A research analyst at a state judiciary counting drug quantities across criminal complaints cannot, because the number she reports becomes a policy recommendation.

So the question wasn't how to display extraction results. It was how to let someone with no technical background decide whether to trust a specific value on a specific page, and then act on that judgment without breaking the record.

• Reviewers

  Procurement teams and research analysts who check an extracted value against the page it came from. They have no technical background and no reason to learn what a prompt is. At CJRI, the reviewer is an analyst whose counts become policy recommendations.

• Cloudwick's engineers

  The people who change prompts when a field comes back wrong. They never meet the reviewer. What reaches them is a flag, and the flag has to say what wrong looks like.

I was the product designer on the review layer, working for DigiMantra and embedded with Cloudwick from October 2024 to April 2025. Cloudwick's engineers had built the extraction before I joined, and prompt changes went through them.

I owned the screens: six product areas, each one with blank, happy path, error, and edge case states drawn and handed off, along with the shared components behind them: file status, badges, alerts, search and filter groups, and the create and update modals.

• Onboarding
• Dashboard
• Document Stores
• Process Flows
• Management
• Profile & Settings

• The model was fixed. Extraction worked and was measured before I arrived, so the design could change what a person did with a value, not the value itself.
• Records feed analysis that feeds policy. Whatever a reviewer did, the original extracted value had to survive it.
• The same screens had to hold a three field invoice and a ten page complaint with nested tables.
• Desktop web, designed at 1440px.

1. 01

   The source document sits beside the extracted values.

   The Output screen splits in two. Extracted fields on the left as key and value pairs. The original document on the right with page navigation.

   A reviewer checking "Distributor Address" reads the model's answer and the page it came from without opening a second window or losing her place in a ten page complaint.

2. 02

   OCR results and model output are separate views.

   I put a toggle above the table: OCR Results, Output.

   Two things break in this pipeline. The scanner misreads a character, or the model structures the text wrong. A user looking only at the final field sees one kind of error and can't tell which happened. The toggle lets her check the raw text, locate the failure, and report something an engineer can act on.

3. 03

   Reviewers suggest values, they don't edit them.

   Each row carries a + Suggest Value action rather than an editable cell.

   In a judiciary, extracted records feed analysis that feeds policy. If any reviewer can overwrite a value in place, the provenance disappears and nobody can reconstruct what the model originally returned. A suggestion keeps both: the extracted value, the proposed correction, and who proposed it.

4. 04

   Flagging a field requires a written reason.

   The flag icon opens a text area that names the field it's about: Write a reason for flagging 'Shipping Method' for review. The user types, then hits Flag for Review.

   A bare flag tells an engineer that a field is wrong. It doesn't tell him what wrong looks like, and prompt changes need that. Naming the field in the prompt text also stops the common mistake of flagging one row and writing about another.

5. 05

   Sensitivity is visible in the list, not buried in settings.

   The Document Stores table carries keyword tags on every row, including PII Data and Confidential, alongside the trigger type that governs when the store runs: file based, on demand, or time based.

   Someone scanning a long list of stores needs to know what's inside one before opening it. Putting the tags in a detail screen would have meant opening a confidential store to learn it was confidential.

6. 06

   One set of screens, two very different documents.

   The same interface holds a three field invoice and a ten page complaint with nested tables. I designed the value column to carry a plain string, a number, or a table summary that expands, so a row can read "Table, 3 Records" without the layout collapsing.

   The document viewer paginates because complaints run long and invoices don't.

Cloudwick deployed Amorphic IDP at the Hawaii State Judiciary's Criminal Justice Research Institute. CJRI used it to pull drug types and quantities out of freeform text in complaint documents, data their case management system held but couldn't query.

Cloudwick reported 98% extraction accuracy on manual review and processing costs near $1 per 20 documents, and published the deployment as a customer case study.

Those numbers belong to the platform and the model, not to the screens.

What I learned

The blank states did more work than I expected. A new user opening Document Stores on day one sees an empty table, and that screen has to explain what a document store is and why she'd make one.