Building a Custom Vision Automation Pipeline for a Northern European Salvage Vehicle Auction Operator

Industry

Automotive & Mobility

Geography

Northern Europe

Cooperation Period

6 months

About the Client

The client operated a salvage vehicle auction platform in Northern Europe. The operator combined physical yard operations with an online salvage auction platform for totaled vehicles. Buyers included dismantlers, exporters, repair shops, and cross border traders operating across the region. The client already ran a mature Adobe Experience Cloud environment for content management, campaign delivery, and buyer engagement analytics before Clixlogix’s engagement began.

Speed from vehicle intake to a live auction listing is a primary economic driver in salvage operations. Every day a vehicle sits before listing carries storage cost and delays return on the underlying claim. Photography sits on that critical path.

Fig 1 – Operational Shift Delivered by the Pipeline

Challenge

Manual image editing at regional sourcing volumes had become a hard ceiling on throughput, and several operational pressures made a computer vision automation initiative urgent.

Manual editing capped throughput. Human editors could not keep pace without adding headcount linearly, which was not a viable path at the operating margin. Every day a vehicle waited in the editing queue was a day of storage cost and delayed capital return.

Source variability broke listing consistency. Field adjusters, tow yard staff, and body shops captured images with different devices, under different lighting conditions, with inconsistent framing. Every downstream surface expected uniform presentation.

Damage visibility was inconsistent. Buyers bid on salvage vehicles primarily on the visible extent and location of damage. Coverage of damage across listing photography varied by editor. Operations reported that inconsistent damage visibility was correlated with lower bid participation on affected listings.

Marketing distribution stayed fragile. Auction listings, email campaigns, and downstream data feeds each had their own image spec requirements. Any change in a source image cascaded into rework across every distribution channel. The client’s Adobe Experience Cloud environment was mature and productive but had no automated way to receive consistent vehicle imagery upstream.

The initiative was scoped to automate ingest, quality checks, and damage detection at the source, then hand the enriched output cleanly into the client’s existing Adobe Experience Cloud stack.

Engagement Model

Full Process Delivery over six months. Clixlogix owned the scope from discovery through production rollout. The vision core was built as a standalone system on Google Vertex AI with an OpenCV preprocessing pipeline. The integration layer was engineered to feed cleanly into the client’s incumbent Adobe Experience Cloud environment.

Solutioning Under Scrutiny

Consulting Insight

Design decisions ran through the client’s VP of Engineering as a daily technical review during the solutioning phase. Alternatives were considered and closed with documented rationale before code shipped.

Managed custom training versus a custom fine tuned model. Two custom training paths were evaluated on the client’s own adjuster labeled reference set. The custom fine tuned approach was selected. It performed materially better on salvage specific damage classes than the managed alternative on comparable evaluation data.

From scratch architecture versus fine tuned model. Building a foundational model from scratch would have consumed a significant fraction of the engagement window with no clear accuracy upside inside the timeline. Fine tuning met the target inside the timeline.

Integration into the incumbent Adobe stack versus replacement. The client’s Adobe Experience Cloud environment was mature and productive. Integration was the faster and cheaper path.

Asynchronous queue backed pipeline versus synchronous processing. Regional ingest volumes spike unpredictably. Asynchronous processing held under peak load.

Specialist models per subtask versus a single multi task model. The team moved from one multi task model to three specialist models (quality, view, damage) after multi task accuracy plateaued below target in month two.

Solution

Clixlogix delivered a computer vision automation pipeline that carried vehicle photography from yard capture through to auction listing release. The build was structured across five functional layers, each with a distinct engineering discipline and a bounded interface to the layers around it. The layered separation kept vision engineering isolated from Adobe integration work, let the storage and orchestration layers scale independently of model serving, and let the client’s incumbent Adobe Experience Cloud environment stay untouched by pipeline internals.

The five layers moved a photograph through basic image preparation, inference on three specialist computer vision models, vehicle association through an intake session, resilient orchestration and storage, and the handoff into the client’s existing Adobe environment where listing decisions released to buyers. Each layer is described below, followed by the specific mechanisms that cut across layers: publication readiness, crop preservation, and the feedback loop into training data.

Fig 2 – System Architecture

Vision Core

Vertex AI hosted three specialist computer vision models trained on adjuster labeled data: an image quality classifier (output classes covered capture quality, blur, exposure, and occlusion), a view categorizer (front, rear, quarter, interior, VIN plate, odometer), and a damage region detector. Vertex AI handled training, model versioning, and inference serving.

