Four things we
know how to build.

Most teams come to us after they've already tried document extraction once. The pilot worked on clean PDFs, then broke the moment real documents arrived — scanned invoices with handwriting in the margins, forms filled out inconsistently, tables that span pages, PDFs that were actually just photos of PDFs.

That gap between 'the model extracted the right fields on the sample' and 'the system reliably handles what the business actually receives' is where most document projects die. We build for the second case. That means configurable pipelines instead of hardcoded rules, a real ground-truth dataset from day one, an evaluation harness that tells you when accuracy drops on new document types, and a human review loop for the cases the model is uncertain about.

The output is boring by design: a pipeline that an operations team can trust, tune, and extend without calling us back every quarter.

A knowledge graph is only as useful as the questions you can actually ask it. Most graph projects fail because the schema was designed around the source data instead of the questions the business needs answered — so you end up with a technically correct graph that no one can query usefully.

We work backwards. We start with the five or ten questions that matter most to your team, then design the schema, entity types, and relationships to make those questions fast and obvious. Along the way we handle the messy parts most tutorials skip: entity disambiguation, schema evolution without reloading the whole graph, and making the graph queryable in plain language when that's what the end users actually need.

The graphs we build sit in production for years, not months. That only happens if they're designed to answer real questions from day one.

Entity resolution is the problem that quietly kills data projects. You have the same person in four systems spelled five ways, the same company with three different tax IDs across merged subsidiaries, products that are 'the same thing' by one definition and 'different SKUs' by another. The right answer depends on what the business is trying to do — and the business usually can't tell you until they see the wrong answer.

We approach this iteratively. We build a first pass with sensible defaults, put it in front of the people who'll use it, watch what they flag as wrong, and fold their feedback into the matching rules. After three or four rounds the system converges on something that reflects how your team actually thinks about identity, not how a textbook says they should.

The hardest part isn't the matching algorithm. It's building a system that can be corrected without a rewrite when the business definition of 'same entity' shifts — which it will.

Most AI failures we've seen in production weren't model failures. They were architecture failures — systems where a model was plugged into a pipeline that had no error boundaries, no retry logic, no way to swap components out, no visibility into why things broke, and no clean separation between the model and everything around it.

When we design an AI system, the model is the last component we pick. First we decide where human review belongs, how we'll evaluate the system in production, what happens when the model is wrong, how we'll version and roll back changes, and what the failure modes are when downstream systems time out. Only then do we pick the model — and usually we pick it last because by that point the right choice is obvious.

This is unglamorous work and it's what separates AI systems that are still running in year three from the ones that got quietly replaced by a script.