Reading the Omani Mulkiya: The Fields That Break Extraction

Easy, because it is a fixed-layout card: the same fields in the same places, issued by one authority, printed to one design. That is the opposite of a bank statement, where every issuer invents its own structure. Hard, because the fields that matter commercially are also the ones most likely to be misread — and a vehicle registration is usually the input to something automated, so a wrong character propagates.

The fields, graded

The ranking is counter-intuitive and worth dwelling on. A seventeen character VIN is long, which sounds worse and is actually better: length brings structure, structure brings validation, and a VIN carries a check character that rejects most single-character misreads outright. A plate is four or five characters with a letter component and no internal redundancy at all. Every character has to be right, and nothing in the field itself can tell you when one is not.

The two confusions that produce nearly all plate errors

The first is character shape. In a short alphanumeric field, 0 and O, 1 and I, 5 and S, 8 and B are the classic substitutions, and a plate gives the model no context to disambiguate them — unlike a word, where surrounding letters constrain the answer. Knowing which positions in the local plate format carry letters and which carry digits removes most of this at a stroke, because it eliminates the wrong class of character before the model has to choose.

The second is numeral system. Omani documents may render numbers in Western digits or Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩), sometimes both on the same card, and a pipeline that assumes one will silently mis-handle the other. This is the same class of problem that makes Arabic bank statements harder than English ones, and it needs handling at the character level rather than by post-processing a wrong answer.

Bilingual layout is a reading-order problem before it is a language one

A card carrying Arabic labels alongside Latin-script values mixes text directions inside a single line. Extract text in the order it appears in the file rather than the order it appears on the card, and values arrive attached to the wrong labels — which is worse than failing, because the output looks structurally valid.

The defence is not better character recognition. It is anchoring to position: on a fixed-layout card you know roughly where each field sits, so you read regions rather than reading the page and hoping to parse it. That makes the layout the primary key and the text secondary, which is the opposite of how general-purpose OCR works and the reason a document-specific extractor beats a generic one here.

What the capture does to your accuracy

In practice these cards arrive as phone photographs, and the physical document fights you. It is laminated, so a flash produces a specular highlight directly over whatever field it lands on. It is held in a hand, so it is skewed and often slightly curved. It lives in a glovebox, so it is scuffed. And it is frequently photographed indoors at a counter under mixed lighting.

The highest-return engineering here is usually not in the model at all — it is in capture guidance. Detecting the card edges live, telling the user the image is too dark or too angled, and rejecting a frame with a highlight over a field before accepting it will do more for field-level accuracy than a better recogniser applied to a bad photo. A system that accepts any image and reports low confidence afterwards has moved the work to a review queue that someone has to staff.