Skip to content
Cole Jordan
Open to senior roles

Cole Jordan, Senior AI &
Full-Stack Engineer

Production AI is more than calling an LLM. I build the systems around it—APIs, data pipelines, validation, workflows, cloud infrastructure, and the product users actually interact with.

View My WorkLet’s Talk
Tracedocument.process
recording2001.78s

daily_drilling_report_142.pdf · tenant acme-drilling

  1. api.uploadPOST /v1/documents14ms
  2. auth.verifyscope ok6ms
  3. storage.puts3 · original kept78ms
  4. queue.publishdocument.received5ms
  5. model.classifydrilling_report405ms
  6. model.extract23 fields1.18s
  7. validate.schemapass10ms
  8. validate.rules1 warning21ms
  9. route→ human review3ms
  10. db.writepostgres18ms
model call everything else2 of 10 spans call a model
The other eight are the job.
  • 10+ Years Experience
  • AI & LLMs
  • Python
  • Full-Stack
  • AWS
  • Document AI
  • PostgreSQL

About

I like building the part around the AI.

Calling an LLM is easy.

Making the result useful in a real product is where the engineering starts.

That usually means APIs, authentication, databases, queues, validation, retries, observability, permissions, failure handling, and sometimes a human in the loop.

That’s the kind of work I enjoy.

Experience
10+ years of production software
Industries
Healthcare · Oil & gas · Apparel · Media
Most recently
AI/ML Engineer, Harbera (2025–2026)
Before that
Senior Software Engineer, AWS (2016–2025)
Cole Jordan in a black AWS hoodie.
The human in the loop.

I build production AI products, backend systems, and full-stack applications that turn complex ideas into reliable software.

10+ years building production software across healthcare, oil & gas, apparel, and media. The last few years made one thing particularly clear: getting a model to produce an answer is the easy part. Making that answer useful, reliable, secure, and connected to a real product is the engineering challenge.

How an AI product gets built: Idea, then Architecture, then AI, then Backend, then Data, then Product, then Production. The model is one step of 7.

Six disciplines that usually live on different teams

  • AI engineering

    LLM workflows, Document AI, agents and structured outputs, plus the checks that tell you whether any of it works.

  • Backend engineering

    Python, FastAPI, REST APIs, queues and workers. The plumbing that keeps the interesting parts alive.

  • Full-stack development

    React, Next.js and TypeScript. The screen where a person reviews what the model did.

  • Cloud architecture

    Nine years at AWS: service boundaries, failure domains, and infrastructure that doesn’t need a hero.

  • Data systems

    PostgreSQL, data modeling and pipelines. Structured output has to live somewhere sensible.

  • Production operations

    Monitoring, logging and observability. Knowing it broke before a customer does.

Featured projects

Projects where the demo was the easy part.

Each of these started as “just add AI” and turned into a systems problem: messy inputs, uncertain outputs, and real people relying on the result.

  1. 01Upstrima
  2. 02Harbera
  3. 03Freed
  4. 04Seamli AI
  5. 05Invisible Inquiry
01Document AI · Oil & Gas

UpstrimaTurning messy documents into structured data.

An AI platform for oil and gas, where agents and supervised workflows run on documents that were written for people: daily drilling reports, well data, operational summaries.

upstrima.com (opens in a new tab)
Upstrima · document processing

How it flows

  • model
  • deterministic check
  • person
  • plumbing

  1. Document

    PDF, scan, export

  2. Ingestion

    normalize, keep the original

  3. Classification

    what did we receive?

    model

  4. AI Extraction

    against a typed schema

    model

  5. Validation

    schema + domain rules

    check

  6. Confidence / Exceptions

    below threshold → route

    check

  7. Human Review

    only what needs it

    human

  8. Structured Data

    safe to use downstream

Upstrima runs AI agents and supervised workflows for oil and gas engineering teams. Underneath most of them is one of those problems that sounds simple until you actually build it: taking documents that were designed for humans and turning them into data that software can trust.

