XTR Vision

Triage & Grading Project

Pre-Polishing Triage Estimation | Multi-Tenant Architecture | AI Model Design

March 2026

2

VisionL System Overview

What is VisionL?

Automated computer vision system for grading used/refurbished smartphone screens
Captures before & after polishing scans; generates DefectInfo.txt per scan with per-defect attributes
Aligned to CTIA v5.0 grading standard
XTR is the vendor; clients are refurbishment facilities deploying the equipment

Server-Side Architecture

VisionL stations capture scans and generate DefectInfo.txt locally.

Files upload to XTR server where:

OBB overlap matching runs
ML model predicts triage outcome
Results pushed back to client

No local inference engine needed on client stations

Two-Phase Assessment

Phase 1: TRIAGE

AI-driven: ML model predicts post-polish grade from raw defect features

Output: Predicted grade + confidence

Phase 2: GRADING

CTIA v5.0 criteria: defect count by level (L1–L4) per surface area

Output: Final grade A / B / C / D / E

3

Current Rule-Based Triage Model

How triage pass/fail is determined today

Gray Difference (GD%): pixel deviation from brightest pixel in 32×32 area — infers scratch depth from shadow contrast

Depth Levels & Color Classification

Level 0GD < 10%
Surface only

Level 1GD 10–40%
Shallow

Level 2GD 40–70%
Medium

Level 3GD >70% / ≤160px
Deep

Level 3+GD >70% / >160px
Very deep

Rule-Based Decision Logic

Thresholds: Green+Cyan ≤ 200 | Yellow ≤ 10 | Magenta ≤ 2 | Red = auto FAIL Input: Color class counts Output: Binary PASS / FAIL

Limitations: Short-but-deep scratches may pass incorrectly · Manual threshold tuning per model · No learning from outcomes

4

Proposed AI-Driven Triage Model

Pre-polishing triage estimation using historical before/after data

Core Idea: Train ML model on historical before/after polish pairs to predict post-polish grade per scratch. Replace static color-class thresholds with learned polishing outcome probabilities.

Model Input Features

Per-scratch raw features:

Length, width, total area
GD% band pixel counts (4 bands)
Deep area ratio (GD>70% / total)

Context features:

Device model, surface zone
Polish machine + pad type

Model Output

Predicted post-polish grade (A/B/C/D/E)
Confidence score
Triage recommendation

Advantages over Rule-Based

Adaptability
Learns from production data; improves with volume; client-specific fine-tuning

Edge Case Handling
Model sees full depth profile — handles short-but-deep scratches that fool rule-based thresholds

Richer Input
Uses raw length, width, & depth distribution instead of just pixel counts

Granular Output
Predicted grade + confidence instead of binary PASS/FAIL

5

Pre-Polishing Triage Estimation Engine

Before polishing: AI model predicts post-polish grade from DefectInfo.txt → advises operator whether polishing is worthwhile

1

Pre-Polish Scan

VisionL captures screen
Generates DefectInfo.txt
with OBB + GD bands

▶

2

Feature Extraction

Raw feature vector per defect:
length, width, area,
GD% band pixel counts

▶

3

ML Prediction

XGBoost model on XTR server
predicts post-polish
attributes per scratch

▶

4

Grade Computation

Apply CTIA v5.0 grading
to predicted attributes
Compute A/B/C/D/E

▶

5

Operator Guidance

Current vs predicted grade
Confidence score
Polish / Skip / Review

Operator Output Display

C

Current Grade

B

Predicted Post-Polish

High

Confidence

Polish

Recommendation

All inference runs server-side on XTR server (CPU-only, XGBoost) — no local ML runtime needed on VisionL stations

6

Historical Data Collection Design

Matching method: OBB overlap matching from before/after DefectInfo.txt files (no image access server-side)

500+

matched before/after
scratch pairs needed
(min viable training set)

BEFORE Polishing (DefectInfo.txt)

