Step 1: Collecting Evidence
The build decides what kind of evidence the member must submit. OCR builds ask for screenshots. ESO Markdown builds ask for a CharacterMarkdown export. ESO TONL builds ask for the advanced TONL export. Future game adapters can add their own sources without changing the member workflow: choose a build, submit the requested evidence, and continue.
For screenshot evidence, the bot uses Tesseract OCR to extract text from images. For structured exports, it parses named sections and fields directly. Clear screenshots still matter for OCR, while complete, unedited exports matter for Markdown and TONL.
Step 2: Fuzzy Matching
Once the bot has readable evidence text or structured fields, it compares them against the build. Rather than requiring an exact string match everywhere, OCR-style checks use fuzzy matching powered by RapidFuzz. This means "Refrshing" can still match "Refreshing" even though the spelling is slightly off.
Each item is checked using the item name, aliases, and any relevant game-specific catalog data. The best match score wins. If the match is strong enough, it counts as a hit. If it's close but not great, it counts as a "maybe." If nothing is found, it's a miss.
Excludes are checked first. If the OCR text matches an exclusion pattern for an item, that match is thrown out before scoring. This prevents "Refreshing Move" from counting as a match for "Refreshing."
Step 3: Two-Pass Scoring
OCR-style text matching runs two passes to maximize accuracy:
- Pass 1: Balanced Pass
- The first pass goes through the build items and tries to find matches in the OCR text using standard fuzzy matching thresholds. Items that clearly match get marked as hits. Items that are ambiguous get flagged for the second pass.
- Pass 2: Rescue Pass
- The second pass revisits items that didn't match in the first pass. It uses a more lenient matching threshold to catch near-misses that the balanced pass left behind. Items matched during rescue are counted as "maybe" matches, which contribute partial credit.
Structured Evidence Scoring
Structured evidence, such as ESO CharacterMarkdown, does not depend on reading pixels. GearCheck parses the export into known sections like character basics, equipment, skill bars, champion points, passives, and stats. Enabled sections in the build editor become checklist sections in the score report.
Structured checks can still miss when the export is incomplete, the wrong evidence source is selected, or the build asks for data that the chosen format does not include. For example, ESO TONL currently does not include champion point allocation, so CP checks belong in the Markdown spec.
Match Types
Each item in the build ends up in one of three states after scoring:
Match (full credit)
The item or field was found with high confidence. It counts as 100% credit toward the category score.
Maybe (half credit)
The item or field might be present, but the match isn't strong enough to be certain. OCR near-misses are typically caught by the rescue pass. Counts as 50% credit.
Miss (no credit)
The item or required field was not found. Either the member does not have it, the evidence did not capture it, or the wrong export source was submitted.
Category Weights
After scoring each category individually, the bot combines them into a final score using category weights. Each category has a weight, defaulting to 1.0, and categories with higher weights contribute more to the final number.
How it works
For each category, the raw category score is multiplied by its weight. Then all weighted scores are added up and divided by the total weight to produce the final percentage. A category with weight 1.5 has 50% more influence on the final score than a category with weight 1.0.
Score Thresholds
The final score sets the member's gear check status. These are the defaults the bot scores with:
| Status | Default score | What it means |
|---|---|---|
| Verified | 85 and up | Passed the build. |
| Tentative | 80 to under 85 | Close. Worth a manual review by a mod. |
| Borderline | 75 to under 80 | Missing significant items or fields. Needs better gear or better evidence. |
| Unverified | Under 75 | Too low. Gear doesn't meet the build spec. |
Verified
Default score: 85 and up
Passed the build.
Tentative
Default score: 80 to under 85
Close. Worth a manual review by a mod.
Borderline
Default score: 75 to under 80
Missing significant items or fields. Needs better gear or better evidence.
Unverified
Default score: Under 75
Too low. Gear doesn't meet the build spec.
Score Band and Mod Decision
Before a mod reviews a check, its verdict follows the score band. A mod's decision then replaces it.
| Score band | Verdict before review |
|---|---|
| Verified 85 and up | Verified |
| Tentative 80 to under 85 | Partial |
| Borderline 75 to under 80 | Failed |
| Unverified Under 75 | Failed |
Verified 85 and up
Verdict before review Verified
Tentative 80 to under 85
Verdict before review Partial
Borderline 75 to under 80
Verdict before review Failed
Unverified Under 75
Verdict before review Failed
When a mod decides
- Verified
- Verified sets the status to Verified on the check the dashboard shows.
- Partial
- Partial sets the status to Tentative on the check the dashboard shows.
- Failed
- Failed sets the status to Unverified on the check the dashboard shows.
In Discord, /mod approve gives Verified and /mod reject gives Failed. Partial is a dashboard choice.
The decision panel shows these words in your language. The post in the check's thread uses English.
Verified Minimums (Mod Overrides)
Sometimes the evidence parser gets it wrong, or a guild wants a human to make the final call. A mod can review the submitted evidence, confirm the gear is actually correct, and set a verified minimum using /mod override. The verified minimum means the displayed score won't go below that value, even if the automated score is lower. This doesn't change the raw parser results. It just says "I've manually verified this person's build is at least X%."
The Failsafe System
If a member repeatedly scores very low on a build, well below the threshold multiple times in a row, the failsafe system kicks in. The build gets locked for that member, preventing them from submitting more attempts until a mod unlocks it.
This exists to prevent people from spamming repeated evidence attempts hoping to get a lucky result. If someone genuinely has the right gear but keeps scoring low, a mod can review the evidence and either override the score or unlock the build.
Why Did I Get a Low Score?
If a score seems wrong, here are the most common causes and what to do about them:
Blurry or Low-Resolution Screenshots
OCR needs clear text to work. If the screenshot is blurry, zoomed out too far, or heavily compressed, the bot can't read the perk and item names accurately. Try taking a cleaner screenshot, ideally with the game UI at native resolution.
UI Elements Covering Gear Text
Tooltips, popups, chat overlays, or other UI elements can block the text the bot needs to read. Make sure the gear information is fully visible and not obscured by anything.
Missing Aliases in the Build
If the item's name appears differently in-game than what the build expects, it won't match. Admins can fix this by adding aliases to the item using /pack edit-item. Check the "Show Details" button on the score breakdown to see exactly what the bot found vs. what it expected.
Missing Items in the Build Spec
If items aren't in the build at all, the bot won't know to look for them. Admins can review and update the build using the pack commands.
Wrong Evidence Source
If a build is configured for ESO Markdown but the member submits screenshots, the bot will not evaluate the same fields. The reverse is true too: an OCR build expects screenshots, not an ESO export. Check the build editor and make sure the selected spec matches the instructions the member followed.
Debug With /pack test
Admins can paste OCR-style sample text into /pack test to see exactly how the scoring engine handles it. For structured ESO builds, use the dashboard import/test flow with a real Markdown or TONL export. This is the best way to figure out whether the issue is in the evidence, aliases, parser, or build spec itself.