Extracting Structured Data from Messy Text
Turn emails, tickets, and notes into clean typed records — with schemas, null handling, confidence, and a review path for the uncertain ones.
Every support inbox is a pile of facts trapped in prose. "Hi, I was charged twice for order 88213 on the 3rd, can you refund the extra $49? We're on the Team plan." A human reads that and fills in four fields without thinking. Your database can't, until something turns that sentence into { orderId, amount, plan, request }.
Language models are very good at this, which is exactly the danger. An extraction feature that's right 95% of the time and confidently wrong the other 5% will put bad data into records that other systems trust. In this lesson you'll build field extraction for Deskmate's inbound email: a record design that handles missing information honestly, evidence you can verify in code, normalization that doesn't depend on the model's arithmetic, and a review queue for the records that shouldn't go straight in.
Extraction copies facts; it doesn't guess them
Start by being strict about what "extraction" means. An extraction feature copies information that is stated in the text into typed fields. It's tempting to let the same call infer things too ("the customer is probably on the Enterprise plan, given how they write"), but inferences have different failure modes and deserve a different feature.
It helps to sort every field you want into one of three kinds before you write a schema:
| Kind | Example | Who should produce it |
|---|---|---|
| Stated | Order number, amount, plan name the customer wrote | The model, with a quote as evidence |
| Derived | Refund amount in cents, due date as an ISO timestamp | Your code, from stated values |
| Inferred | Urgency, product area, sentiment | A separate classification step, labeled as a judgment |
Mixing kinds is the root of most extraction bugs. If the model is asked for refundAmountCents, it will multiply, round, and occasionally invent a number when none was given. If it's asked for the amount as written plus the currency, your code can do the arithmetic with no surprises. Inferred fields like urgency belong to Classification, Tagging, and Routing, the next lesson.
The rule of thumb: the model reads, your code computes.