A Python preprocessing pipeline running OpenCV handled pixel level operations across two stages.

The first stage applied basic image preparation to every image regardless of view type. Exposure normalization, orientation alignment, and white balance normalization ran here so the quality classifier and view categorizer saw comparable inputs across capture devices and lighting conditions.

The quality classifier and view categorizer then ran against the basic-prepared image. The quality classifier decided whether the image was acceptable for scoring. The view categorizer identified the view type. Frames flagged as unacceptable routed to retake.

The second stage applied view-specific preparation to images that would enter damage inference. Background segmentation and masking ran on exterior wide shots where a vehicle silhouette needed to be isolated from yard tarmac or workshop background. VIN close-ups, odometer close-ups, and interior views were not background masked because the vehicle occupies the frame.

The damage region detector then ran on eligible views (exterior and interior body panel views) using the second-stage output. The derivative fed to damage inference preserved the source frame boundaries; where background masking applied, the mask suppressed ground reflection and workshop clutter before the detector saw the frame.

Cropping happened later, for presentation renditions and downstream delivery. It did not feed damage inference.

NumPy handled pixel arrays. pandas handled evaluation dataframes and reviewer correction curation.

Fig 3 – Vision Model Specialization

A Claude Sonnet model from Anthropic produced draft condition notes from processed images and metadata. LangChain orchestrated prompt templating, output parsing, and structured response validation. Every drafted note carried an AI attribution flag and required adjuster review before it appeared on any buyer facing surface.

Every model output carried a confidence score. Downstream routing used the score against a configured threshold.

Capture Session and Vehicle Association

Vehicle to record association was established through an intake session, not through VIN OCR on individual photos. When a vehicle arrived at a yard, an intake session record was created carrying an intake session ID and the lot record from the client’s auction platform. Every photo captured for that vehicle (exterior views, interior, VIN plate, odometer) uploaded under the intake session ID via a capture manifest, which bound the photos as a set to the specific vehicle and lot.

VIN plate OCR on the VIN photo cross validated the intake session binding by matching the OCR read against the lot record. A mismatch, an unreadable VIN, or a session record with fewer than the minimum coverage set of photos routed the case to a manual association queue on the operations side.

Frames containing a single detectable vehicle silhouette were processed against the intake session binding. Frames where more than one distinct vehicle silhouette appeared could not be resolved by the pipeline alone. Such frames were flagged as ambiguous and routed to an adjuster review queue for a human to confirm which silhouette matched the intake session vehicle before inference proceeded.

Fig 4 – One Vehicle Through the Pipeline

Backend, Queue, and Resilience

Clixlogix built new APIs on Node.js for image ingestion and Python worker services for the preprocessing pipeline. Backend services beyond these belonged to the client’s existing enterprise footprint and were consumed as APIs where relevant.

Two separate Redis deployments backed the operational layer. One instance served as the job queue for image processing tasks (configured with a persistence and eviction policy appropriate for durable queue semantics). A second, separately deployed instance served as an inference cache. Cache entries were keyed on the tuple (content hash, preprocessing version, model version), so a reprocessed image against a newer model or preprocessing version did not return a stale cached result. Queue durability and cache eviction were configured independently at the instance level.

Duplicate prevention operated at the image level, via content hash on ingestion. It did not deduplicate at the vehicle or intake session level. A single vehicle received many photos across many intake events; the vehicle identifier bound the photos to the vehicle in the database, and the image identifier tracked the individual asset.

Failed job recovery ran on exponential backoff for transient errors. Non transient failures dead lettered to an operations UI for manual review and re queue.

Sustained inference outage triggered circuit breakers and a degraded mode. Under degraded mode the operations team continued publishing through the pre engagement editing workflow, with a metadata flag on affected listings to trigger reprocessing on service restoration.

Processing modules ran in Docker containers on Google Kubernetes Engine (GKE), which hosted the preprocessing workers, the Node.js APIs, and the integration workers. Terraform provisioned cloud infrastructure. Ansible handled application configuration on the compute layer. The environment ran in a single Google Cloud region with in region high availability.

The client’s existing image storage sat on AWS S3. Clixlogix hosted training and inference on Vertex AI on Google Cloud for the ML platform’s managed training, versioning, and serving benefits. Image data crossed from S3 to Vertex AI for inference and derivatives returned to S3. Cross cloud transfer cost and latency were an accepted tradeoff for the ML platform choice.