Reports arrive in different formats and layouts. The real challenge isn't pulling text off a page. The system has to work out what kind of document it received, find the information that matters, produce structured output, validate it, and know when a result is uncertain enough that a person should look at it.

My work focused on the document intelligence and backend side of the product: ingestion, classification, extraction and validation, plus the exception and review paths around them. Each one is built as a reusable processing capability, not a one-off pipeline.

Upstrima's workflow builder: an End of Well Report workflow where drilling-report, NPT, complications, depth-versus-days and well-schematic agents feed a document exporter.
The product side: agents chained into supervised workflows. Screenshot from upstrima.com.

The interesting part wasn't extracting information from the document. The interesting part was figuring out what to do when the model wasn't sure. That's why the workflow included validation, confidence checks, exception paths, and human review before the data reached downstream systems.

The hard parts

  • Extraction is the easy part to demo. Production is the long tail: a scanned page, a table that breaks across pages, a value that's present but contradicts another one. Every result carries a confidence signal and goes through validation, and anything that fails takes an explicit exception path instead of quietly flowing downstream.

  • Two reports can carry identical information and share almost nothing visually. Classifying the document first, then extracting against a schema for that document type, keeps the extraction logic from turning into a pile of special cases.

  • The product chains steps into workflows, so each capability (ingest, classify, extract, validate) has to behave like a good API: clear inputs, typed outputs, predictable failure modes. That's what makes a step safe to reuse in a workflow nobody has designed yet.

Role

Document intelligence & backend engineering

What I built

  • Python processing services for document ingestion
  • Document classification, so every file is read with the right schema
  • Structured and entity extraction into typed outputs
  • Validation: schema checks plus domain rules
  • Confidence checks and exception handling for uncertain results
  • Review workflows that send a person only the fields that need one
  • REST APIs that plug processing into the rest of the platform
  • Reusable processing steps that workflows can compose

Stack

  • Python
  • FastAPI
  • Document AI
  • IDP
  • LLMs
  • Structured Extraction
  • Validation
  • PostgreSQL
  • REST APIs
  • Workflow Automation
Visit upstrima.com (opens in a new tab)
02Healthcare AI · Operations Automation

HarberaAI for the work that happens behind healthcare.

An AI-native platform for provider credentialing, payer enrollment and revenue-cycle operations: the document-heavy work that has to be right before a clinic can bill.

harbera.com (opens in a new tab)
Harbera · credentialing review

How it flows

  • model
  • deterministic check
  • person
  • plumbing

  1. Healthcare Document

    license, DEA, CAQH, forms

  2. AI Understanding

    what is this document?

    model

  3. Extraction

    structured output

    model

  4. Normalization

    one shape, any source

  5. Validation

    formats, dates, cross-document

    check

  6. Human Review

    conflicts, low confidence

    human

  7. Operational Workflow

    credentialing, enrollment, RCM

Healthcare has no shortage of data. The harder problem is getting that data into the right workflow without creating another mountain of manual work.

Harbera is an AI-native healthcare operations platform. Credentialing a single provider means licenses, DEA certificates, CAQH profiles and enrollment forms, and a lot of fields that have to agree with each other across every one of them. Payer enrollment and revenue-cycle work pile more documents on top.

I built AI and backend capabilities around those document-heavy processes: read the document, pull out what matters, check it, and hand it to the right step of the workflow, with a person in the loop when it counts.

In healthcare, model accuracy is the entry fee. The system leans on structured outputs, validation, exception handling and careful data handling, and model output stays a draft until it passes checks or a person signs off.

A license number that's “mostly right” is a wrong license number.

The hard parts

  • In credentialing, a near-miss on a license number or an expiration date isn't a small error. It's a rejected application, and a provider who can't see that payer's patients until it's fixed. Extraction runs against strict schemas, and validation checks formats, dates and consistency across documents before anything moves forward.

  • The point isn't to remove people. It's to stop wasting their time. Confident, validated results move on. Conflicts, like a middle name that differs between a license and a CAQH profile, go to a reviewer with both sources side by side.

  • HIPAA-sensitive workflows reward boring engineering: least-privilege access, sensitive fields kept out of logs, encryption, and an audit trail of who changed what. None of it demos well. All of it matters.

