AI Text Extraction POC

The Problem

Getting a recorded document’s key fields — grantor, grantee, consideration amount, parcel ID, legal description — onto the product’s website required a person to read the document and manually key in the data. That manual review step was the bottleneck standing between a recorded document and usable, published content. The end goal was to remove it entirely: let AI extract the fields directly and pipe them into the website with no manual re-entry. But no one had proven that was actually viable — there was no integration with an AI extraction service, no schema tuned to these documents, and no way to know whether machine-extracted output could be trusted enough to replace a human reviewer.

The Solution

I built the proof of concept that answered that question. I integrated a third-party AI document extraction service, designed and tuned an extraction schema for the domain, and wired the application directly into the AI service’s API so a recorded document could be submitted and structured field data returned as a JSON object. The POC proved the core premise end to end: the service could extract the required fields and the JSON output could be fed into the same pipeline that populates the website — no manual re-keying required. To confirm the output was trustworthy enough to actually replace manual review, the extraction results were validated against ground truth using the automated accuracy evaluation pipeline, which is what turned “this seems to work” into a defensible accuracy claim. Alongside the technical build, I ran the cross-functional conversations needed to align the integration with the product’s intended user experience, so extraction wasn’t a backend capability built in isolation but one designed from the start to slot into how the website would actually consume it.

Outcome & Impact

The POC proved the core premise: AI extraction could replace manual document review as the path from a recorded document to published website content. The integration produced structured, accurate field output with no human re-keying step, and that accuracy was independently confirmed — not just asserted — by validating the results through the automated accuracy evaluation pipeline, which replaced roughly eight days of manual validation work per batch with an automated run. This POC was the prerequisite for that entire evaluation effort: without a working integration and a validated schema, there was no extraction output to evaluate in the first place, and no case for retiring manual review.

My Role & Contributions

Aspect	Detail
Role	Sole technical integrator, acting as PM and builder
Team size	1 (with cross-functional input on product UX)
Timeline	Single proof-of-concept phase
Scope	Vendor tool evaluation, schema design and tuning, API integration, UX alignment
Key decisions	Extraction schema structure and field coverage, API integration approach, how extraction surfaces in the product experience

I owned the technical integration end to end — there was no existing internal playbook for this vendor, so the API consumption pattern, schema design, and integration approach were all decisions I made directly. I also facilitated the conversations that connected this backend capability to product design, rather than leaving it as a disconnected engineering exercise.

Technical Overview

┌─────────────────────────────────────────────────────┐
│              Recorded Document                      │
│        (manual review being replaced)               │
└─────────────────────────┬───────────────────────────┘
                          ▼
          ┌──────────────────────────────────┐
          │  Third-Party Extraction Service  │
          │  (domain-tuned schema applied)   │
          └───────────────┬──────────────────┘
                          ▼
          ┌────────────────────────────────┐
          │      JSON Field Response       │
          │  grantor · grantee · amount ·  │
          │  parcel ID · legal description │
          └───────────────┬────────────────┘
                          ▼
          ┌───────────────────────────────┐
          │  Accuracy Validation (eval    │
          │  pipeline, vs. ground truth)  │
          └───────────────┬───────────────┘
                          ▼
                    Product Website

The core technical work was learning the AI service’s schema configuration model well enough to define an extraction schema grounded in the fields the business already relied on in production, then tuning it against real transaction data to resolve the edge cases those transactions surfaced. The application-side integration called the AI service’s API directly and parsed its JSON response into a pattern the rest of the product could consume — feeding structured output directly toward the website rather than a manual entry queue.

Challenges & Key Decisions

Learning a black-box vendor tool from scratch

There was no internal precedent for this vendor’s platform. Best practices for schema design, field configuration, and API usage had to be reverse-engineered through documentation and direct experimentation rather than pulled from existing tribal knowledge — the inverse problem of most of my other integration work, where I was usually the one encoding tribal knowledge for others.

Building the schema from production evidence, not a blank page

I didn’t design the extraction schema in the abstract. I researched the indexing fields already established and relied on in production, then used real transaction data to identify exactly where a generic schema would fail — ambiguous fields, edge cases, formats existing processes had already had to work around. The schema was derived from what the business already knew worked, and tuned specifically to resolve the issues that real transactions surfaced once run through extraction. That grounding is what made the resulting schema credible enough to later serve as the basis for a formal accuracy evaluation, rather than something built on assumptions about how documents “should” look.

Connecting a backend capability to product UX early

It would have been easy to treat this as a pure backend integration and hand off a working API. Instead, I facilitated the technical conversations needed to layer in the intended product UX from the start, so the extraction capability was designed with its eventual user-facing surface in mind rather than retrofitted later.

Lessons Learned

• Vendor integrations without internal precedent require more upfront investment. With no existing pattern to build on, the schema design and API integration work took longer than a well-documented internal system would have — but that investment paid off directly in every downstream project that consumed it.
• Schema design is where domain expertise pays off, not the API call itself. Wiring up an API call is mechanical; grounding the extraction schema in fields the business already trusted, and tuning it against real transactions, is the part that determines whether the whole system is credible.
• Loop in UX before the integration is “done.” Facilitating product conversations during the build — not after — meant the extraction capability was designed for its eventual user-facing surface from day one.
• Proving accuracy is what makes automation a real decision, not a demo. Getting extraction to technically work was necessary but not sufficient — validating the output against ground truth was what turned this into a credible case for retiring manual review rather than just an interesting prototype.