Defect ID, Device ID, Timestamp
Device model, surface zone (AA/A/B)
Length, Width, Total Area (px)
OBB_Angle (from cv2.minAreaRect)
CropOrigin_X, CropOrigin_Y
GD% band pixel counts (4 bands):
0–10% | 10–40% | 40–70% | 70%+
GrayMax − GrayMin (single GD scalar)
RectColor (Green/Cyan/Yellow/Magenta/Red)

AFTER Polishing (DefectInfo.txt)

Same enhanced DefectInfo.txt format
Matched via OBB overlap (not Defect ID)
Post-polish: length, width, area
Post-polish GD% band pixel counts
Post-polish OBB_Angle, CropOrigin
Status per scratch:
Removed / Reduced / Unchanged / New

7

Simulation Model Design

Raw Feature Vector vs. Type 1–6 Binning

Model Input Features (per scratch)

Continuous values (no binning):

Length, Width, Total Area, Deep Area (px)

GD% depth band pixel counts:

Band 1: GD 0–10% (surface)
Band 2: GD 10–40% (shallow)
Band 3: GD 40–70% (medium)
Band 4: GD 70%+ (deep)

Context: Device model, polish process ID, GD% mean/max

Why Raw Values > Type 1–6 Binning

XGBoost learns optimal split points on continuous features — pre-binning discards granularity.

GD% pixel counts per band give the full depth distribution, not just a single class label.

Type categories still useful for operator display — just not as model input.

Model Output (per scratch)

Predicted post-polish length, width, area, deep area
Predicted GD% per band
Removal probability (0.0–1.0)
Confidence: Low / Medium / High

8

Scratch Matching: DefectInfo.txt Gap Analysis

Current DefectInfo.txt (b0.145)

DefectNumber
CenterAxis_X, CenterAxis_Y
RectColor (G/C/Y/M/R)
GrayMax − GrayMin
DefectLength (AABB)
DefectArea, DefectWidth

AABB = axis-aligned bounding box
Coords relative to crop image

Gaps for Matching

No scratch angle/orientation
AABB inflates area 10× for 45° scratches

No depth distribution
Single GD scalar, need per-band counts

No crop-to-device mapping
Can't align coordinates across scans

Recommended Additions

OBB_Angle — Critical
Orientation of min-area rotated rect

CropOrigin_X/Y — Critical
Crop offset for absolute device coords

GD Band Counts (×4) — Critical
Pixel count per depth band

New Field	Priority	Purpose
OBB_Angle	Critical	Orientation of min-area rotated rect. cv2.minAreaRect() — fast.
CropOrigin_X/Y	Critical	Crop offset → absolute device coords. Cross-scan alignment.
GD Band Counts (×4)	Critical	Pixel count per GD% depth band. Depth fingerprint for matching.
TrueLength	High	Actual scratch path length (not AABB diagonal).
DefectCentroid_X/Y	Medium	Actual pixel centroid vs AABB center. Phase 2.
ClusterMemberIDs	Medium	Sub-defect IDs in cluster for partial removal matching.

9

OBB Overlap Matching (DefectInfo.txt Only)

No raw image access needed server-side. Match before-defect OBBs against after-defect OBBs using only the two DefectInfo.txt files.

Step 1: Load Before OBBs

For each defect: read center (X,Y), OBB_W, OBB_H, OBB_Angle.

Reconstruct 4 OBB corners from center + size + angle (simple trig).

Convert to absolute coords: add CropOrigin offset for device-frame coordinates.

Step 2: Align + Find Overlaps

Global alignment: compute affine transform from device frame landmarks.

Transform all after-defect coords into before-scan coordinate space.

For each before-defect OBB: find all after-defects whose aligned OBB overlaps (rotated rect intersection test, 3–5px padding).

Step 3: Build Training Sample

Zero overlaps: Fully removed (after values = 0).

1+ overlaps: Aggregate: sum area, max length, max GD, sum band counts.

Training row =
Before: L, W, area, GD, bands, angle
After: agg L, W, area, GD, bands
Meta: device, polish, equipment

