Build notes
Extracting structured procurement fields from RFA emails with Claude
June 30, 2026
Clotho is a live AI procurement intake tool. You paste an unstructured "Recommended for Award" email, Claude extracts the structured procurement fields, a buyer reviews the result, and the request lands in the system of record with an audit trail entry. You can click through the demo without a login. These are the build notes on how the extraction pipeline actually works, because the interesting engineering is not the part people expect.
The problem shape
Procurement intake at a Fortune 500 is a transcription job. Requests arrive as RFA emails, memo attachments, and SharePoint comment threads. A buyer reads each one and re-keys the same fields every time: capital project code, budget reference, cost center, supplier name, value, sourcing method, single-source justification, submitter. I watched this workflow from the inside for six years as an SAP Ariba user at Cummins. The re-keying is not the expensive part. The expensive part is what the re-keying causes downstream: the same supplier entered five different ways because the buyer could not find the existing record, and a vendor master full of duplicates that every report afterward has to work around.
So the pipeline has two AI problems that look like one. Extraction: read a messy email and produce the structured fields. Entity resolution: decide whether "Acme Industrial Supply LLC" in the email is the "ACME INDL SUPPLY" already in the supplier master.
Extraction: let the model do what models are good at
The extraction half is the part Claude handles almost entirely. Paste the email, Claude Sonnet returns the fields, and the form populates for review. Two decisions mattered here.
First, the model output never goes straight to the database. It populates a review form, the buyer corrects anything that looks wrong, and only the reviewed version is submitted. That single design choice removes the whole class of objections about model accuracy, because the failure mode is "buyer fixes a field" instead of "bad data in the system of record." It also means the tool is useful even on the emails it gets partially wrong, which is how real adoption happens.
Second, latency is a feature. The extraction fires in under two seconds, fast enough that it reads as part of the page load rather than a step you wait on. If the buyer has time to switch tabs, you lost them.
Entity resolution: the LLM is the second stage, not the first
The naive version of supplier matching sends the extracted supplier name plus the whole vendor master to a model and asks for the best match. That is slow, expensive, and does not scale past a toy dataset.
Clotho does it in two stages. Postgres does the wide search: a pg_trgm trigram index pre-filters the supplier master in milliseconds and returns a shortlist of candidates that look textually similar. Claude then reranks the top ten, which is the kind of judgment call LLMs are actually good at: knowing that "ACME INDL SUPPLY" and "Acme Industrial Supply LLC" are the same company, and that "Acme Consulting Group" is not, even though the trigram distance disagrees.
The division of labor is the whole trick. The database does the cheap, fast, wide filtering it was built for. The model does narrow, high-context judgment on ten rows instead of ten thousand. Each stage covers the other's weakness, and the model cost per lookup stays flat no matter how big the supplier master gets.
The boring parts that make it enterprise-shaped
None of this would survive contact with a real procurement organization without the unglamorous layer underneath. Every submission gets a generated request ID and an audit trail entry. Row-Level Security is on in Supabase, so access control lives in the database instead of in application code that has to remember to check. The in-flight request tracker replaces the manual SharePoint list that usually holds this workflow together. Stack: React 19, TypeScript, FastAPI on Python 3.12, Supabase Postgres, one Vercel deploy.
The pattern generalizes. Unstructured document in, structured record out, human review in the middle, database pre-filter plus LLM rerank for entity matching. Swap RFA emails for invoices, spec sheets, warranty claims, or intake forms and the same architecture holds. That is what makes this a pilot template rather than a one-off tool.
What I would tell a team building this
- Put a human review step between the model and the system of record. It converts accuracy objections into UX, and UX is fixable.
- Never ask an LLM to search. Ask it to judge a shortlist that something cheaper already produced.
- Make the audit trail a day-one feature. In regulated environments it is the difference between a demo and a deployment.
- Ship it where the work already happens. Clotho wins because it replaces a copy-paste habit, not because it introduces a new destination.
The full writeup with architecture detail is in the Clotho case study, and the demo is live at clotho-pi.vercel.app.
Building something like this?
I ship this pattern as a fixed-fee pilot: document intake, extraction, entity matching, audit trail, working software at the end. I also take contract engagements in AI and data roles.