Finding the system beneath the feature.

Turning shipping documents into trustworthy product data

Shipping runs on documents. Bills of lading, arrival notices, invoices, delivery orders, and other records contain essential information—but it arrives in inconsistent formats, from sources that may overlap or disagree.

The obvious framing is an extraction problem: upload a document and ask AI to return fields. The more consequential problem is trust.

Once AI produces a value, the product still has to explain what it means, where it came from, and what should happen next.

The underlying questions

• What document and evidence support this value?
• Which shipment, container, booking, bill of lading, or purchase order does it describe?
• What happens when the terminal, carrier, document, and user disagree?
• Has a person reviewed or corrected it?
• Should the correction change the document, the operational record, or both?

The system

I helped shape a Document Hub where customers can forward documents to a dedicated address or upload them directly. The system extracts relevant information, connects the document to operational records, and presents the result for review.

What this reinforced

AI features become products when their uncertainty, evidence, and relationship to human decisions are designed—not hidden.

Designing the human side of an AI system

When AI extracts dozens of values from a document, showing the result as a completed form creates false certainty. Treating everything as an error queue makes the system exhausting.

What does a person need to see to make a fast, informed judgment?

The experience supports both scanning and investigation. A grid helps people review many fields efficiently; a full-page view creates room to understand the document, its relationships, and its history.

Important interaction concepts

• Visible links between documents and operational records
• A clear distinction between AI-set and human-corrected values
• History that preserves how information changed
• Access to source evidence when a value is disputed
• Exceptions made prominent without requiring people to re-check everything

The deeper lesson

Human review is not a fallback added after the AI feature. It is part of the AI system’s architecture. Quality includes whether people can recognize errors, understand why a result appeared, correct it efficiently, and trust what happens next.

When one product object is secretly several concepts

Software often begins with a useful simplification. Over time, that simplification accumulates responsibilities until the product can no longer represent reality cleanly.

In shipping software, “shipment” can become shorthand for a booking, a bill of lading, one or more containers, a commercial movement, or the object against which customer activity is organized. These concepts often travel together, so treating them as one object works—until it doesn’t.

Containers roll to later sailings. Documentation is reissued. A bill of lading describes multiple containers. Customer and billing relationships attach at different levels. Exceptions in the real world become exceptions throughout the product.

My approach

1. Identify the real-world entities.
2. Define what makes each entity distinct.
3. Map their relationships and lifecycles.
4. Test the model against difficult cases.
5. Decide which complexity the product should expose and which it should absorb.

The goal is not conceptual purity. A better model should reduce exceptions, clarify ownership, improve automation, and make future product decisions easier.