Role

AI/ML Engineer, 2025–2026

What I built

  • LLM extraction with structured outputs, validated against typed schemas
  • Normalization, so provider data looks the same whichever document it came from
  • Validation and exception handling for fields that must match across documents
  • Human-in-the-loop review for low-confidence and conflicting results
  • Python/FastAPI services and REST APIs that connect AI to credentialing and enrollment workflows
  • PostgreSQL models for documents, extracted fields and review state
  • Secure handling of sensitive data in HIPAA-sensitive workflows on AWS

Stack

  • Python
  • FastAPI
  • LLMs
  • Document AI
  • Healthcare AI
  • Workflow Automation
  • PostgreSQL
  • REST APIs
  • Human-in-the-Loop
  • AWS
Visit harbera.com (opens in a new tab)
03Healthcare AI · Clinical Documentation

FreedMaking clinical documentation less painful.

An AI scribe that turns patient visits into structured clinical notes, so clinicians can pay attention to the person in the room instead of the keyboard.

freed.ai (opens in a new tab)
AI scribe · clinical documentation

How it flows

  • model
  • deterministic check
  • person
  • plumbing

  1. Conversation / Clinical Input

    the visit itself

  2. AI Processing

    transcribe and understand

    model

  3. Structured Clinical Information

    sections, findings, plan

    model

  4. Documentation

    clinician reviews and edits

    human

  5. Healthcare Workflow

    sign, send to the EHR

Clinical documentation is one of those problems where the technology has to fit into the workflow, not the other way around.

Freed is a healthcare AI product built around that idea: capture the visit, produce a structured clinical note the clinician can review and edit, and get it into the record without an evening of catch-up typing.

The interesting engineering problem sits in the middle. A clinical conversation wanders, corrects itself, and mentions the important thing in passing. Turning that into documentation that's accurate, structured, and shaped like the notes a clinic actually writes is much harder than transcription.

The experience I bring to this spans healthcare application backends, clinical workflows, AI-assisted documentation, data processing, APIs, databases, cloud infrastructure, and the frontend/backend integration that puts a draft in front of a clinician at the right moment.

The note is a draft until the clinician says it isn't.

The hard parts

  • Clinicians already have a way of working, and they're busy. If a tool asks them to change it, they won't use it. The note has to land in the format, template and place they already expect.

  • Visits don't happen in SOAP format. Organizing a conversation into structured sections without adding anything that wasn't said is the core problem, and it's a different problem from transcription.

  • Clinical audio and notes are about as sensitive as data gets. Access control, retention and what ends up in logs are product decisions here, not afterthoughts.

Role

Backend & full-stack engineering for healthcare workflows

What I worked on

  • Backend systems and APIs for healthcare applications
  • Data processing for unstructured clinical input
  • AI-assisted documentation flows that keep the clinician in control
  • PostgreSQL data design for documentation workflows
  • Frontend/backend integration with React and JavaScript
  • Cloud infrastructure on AWS

Stack

  • Python
  • JavaScript
  • React
  • PostgreSQL
  • AWS
  • Healthcare AI
  • APIs
  • Data Processing
Visit freed.ai (opens in a new tab)
04Visual AI · Computer Vision

Seamli AIWhere computer vision meets the product experience.

Fit intelligence and virtual try-on for apparel: computer vision that shows how a garment will look and fit before someone buys it.

Seamli AI · virtual try-on

How it flows

  • model
  • deterministic check
  • person
  • plumbing

  1. User Image + Garment

    a photo and an item

  2. Computer Vision / AI

    understand body and garment

    model

  3. Image Processing

    align, composite, clean up

  4. Backend API

    jobs, status, results

  5. Interactive Web Experience

    preview, compare, decide