Advantage: Server receives only two small DefectInfo.txt files per device pair (typically <10KB each). No crop images uploaded. Matching is pure coordinate math. If a scratch is polished below detection threshold, it correctly reads as fully removed.

10

Simplified Pipeline and Edge Cases

End-to-End Pipeline (no image access server-side)

Before scan completes — VisionL saves DefectInfo.txt with OBB + GD bands + CropOrigin
Device goes through polishing
After scan completes — VisionL saves new DefectInfo.txt (same enhanced format)
Pair linking (server-side) — Match before/after via device ID; compute affine transform
OBB overlap matching — For each before-defect OBB, find overlapping after-defects. Pure coordinate math.
Generate training sample — One row per before-defect: before features + after aggregated + metadata

Data Flow: Per scan: DefectInfo.txt only (<10KB) · No crop images on server · Sub-second compute per device pair

Edge Cases

Overlapping before-OBBs (clusters) — Each before-defect is its own sample. One after-defect may map to multiple. Model learns this.

Scratch splits into fragments — Multiple after-defects overlap one before-OBB. Aggregate: sum areas, max length, sum bands.

Below-threshold removal — Polished below detection = zero after-defects in OBB = fully removed. Correct for grading.

New scratches in after-scan — After-defects not overlapping any before-OBB = new damage. Flag separately.

11

Visual Walkthrough: OBB Overlap Matching with Sample Data

Before DefectInfo.txt (enhanced format)

# No CenX CenY Color GD Len Area Wid Angle GD0-10 GD10-40 GD40-70 GD70+ 22 1245 680 Yellow 45 85 340 5 32.5 120 95 80 45 11 890 455 Cyan 18 42 126 3 -15.2 100 26 0 0 35 1520 510 Magenta 72 120 960 8 67.8 180 220 350 210 7 520 780 Green 6 32 64 2 10.0 60 4 0 0 29 1100 850 Red 88 140 1120 10 -45.0 200 280 420 220 CropOrigin: X=200, Y=150

After DefectInfo.txt (same device, post-polish)

# No CenX CenY Color GD Len Area Wid Angle GD0-10 GD10-40 GD40-70 GD70+ 15 893 458 Green 8 20 40 2 -14.8 35 5 0 0 6 1310 565 Green 6 15 30 2 65.0 28 2 0 0 CropOrigin: X=205, Y=148

Matching Results (5 training samples generated)

#22 Yellow GD=45 → No overlap → FULLY REMOVED (after=0)

#11 Cyan GD=18 → After #15 GD=8 → REDUCED 56% (training row)

#35 Magenta GD=72 → After #6 GD=6 → REDUCED 92% (training row)

#7 Green GD=6 → No overlap → FULLY REMOVED (after=0)

#29 Red GD=88 → No overlap → FULLY REMOVED (after=0)

12

Grading Framework (CTIA v5.0 Standard)

Defect Level Classification

L1
≤0.5mm length
≤0.05mm width
Not easily visible

L2
≤1.5mm length
≤0.25mm width
Visible, no feel

L3
≤2.0mm length
≤0.5mm width
Feel, doesn't stop

L4
≤2.0mm length
>0.5mm width
Feel, does stop

Grade Thresholds — "AA" Main Display (max defect count)

Grade	L1 (≤0.5mm)	L2 (≤1.5mm)	L3 (≤2.0mm)	L4 (≤2.0mm)	Description
A	0	0	0	0	Like new
B	15	7	3	1	Light wear
C	Unlim	Unlim	60	30	Moderate wear
D	Unlim	Unlim	Unlim	Unlim	Heavy wear
E	Unlim	Unlim	Unlim	Unlim	Non-functional

13

Grading Criteria Management

Policy Inheritance Chain

Project-level Profile

→

Client Default

→

XTR / CTIA Standard

Grading Profile Examples

CTIA Standard

DEFAULT — CTIA v5.0 thresholds. Full triage enabled.

AA: L1–L3=0, L4=0 | B: L1=15, L2=7, L3=3, L4=1 | C: L3=60, L4=30