Storage and Data

PostgreSQL held the primary transactional store that Clixlogix built. It carried intake session IDs, vehicle to image linkage, asset URLs, confidence scores, damage classes, coverage completeness flags, and lineage IDs.

Google BigQuery held the ML pipeline’s training and evaluation environment: labeled reference sets, evaluation metric tables, and held out test sets tied to Vertex AI workflows.

AWS S3 held the source image archive unmodified and intermediate rendition storage.

The client’s existing Snowflake warehouse received a scheduled feed of curated insights for downstream business intelligence and executive reporting. Snowflake was the client’s incumbent warehouse; Clixlogix wrote to it rather than replacing it.

Integration with the Client’s Adobe Environment

The client already ran mature Adobe Experience Cloud operations. Clixlogix built the pipeline’s output contract to feed into that environment.

Serverless functions on Adobe I/O Runtime received processed renditions and metadata from the pipeline and uploaded them into AEM Assets through the ingestion API for the client’s AEM deployment.

Adobe I/O Events subscribed to AEM asset workflow events including approval, publication, rejection, and reviewer edits on notes and damage annotations. Event callbacks routed back into the pipeline’s PostgreSQL and BigQuery layers as reviewer signal capture. Not every callback constituted a training annotation; the training data curation flow filtered signals down to reviewer corrections in defined categories (damage region re annotation, category correction, note rejection or edit).

New configuration inside the client’s existing interfaces:

New routing rules directed high confidence outputs to the existing publish workflow and lower confidence outputs into an existing review queue repurposed with new triage criteria
New metadata fields (confidence score, damage class, coverage completeness, notes with attribution flag) were added to the AEM asset schema
New dashboard metrics (cycle time, review rate, confidence distribution) were configured within existing Adobe Analytics dashboards
New photography rules (minimum coverage, capture time quality checks) were pushed to yard capture devices

Operations staff continued to work in the same tooling surface. The primary user experience shift was the new review queue triage behavior.

Fig 5 – Publication and Review Flow

Publication Mechanics

Publishing an image asset in AEM is distinct from publishing an auction listing to buyers. AEM controlled image asset availability inside the content environment. The client’s auction platform controlled the release of a listing to buyers.

An auction listing became eligible for release when five conditions held on the listing:

Image quality and damage review status per applicable image type. Image acceptability (from the quality classifier: not blurry, not obscured, not underexposed) held on every image in the coverage set. Damage region detection ran on views where damage detection was in scope (exterior and interior body panel views), and required review was completed on any detection that fell below the confidence threshold. “No damage detected” was an allowed output of the damage detector and remained subject to the routing and review policy. Image acceptability and damage assessment are independent judgments; a confidently acceptable image does not validate the damage detector’s finding for that image
Coverage completeness was satisfied: a defined set of exterior angles, interior, VIN plate, odometer had been captured for the intake session
Required renditions were confirmed available on the buyer-facing delivery path, meaning successful upload into AEM Assets and any downstream processing to the buyer-facing rendering (Adobe Dynamic Media) had completed for each required rendition
Intake session binding was valid, with VIN plate OCR matching the lot record
Every AI drafted condition note attached to the listing had been reviewed and either approved or replaced by an adjuster

The auction platform released the listing when all five conditions were satisfied.

Authorized manual attestation could substitute for automated gate satisfaction in two specific cases. When VIN plate OCR failed on an otherwise valid photo set, an adjuster could manually confirm the VIN by comparing the physical plate against the intake record and attesting to the match through an override action in the operations UI. When inference was in degraded mode, publications could proceed through the pre engagement editing workflow with an adjuster attesting to damage assessment and quality on the listing photos. In both cases the attestation event was logged with the reviewer’s identity and reason code, and the listing carried an audit flag indicating manual attestation rather than automated satisfaction.

Once a listing was released to buyers, subsequent updates followed a different workflow. Revised condition notes, added photos, or metadata corrections were applied to the active listing without withdrawing it from auction. A listing was withdrawn from an active auction only when a correction revealed a material listing error that had to be re released after correction, subject to the auction platform’s business rules.

Image assets could reach AEM ahead of a listing being released to buyers. Asset availability and listing release were decoupled states, tracked separately in PostgreSQL and reconciled by the auction platform’s listing readiness check.

Crop Preservation