Seamli AI is a very different kind of AI problem from Document AI. Instead of turning documents into structured data, the product works with photos, garments and measurements, and the output isn't a JSON object. It's an image someone looks at and decides whether to trust.

The product does two things. Virtual try-on shows a garment on you. Fit analysis compares the garment with your measurements and tells you where it will be snug or loose.

The vision model gets the attention, but much of the engineering is around it: image processing before and after the model, a Python/FastAPI backend that runs heavy work without blocking the interface, Supabase/PostgreSQL for data, and a React/Next.js frontend that stays responsive while all of that happens.

With documents, a wrong field fails validation. With images, the user is the validator.

The hard parts

  • With documents, a wrong field is a validation error. With images, a wrong result is something a person sees instantly and remembers. Quality checks and graceful fallbacks matter more than a perfect demo.

  • Vision work isn't instant. Upload, processing-status and preview states keep the interface responsive while the backend does the heavy lifting asynchronously.

  • Lighting, pose, background, resolution: user photos vary as much as scanned documents do. Normalizing input before it reaches the model is half the job.

Role

Full-stack engineering for visual AI

What I built

  • Image processing that prepares user and garment images and cleans up results
  • Computer vision and AI integration for try-on and fit
  • Python/FastAPI APIs for processing jobs and their results
  • A React, Next.js and TypeScript interface for upload, garment selection, preview and controls
  • Supabase/PostgreSQL data for users, garments and results
  • API integration across the web app, processing services and models

Stack

  • Computer Vision
  • Image Processing
  • Python
  • FastAPI
  • React
  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • AI
05Graph AI · Investigative Research

Invisible InquiryMaking the connections visible.

A research platform that turns source documents into an explorable graph of people, organizations, money and events, with every connection traceable back to its source.

invisibleinq.com (opens in a new tab)
Invisible Inquiry · graph viewer

How it flows

  • model
  • deterministic check
  • person
  • plumbing

  1. Source Documents

    filings, articles, records

  2. AI Ingestion

    read and extract

    model

  3. Entities & Relationships

    people, orgs, money, events

    model

  4. Linking & Provenance

    same entity? which source?

    check

  5. Graph API

    query by entity and type

  6. Interactive Graph

    explore, filter, cite

Invisible Inquiry is built on a simple observation: a lot of important stories aren't in any single document. They're in the connections between documents: who sits on which board, which organization funded which project, which name keeps turning up in the same filings.

The platform ingests source material and turns it into a graph. People, organizations, events, money and locations become nodes, relationships become edges, and the Graph Viewer lets anyone explore it like a browser: click a node, see its relationships, read the sources.

It's Document AI with a twist. Extracting entities is step one. The hard parts are deciding when two mentions are the same entity, keeping provenance for every edge, and rendering a dense network in a browser without it turning into a hairball.

In investigative research, a connection without a source is just an accusation.

The hard parts

  • Names repeat, organizations rename themselves, and the same entity shows up spelled three different ways. Deciding when two mentions are one node, and when they definitely aren't, matters more than the extraction itself.

  • A relationship without a source can't be checked, so it can't be trusted. Every connection traces back to the document it came from, and the interface keeps that source one click away.

  • Real networks get dense fast. Filtering by entity and relationship type, focusing on a selected node, and loading neighborhoods progressively keep the graph explorable.

Role

Full-stack engineering: data pipeline & graph viewer

What I built

  • Python/FastAPI services for ingesting sources and serving graph data
  • AI-assisted entity and relationship extraction, with provenance back to each source
  • A Supabase/PostgreSQL data model for entities, relationships and sources
  • A React, Next.js and TypeScript graph explorer with search, filters and entity panels
  • API integration between ingestion, storage and the interactive viewer

Stack

  • Python
  • FastAPI
  • React
  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • LLMs
  • Entity Extraction
  • Graph Visualization
Visit invisibleinq.com (opens in a new tab)

The pattern

Five products. Five different AI problems.

