Inventory ops for a warehouse auction

A giant warehouse full of auto parts and auto upholstery materials needed to become organized, described, and deployed to auction websites — quickly. Not a catalog site. Not a retail store. Auction listings, warehouse velocity, and thousands of SKUs, most of them visual — parts photos, upholstery samples, finished-good swatches. That's the problem we solved.

The Problem

The warehouse operator had accumulated inventory over years: OEM auto parts, aftermarket components, rolls of automotive upholstery fabric, finished seat covers, interior trim kits. Everything arrived without systematic cataloging. Boxes, bins, pallets — organized spatially in the warehouse but not in any searchable system.

The auction channel demanded speed and accuracy. Listings needed good photos, accurate descriptions, dimension and weight specs, condition assessments. A parts lot might have fifty items; an upholstery roll might need diameter and yardage calculations. Manual entry couldn't scale. The existing approach — employees photographing, describing in text files, posting manually — hit bottlenecks at a few hundred listings.

Off-the-shelf inventory systems failed this use case:

ERP systems (Salesforce, NetSuite) assume clean, structured product data. They want SKUs, serial numbers, consistent attributes. The warehouse had messy, variable SKUs — one-off lots, mixed condition items, visual-first descriptions. The data model didn't fit.

Generic inventory apps assume retail or e-commerce. They don't handle auction format output, photo-first intake workflows, or rapid throughput to marketplace listings. They optimize for organized warehouses, not auctions.

Custom build from scratch — we considered this. But the requirement was speed to deployment, not building a data model from zero. We needed the problem solved in weeks, not months.

What we needed was a custom system built for this specific constraint: warehouse intake, photo classification, structured inventory, auction listing output.

System Architecture

We built a four-component architecture:

Component 1: Autoparts Repository

The repository is the system of record. It holds:

- Inventory records: Each item gets a structured record — part number or lot ID, category, condition, dimensions, weight, location in warehouse - Media assets: Photos attached to records, multiple per item - Listing templates: Format definitions for auction output — describing fields, photo requirements, formatting rules for each marketplace type - Deployment queue: Tracks items pending listing, in review, published

The repository is custom PHP with SQLite — lightweight, fast, no external database dependencies. It's optimized for the specific data shapes we need: parts, upholstery, finished goods, one-off lots.

Component 2: Vision Classification Pipeline

This is where custom beat off-the-shelf:

Photo intake: Warehouse workers photograph items with mobile devices. Photos upload to the system — raw, sometimes poorly lit, inconsistent framing.

Computer vision processing: A Python-based pipeline analyzes each photo:

- Object detection — identifying the part type, upholstery category, or finished-good classification - Quality scoring — flagging blurry, poorly lit, or insufficient images - Attribute inference — estimating dimensions from reference objects, counting upholstery rolls

Human-in-the-loop validation: The CV model proposes classifications. Human reviewers approve, correct, or reject. The system learns from corrections.

For auto parts, the model learned to identify Make/Model/Year context from visual patterns. For upholstery, it learned fabric type and pattern classification. The training set was the warehouse's own photos — domain-specific, not generic ImageNet weights.

Component 3: Sanctum Agents for Orchestration

We deployed Sanctum agents for workflow orchestration:

- Batch agents: When new inventory enters, agents route items through classification, populate repository records, queue for review - Review agents: Queue items for human review at checkpoints, route based on classification confidence - Listing agents: When items are approved, agents compose auction descriptions from structured data, format for target marketplaces, prepare deployment

Agents handle the throughput. Humans handle judgment. This is the pattern: agents accelerate; humans validate.

Component 4: Listing Deployment

The final component transforms repository records into auction listings:

- Template rendering: Repository data + listing templates → formatted listings - Marketplace formats: eBay-class marketplace structure (described conceptually, not by platform name) - Batch deploy: Multiple items deploy together — lot-based listings, grouped by category

The deployment path: warehouse photo → repository record → auction listing. Fully automated from approval to live listing.

What We Shipped

Three outcomes:

Organized inventory: Every item in the warehouse is now a structured record with photos and specs. Searchable, auditable, trackable. No more "where is that part?" questions.

Faster listing throughput: Manual entry did dozens of listings a day. The system processes hundreds. Classification and listing generation are the bottlenecks removed.

Photo-first workflow: The vision pipeline handles what manual intake couldn't — consistent photo quality, automated classification, attribute inference from images. Human time shifted from entry to review.

The warehouse operator went from weeks of manual posting to continuous deployment. Auction listings went live faster with more consistent data.

What We Learned

Three takeaways:

When custom beats ERP: Messy SKUs, auction velocity, photo-first intake — these are not Salesforce-shaped problems. Custom won because the data model fit the reality, not the other way around.

Vision + agents is the right pattern for warehouse intake: Computer vision handles classification at scale; agents orchestrate throughput; humans validate where judgment matters. This pattern transfers to other warehouse-scale visual intake problems.

Repository-first architecture: Building the system of record first — before adding AI or automation — gave us a foundation to optimize. The AI improved an already-structured process, not a broken one.

Closing

This was a data-science and operations problem wrapped in warehouse logistics. The solution was custom because off-the-shelf didn't fit — messy inventory, auction channel, visual-first intake.

If you're dealing with warehouse-scale inventory, auction deployments, or visual-heavy intake workflows — we're familiar with this problem space. The architecture above is one approach; it's not the only approach, but it worked for this constraint.

We run this in production every day. If you want the same capability for your program, or help turning ops data into a clear decision, get in touch.