Derivative crops used for listing views and buyer emails were generated from the normalized full frame derivative. A crop validation rule required that every detected damage region above a size threshold on the source frame remain inside the crop; a proposed crop that would have excluded such a region was rejected and re generated.

Fig 6 – Original to Rendition

When no crop within the required aspect ratio could preserve every detected damage region, the pipeline fell back to the full frame with letterbox padding to satisfy the aspect ratio requirement. The full-frame fallback preserved damage visibility over cropped presentation. Cases hitting the fallback were flagged for review so the operations team could decide whether to accept the letterboxed rendition or revisit the source photography.

Low confidence detections routed to human review under the routing rules. Damage the detector missed entirely would not surface as an automated alert. The intake process included an adjuster’s review of the arriving vehicle. Where that review caught damage the detector had not surfaced, the operations team could annotate the listing manually. The extent of coverage this provided depended on the adjuster’s inspection depth and is not claimed here as universal.

Feedback Loop

Reviewer edits were captured with attribution and version and delivered into the pipeline’s data layers. Different edits fed different components:

Damage region re annotations went into the labeled data used to train the next version of the damage region detector
View category corrections went into the labeled data used to train the next version of the view categorizer
Note edits refined prompt templates for the condition notes generator and served as evaluation signal on prompt quality. The hosted Claude Sonnet model was not fine tuned by Clixlogix; iteration on note generation was through prompt engineering, not through weight updates

Each Clixlogix owned model version was evaluated against a held out validation set and run in shadow mode against production traffic before threshold behavior was updated.

Approval and publication events were logged as system state, not as training annotations. The distinction was preserved through the curation step.

Where the Vision Layer Struggled and How We Fixed It

Field conditions in Northern European yards during autumn and winter produced specific challenges the pipeline was tuned to handle.

Fig 7 – Field Conditions and Remediation

Low sun angle glare on chrome and paint. Adaptive exposure normalization reduced the glare artifact on typical frames. Frames where reflection obscured panel detail routed to retake.

Snow, ice, and salt occlusion. Occlusion detection ran as one of the output classes of the quality classifier. Frames flagged with occlusion above threshold routed to physical clearing or retake before downstream inference.

Reflective wet tarmac. Background segmentation removed ground reflection from the frame the detection model saw.

Wildlife collision damage signatures. A focused fine tuning pass on a curated reference set of wildlife collision frames materially improved detection on this class against a generic baseline.

Body shop fluorescent color cast. White balance normalization corrected the cast before rendition output.

Frozen and dead battery vehicles. A workflow rule scheduled interior photography for indoor intake bays after arrival. The pipeline accepted partial interior coverage with a metadata flag while listing release remained gated on the completed coverage set.

Multi vehicle intake frames. Tow yard operators occasionally shot the target vehicle with the next intake behind it in the same frame. Selection between visible vehicles cannot be resolved reliably from the frame alone. Ambiguous frames routed to an adjuster review queue, where a human confirmed which silhouette corresponded to the intake session vehicle before inference could proceed. Frames without a valid intake session binding also routed to the manual association queue.

Confidence threshold calibration. The initial threshold was set conservatively and pushed a larger than target proportion of frames into human review. A recalibration was evaluated in shadow mode against production traffic and promoted in the third week of live operation. Measurable movement in the operational metrics dashboards followed the promotion.

Results

Each result below states the measurement, the comparison scope, and the observation window.

Substantial Damage Detection Improvement

The damage region detector was evaluated on a held out reference set curated by adjusters and disjoint from the training set. Detection quality improved substantially against the pre engagement measurement baseline on the same reference vehicles.

Reduced Intake to Listing Cycle Time

Median cycle time from vehicle intake to live listing dropped between the six months preceding engagement and the first quarter following full production rollout.

Improved Buyer NPS

Buyer NPS collected through the client's ongoing quarterly buyer survey program improved between the survey preceding engagement and the survey following the first quarter of live operation. NPS remained a quarterly measurement; its appearance on the operations dashboard did not change the survey cadence.

Operational Lift Within Weeks

Movement on operational metrics (cycle time and review workload) became visible in the operations dashboards early in the live operation window, within the first weeks of full production release.

No Unplanned Pipeline Downtime

No unplanned pipeline or integration downtime through the first quarter. Downtime scope was the vision pipeline and Adobe integration components delivered in the engagement; client operated systems outside this scope carried their own service records. Monitoring source: the pipeline observability stack and the operations team's incident register.