Different inputs, different outputs, different ways to be wrong. Here’s the one-line version of each.

Different products, same engineering principle: the model is only one piece of the system.

How I build AI

The model is only the beginning.

I don’t treat an AI model as the product.

The product is everything around it.

Production AI needs predictable APIs, structured outputs, validation, monitoring, permissions, data storage, retry behavior, and clear failure paths. That’s where my backend and full-stack experience becomes especially useful.

Explore the diagram

Eight layers, one of them is a model.

Pick a concern on the dotted line to see which layers it touches, or pick a layer to see what it’s responsible for. Pick it again to clear.

Architecture patterns

Four patterns I keep coming back to.

Boxes and arrows are the easy part. Open one up for the decisions that usually matter more than the diagram.

    1. 01

      Ingestion

      Accept anything, normalize early, and keep the original. You’ll need it for audits and reprocessing.

    2. 02

      Classification

      Decide what the document is before deciding how to read it. Everything downstream trusts this answer.

    3. 03

      Extraction

      Extract against a typed schema per document type, and ask for evidence (page, region, quote) with every value.

    4. 04

      Validation

      Formats, ranges, cross-field and cross-document rules. Cheap deterministic checks catch expensive model mistakes.

    5. 05

      Review

      Low confidence or a failed rule sends the field, its source and the reason to a person. Their correction is saved.

    6. 06

      Structured Data

      Validated values, raw output and provenance stored together. Downstream systems only see the validated version.

    Decisions I’d make again

    • Store raw model output next to the normalized values
    • Version prompts and schemas together
    • Make reprocessing a first-class operation, not a script

    1. 01

      Intent

      Work out what the user actually wants, and whether the system should do it at all.

    2. 02

      Agent

      The model plans and picks tools. It decides what to try next; it doesn’t decide what’s allowed.

    3. 03

      Tools

      Small, typed, well-described tools with narrow permissions. A tool is an API contract, not a suggestion.

    4. 04

      APIs

      Deterministic code does the real work. Permissions, idempotency and audit logs live here, not in the prompt.

    5. 05

      State

      Persist every step so a run can resume, be inspected or be replayed. Stateless agents are impossible to debug.

    6. 06

      Validation

      Check the result against the goal and the rules. Anything with real consequences waits for a human to approve it.

    7. 07

      Result

      A structured outcome the UI can show: what was done, and why.

    The question I keep asking: where should the model make decisions, and where should deterministic code take over? Models are good at reading messy intent and choosing between options. Application logic is better at permissions, money, and anything that has to happen exactly once. RAG earns its place when the answer depends on your data, not by default.

    Decisions I’d make again

    • Structured outputs between every step
    • Human approval for high-impact actions
    • Tool calls logged like API calls, because they are API calls

    1. 01

      React

      Streaming where it helps, explicit loading and failure states, and a review screen that makes corrections fast. The UI is where trust is won or lost.

    2. 02

      API

      A typed contract between frontend and backend: versioned, authenticated, and boring on purpose.

    3. 03

      Python Services

      FastAPI for business logic and AI orchestration; background workers for anything slow.

    4. 04

      PostgreSQL

      Relational data where it’s relational, JSONB for flexible model output, and indexes chosen from real queries.

    5. 05

      AI

      Model calls behind an interface: swappable providers, versioned prompts, recorded inputs and outputs.

    6. 06

      Cloud

      Containers, managed databases, queues and infrastructure as code, so every environment matches.

    Decisions I’d make again

    • Long-running AI work goes to a queue, not a request
    • The frontend shows confidence, not just answers
    • Every model call can be reproduced from what was stored

    1. 01

      Services

      Clear boundaries and clear ownership. Each service owns its data and publishes a contract.

    2. 02

      CI/CD

      Every change tested, built and deployed the same way. Rolling back is a button, not a meeting.

    3. 03

      Containers

      Reproducible builds: the same image runs locally, in staging and in production.

    4. 04

      Kubernetes

      Scheduling, scaling, health checks and rolling deploys, so one bad pod doesn’t become a bad day.

    5. 05

      Monitoring

      Alerts on what users feel: latency, error rates, queue depth, stuck jobs.

    6. 06

      Observability

      Logs, metrics and traces that explain why, not just what, including model calls, tokens and prompt versions.

    Decisions I’d make again

    • Alert on symptoms, investigate with traces
    • Infrastructure as code, reviewed like application code
    • Runbooks written before they’re needed

