A model's probability of assigning the correct GL codes is governed by two things: how well it recognises the document in front of it, and how completely it can resolve that document to a full set of GL codes.
Every model in the AzoraOne pool has a structure — created autonomously at the moment of a bookkeep request, by connecting the dots between the bookkeeping data and the values found in the source document. That structure determines two things: its affinity for incoming documents and its intrinsic efficacy when processing them.
Together, those two variables determine whether a model wins the selection competition and what quality of result it delivers. Understanding both is understanding how accuracy compounds.
The degree of match between a model's structural patterns and the patterns present in an incoming document. High affinity means the model recognises the document. Low affinity means it's out of its depth.
The model's ability to locate target values within a recognised document and generate a complete, balanced set of GL codes. A model can recognise a document but still produce an incomplete or skewed result — that's an efficacy problem, not an affinity problem.
When a document arrives in Play mode, every eligible model in the pool evaluates it against its own structure — supplier signatures, document structures, value distributions, recurring document patterns captured at creation. The degree of match is its affinity score.
A model created from a bookkeep against a specific freight supplier will have very high affinity for that supplier's documents and near-zero affinity for invoices from an unrelated software vendor. This specificity is a feature. A model that is highly confident in its domain is more useful than one that hedges across all of them.
Affinity is determined entirely by a model's structure — established at creation, when the autonomous model builder connects the bookkeep data to the patterns in the source document. The more bookkeeps performed against similar documents, the more models exist in the pool with high affinity for that document type.
A model can have high affinity — it recognises the document — and still produce an incomplete result. Efficacy is the second gate. It measures a model's intrinsic ability to locate its target values within a recognised document and resolve them into the correct set of GL codes — at whatever coding resolution the user has chosen for that specific case.
Think of it like this: affinity gets you in the door. Efficacy determines whether you actually know where everything is once you're inside. A model with high affinity and low efficacy recognises the document but guesses at the detail. A model with high efficacy resolves every required field cleanly.
Like affinity, efficacy is determined by a model's structure — specifically by the quality and completeness of the bookkeep data and source document values that the autonomous model builder connected when the model was created. Models created from complete, well-coded bookkeep requests develop higher intrinsic efficacy than those created from sparse or inconsistent data.
A model's probability of processing a given document is a function of both variables — neither one alone is sufficient. And both are determined entirely by the model's structure: how the autonomous model builder connected the bookkeep data to the source document values at the moment the model was created.
This is why the Record primitive matters. When a bookkeep contains information the pool hasn't encountered before — a new supplier, an unfamiliar document pattern, a different coding resolution — AzoraOne creates a new model, expanding what the pool can recognise and resolve.
When a document arrives, models compete. AzoraOne evaluates every eligible model — its affinity score for this specific document, its historical efficacy on similar documents — and selects the one most likely to produce a complete, correct result.
The winner delivers the result. If the user's subsequent bookkeep confirms it, the model gains fitness — its selection probability rises for similar documents in future. If the result diverges from the bookkeep, the model is penalised: its fitness drops, and it becomes less likely to be selected again. Over time, the pool evolves. High-fitness models dominate their domains. Low-fitness ones recede. This is selective pressure applied to bookkeeping logic.
The effect compounds over time. Your customers don't just get automation — they get automation that gets better the more they use it. Every document processed is a data point that sharpens the pool for the next one.
More bookkeeps → more novel information encountered → more models created → broader pool coverage → more accurate results. The loop runs automatically. Your customers grow the pool just by doing their job.
The pool isn't static. When a bookkeep request or source document contains information that is new to the pool, AzoraOne creates a new model — expanding what the pool can recognise and resolve. The platform improves by running — no manual intervention, no configuration changes required.
An invoice or other source document is submitted. The model pool enters evaluation. Every eligible model scores its own affinity for this document — instantly.
The model with the highest combined affinity and efficacy profile is selected. It processes the document and returns the correct GL codes at the user's preferred coding resolution — in real time.
If the user's subsequent bookkeep confirms the result, the winning model gains fitness — its selection probability rises for similar documents. If not, it is penalised and recedes in the pool. Over time the pool evolves. High-fitness models dominate their domains. The rest recede.
Sandbox access gives your team a live environment. Real documents. Real model competition. Real GL codes returned at the user's preferred coding resolution — from the first request.
Get sandbox access