Strict

PREMIUM — Half CTIA allowances. For high-end resellers or premium programs.

Lenient

BUDGET — 1.5× CTIA allowances. For bulk/budget markets or trade-in programs.

Custom Client

CONTRACT — Fully configurable. Scoped per client / project / device model / market.

14

Multi-Tenant System Architecture

XTR — Platform Owner
Global baseline model | CTIA policy | Software updates | Aggregate analytics

Client A (Tenant)

Custom grading policies | Own data scope | Optional client model

Site 1

Site 2
Line 1 Line 2

Client B (Tenant)

Custom grading policies | Own data scope | Optional client model

Site 1

Site 2
Line 1 Line 2

15

System Infrastructure

Existing xtr-server / xtr-client stack with AI triage integration

Client Site (VisionL)

VisionL_AST Software
Captures before/after scans
Generates DefectInfo.txt
(enhanced: OBB + GD bands)

Posts to xtr-server:
Vision result + DefectInfo.txt content in API payload

Receives back:
Triage prediction (grade, confidence, rec.)

No local ML runtime
No model files on client

AWS Cloud (xtr-server)

Elastic Beanstalk (Python)
Existing API endpoints + new /triage

XGBoost Module — loaded at startup, in-memory inference (~μs), CPU-only

OBB Matching Engine — pairs before/after defects, pure geometry

MySQL (RDS) — existing tables +
defect_info matched_pairs triage_predictions

xtr-client (S3 + React)

Static React app on S3

Vision reports dashboard

Triage results display

Calls xtr-server API

Model Retraining

Scheduled weekly/nightly
Cron on EB or Lambda/Fargate
Reads matched_pairs, trains new model, hot-swaps in EB

16

AI Model Architecture

XGBoost / LightGBM — Gradient Boosted Trees | CPU inference | No GPU needed | ~1–10 MB model

Fast CPU
inference

Small model
(fits in RAM)

Excellent on
tabular data

Interpretable
outputs

Easy incremental
retraining

INPUT (per scratch from DefectInfo.txt)

Raw continuous features:
Length, Width, Total Area (px), OBB_Angle

GD% band pixel counts (4 bands):
0–10% | 10–40% | 40–70% | 70%+

Context: Device model, surface zone, polish ID

▶

OUTPUT (per scratch)

Predicted post-polish:
Length, width, area, deep area, GD% band counts

Removal probability: 0.0–1.0

Confidence: Low / Medium / High

Triage: predicted grade (A–E)

Training Pipeline (on AWS — same EB or scheduled Lambda/Fargate)

1

OBB match pairs

in MySQL

▶

2

Scheduled train

XGBoost fit

▶

3

Evaluate

held-out set

▶

4

XTR review

& approve

▶

5

Hot-swap model

in EB server

17

Data Ownership & Federation

Phase 1 — XTR Baseline

XTR trains and maintains universal model using aggregate data from all sites
Baseline model deployed to ALL client sites on day one
No client needs their own data to benefit immediately
XTR's model and training data are proprietary — not exposed to clients

Phase 2 — Client Adaptation

Client accumulates local before/after production data over time
Client-specific model variant on top of XTR baseline (min 1,000+ scratch pairs)
Client model refines estimates using local process behavior
XTR may use client data (aggregated, anonymized) for baseline — with opt-in consent

18

Key Decision Points & Open Questions

1 Device matching across scans

How to link pre/post-polish scans for the same device? (Serial number, QR code, conveyor position?)

2 Scratch position matching

How to match same physical scratch across captures? See OBB overlap matching slides for recommended approach.

3 Data storage location

Where does the simulation database live? Same MySQL (RDS) on existing xtr-server — new tables, no separate EC2.

4 Polishing process variability

Track different machines, compounds, or operators as separate variables in training data?

5 First data milestone

Recommended: 3 months parallel data collection before enabling estimation feature.

6 Grading profile governance

Who can create/modify/approve grading profiles? (XTR admin only, client admin, ops manager?)