What the Client Does Differently Now

The operations team’s daily work shifted from bulk image editing to exception review and metadata quality control. Bulk editing time recovered was reinvested into buyer engagement analytics and listing strategy work inside the same tooling. A portion of processed images route to human review on a typical week; the remainder move directly through the confidence scored gate.

Listing release decisions run against the listing readiness checks inside the auction platform. Buyer Net Promoter Score remains a quarterly measurement, surfaced in the operational dashboards the team already used.

A measured cycle time baseline is available to the pricing team for use in new insurance carrier contract discussions.

The trained dataset grows through a curated feedback loop, not automatically. Reviewer corrections in defined categories are QA reviewed and rolled into weekly training data additions. Each new model version is evaluated against a held out validation set and shadow tested against live traffic before threshold behavior is promoted. Reviewer corrections supported subsequent model evaluation and refinement.

Technologies and Tools

Layer	Technologies (with role)
Vision Models	Google `Vertex AI` hosted three specialist models trained on adjuster labeled data: a quality classifier, a view categorizer, and a damage region detector. Vertex AI handled training, versioning, and inference serving.
Vision Preprocessing	`Python` worker services running `OpenCV` (exposure normalization, background segmentation, orientation alignment, white balance), `NumPy` (pixel array operations), `pandas` (evaluation metric tables, training set curation, reviewer correction curation).
Condition Notes Generation	An Anthropic `Claude` model produced AI drafted condition notes. `LangChain` orchestrated prompt templating, output parsing, and structured response validation. No retrieval workflow ran in this layer.
Backend APIs and Workers	`Node.js` APIs (image ingestion and integration actions) and `Python` worker services (preprocessing) built by Clixlogix. Existing client enterprise services consumed as APIs where relevant.
Queue and Cache	Two separately deployed `Redis` instances. One as a durable job queue with retry and dead letter handling. One as an inference cache keyed on (content hash, preprocessing version, model version). Queue durability and cache eviction configured independently.
Compute Runtime	`Docker` on Google Kubernetes Engine (`GKE`) hosted preprocessing workers, Node.js APIs, and integration workers. Model inference stayed on Vertex AI. Single region deployment with in region high availability.
Infrastructure Provisioning	`Terraform` for cloud infrastructure (GKE cluster, VPC, service accounts, storage buckets). `Ansible` for application configuration on worker nodes.
Primary Transactional Store	`PostgreSQL` held intake session IDs, vehicle to image linkage, asset URLs, confidence scores, damage classes, coverage completeness flags, and lineage IDs. Existing client systems of record continued on their existing databases.
ML Data Environment	Google `BigQuery` held labeled reference sets, evaluation metric tables, and held out test sets tied to Vertex AI training workflows.
Source Image Archive	`AWS S3` held source images unmodified and intermediate rendition storage. Sat alongside the client's existing AWS footprint.
Client Warehouse (Reporting Target, Client Owned)	`Snowflake`, the client's incumbent enterprise warehouse. Clixlogix wrote curated insights on a scheduled feed for downstream business intelligence and executive reporting.
Internal UI Delivery	`Cloudflare` CDN in front of the operations UI and admin dashboards for staff facing latency. Buyer facing delivery stayed on the Adobe path.
Client's Existing Environment (Integration Target, Client Owned)	`Adobe Experience Cloud` (AEM Assets, AEM Dynamic Media, Adobe Campaign, Adobe Analytics). Integration through `Adobe I/O Runtime` (serverless upload actions using the ingestion path documented for the client's AEM deployment version) and `Adobe I/O Events` for callback based reviewer signal capture.

Services Delivered

AI Software & Application Development, Low Code, DevOps, Computer Vision Engineering, Language Model Integration

Team Composition

Delivery Manager, Computer Vision Engineer, Machine Learning Engineer, Backend Engineer, DevOps Engineer, Data Engineer, Adobe Integration Engineer

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

Australian suburban rental property with an inspector at the front door, phone raised, mid photograph

How an Australian PMS Built AI Image Detection Into Property Inspection Software

Digital Engineering Generative AI & ML Real Estate AI

AI food logging and meal intelligence case study featured image

AI Food Identification, Calorie Estimation, and Meal Intelligence for a Premium Nutrition Coaching App

Mobile App Development Digital Engineering Generative AI & ML Beauty, Wellness & Personal Care AI

View All Case Studies