Skills

The toolbox, grouped by where it gets used.

No percentage bars. I’ve never known what the missing 5% of anyone’s Python was supposed to be. Instead, here’s what I use and where it sits in a real system.

  • AI & Machine Learning

    Models are a component. I care about the contract around them.

    • LLMs
    • AI Agents
    • RAG
    • Document AI
    • Intelligent Document Processing
    • Multimodal AI
    • Computer Vision
    • Entity Extraction
    • Structured Outputs
    • Prompt Engineering
    • Human-in-the-Loop AI

  • Backend

    Where most of my years went, and where most AI products quietly succeed or fail.

    • Python
    • FastAPI
    • REST APIs
    • Microservices
    • API Architecture
    • Workflow Engines
    • Distributed Systems
    • Authentication
    • Authorization
    • Background Processing

  • Frontend

    The screen where someone decides whether to trust what the model did.

    • TypeScript
    • JavaScript
    • React
    • Next.js
    • HTML/CSS
    • Responsive Applications
    • State Management
    • API Integration

  • Data

    Structured output has to live somewhere sensible, and still make sense a year later.

    • PostgreSQL
    • SQL
    • Database Design
    • Data Modeling
    • Query Optimization
    • Data Pipelines
    • Structured Data Extraction
    • Vector Databases

  • Cloud & Infrastructure

    Nine years at AWS will do that to a person.

    • AWS
    • Azure
    • Docker
    • Kubernetes
    • Terraform
    • CI/CD
    • Cloud Architecture
    • Observability
    • Monitoring
    • Logging
    • Production Operations

  • Architecture

    Drawing boxes is easy. Deciding where the boundaries go is the job.

    • System Design
    • Service Boundaries
    • API Contracts
    • Event-Driven Architecture
    • Workflow Automation
    • Scalability
    • Reliability
    • Security
    • Performance Optimization

Experience · 2011 → Present

Every stage added a layer. None of them went away.

2011

  1. Computer Science

    Where the habit of asking “what happens at scale?” started.

  2. Software Engineering

    Shipping code other people depend on.

  3. Cloud & Distributed Systems

    Services, queues, failure domains, and retries that know when to stop.

  4. Full-Stack Development

    Owning a feature from the database schema to the button.

  5. AI / LLM Applications

    Putting models into products, and learning that the model is the easy part.

  6. Production AI Systems

    Validation, review and observability: AI that holds up on a Monday morning.

Present

  • AWS

    2016 – 2025

    Senior Software Engineer

    Built and operated production backend systems, cloud platforms, automation, data services, and AI-enabled systems at scale.

    • Backend systems
    • Cloud architecture
    • Distributed systems
    • Automation
    • Data platforms
    • Production AI
    • AWS

  • Harbera

    2025 – 2026

    AI/ML Engineer

    Built AI-native healthcare workflows around Document AI, structured extraction, validation, workflow automation, and human review.

    • Healthcare AI
    • Document AI
    • Python / FastAPI
    • LLM workflows
    • Structured extraction
    • Validation
    • Human-in-the-loop
    See the Harbera project

Contact

Have a difficult engineering problem? Good.

I’m interested in production AI, backend systems, full-stack applications, and the interesting problems that happen when all of them meet.

Email MeLinkedIn (opens in a new tab)GitHub (opens in a new tab)
colebjordan0@gmail.com

Open to these roles

  • Senior AI Engineer
  • Senior Software Engineer
  • Senior Full-Stack Engineer
  • Backend Engineer