Let the model read, let the code decide

Most of the AI systems we build have the same shape. A language or vision model sits at the front and reads something messy: a supplement label, a supplier invoice, a microscopy image. Behind it sits ordinary code that makes the decision: a score, a price check, a schedule.

We keep those two jobs apart on purpose.

Models are good readers

A label photo, a scanned invoice or a pasted ingredient list is the kind of input that defeated software for decades. Every supplier lays things out differently, units vary, and half the text is noise. Modern models handle this well. Ask one to turn a label into a list of ingredients, forms and doses, and it will get it right far more often than any template or regular expression.

Models are poor deciders

Ask the same model to rank that supplement, or work out the price per unit of active ingredient, and two problems appear. It can give a slightly different answer each time, and it cannot tell you exactly why. For a score a customer will rely on, or a number a sales rep will quote, neither is acceptable.

So we split the system

• The reading layer uses a model to turn messy input into structured data, such as JSON with a fixed schema. The output is validated before anything else touches it, and anything the model is unsure of goes to a person.
• The deciding layer is plain code. Rules, arithmetic, thresholds and rankings live here, written down where they can be read, tested and changed.

In SuppScore, a model reads the label, and a deterministic engine ranks the product against the client's ingredient standards. The same product always gets the same score, and every score traces back to a rule. When a standard changes, the team edits a rule and re-ranks every product, with no retraining.

What this means if you are buying AI

When someone proposes an AI system, ask which parts are the model and which parts are code. If the answer is "the model does everything", ask how you will check its answers, and what happens when it changes its mind. The most useful systems we have built are mostly ordinary software, with a model doing the one job ordinary software could not.