ABOUT
PayrollCompare AI is what you can use today. Khaonix is the system that built it, and that system is the subject of this page.
Khaonix is built around a single inversion. Most document AI starts from your documents: you collect them, label them, train on them. Khaonix starts from what you already know. You tell it which items your documents carry, and it works backwards from there: manufacturing the data that teaches those items, evaluating the result, and producing a model that reads exactly them and nothing beyond. In PayrollCompare AI, those items are the wage types and totals specific to how a company pays its people.
This matters most where it is least visible. Because the data is manufactured from your specification, your real documents never enter the pipeline. There is no corpus of your documents in a training set. The model is bounded to what you specified, so its limits are known in advance rather than discovered in production. For documents that carry personal and financial detail, that boundary is not a feature people tolerate. It is the reason the approach is usable at all.
Why the method exists
The inversion is not a preference. It is a response to a problem that has no good answer the usual way. In regulated domains, the documents you would need to train on are the ones you are least allowed to use. Access to real documents is limited or prohibited outright. Privacy and compliance rules block sharing them. The anonymised samples you can get are structurally incomplete, as they are stripped of exactly the detail that makes a document what it is. And even a large real corpus cannot systematically cover the layouts, languages, and edge cases a reliable model has to handle, because real data only contains what happened to occur.
So training on real documents is slow, costly, and never quite complete. In the domains that matter most, it's generally not permitted at all. Manufacturing the training data from a specification is what makes the problem tractable: every layout and edge case can be generated on demand, every sample is internally consistent, and no real document is ever needed to teach the model. What began as a constraint became the design.
Every model is a bounded model
✓ Scope specified: you define exactly which items it reads
✓ Scope documented: what it handles is written down, not implied
✓ Scope versioned: each model is tied to the specification it was built from
✓ Scope checked: the model is evaluated against that specification before it ships
Why payroll first
The reusable part of Khaonix is not the payroll model. It is the system that manufactures a bounded model from a specification, without ever training on real documents. Underneath any one product sits a reusable core, a step that adapts it to a market's language and layout, and a step that adds the items specific to one company. The diagram is how that produces a single specialized model.
I chose payroll first on purpose. It is unforgiving about correctness, it spans systems that do not agree with each other, and the people who work in it can spot a vague claim immediately. If the method survives there, it has been tested against a hard case rather than a flattering one. Payroll is the first proof the machinery runs end to end. Not the limit of what it is for.
One specification, two architectures
A claim like "the specification is the asset, the model is disposable" is easy to write and hard to prove. Here is the proof I have.
The first production model was a vision model: it reads the rendered page as an image. Then I built a second model from the same specification, under an entirely different architecture: a layout model that reads the text and its position on the page. Nothing about the specification changed. The same catalog regenerated the training data, the same evaluation framework scored the result, and the same serving system now runs both models side by side in production.
Two consequences follow. First, the system is not tied to any model family: when a better architecture appears, the specification manufactures a new model for it, and the old one is retired without loss. What was learned lives in the catalog, not in the weights. Second, the two models check each other: the same document, read by two unrelated architectures, arriving at the same values, is a form of verification no single model can provide.
That is what "the model is disposable" means in practice. It has now happened once, in production, on purpose.
Verifiable today
Claims about method are cheap. These are the ones you can check:
- The models are trained exclusively on synthetic data. No client document has ever entered a training set.
- The bounded learning method is the subject of a European patent application.
- The first domain is payroll: unforgiving about correctness, and read by professionals who spot vague claims immediately.
- One specification has produced production models under two unrelated architectures, serving side by side.
Where it goes
What separates one document type from another, in this view, is configuration: which items, in which layout, represented which way. The machinery that turns that configuration into a working model stays the same. So the direction is a platform that produces client-specific and market-specific models as configuration rather than bespoke builds, with payroll as the first proof and further domains as the test of how far the separation holds. I state that as a direction, because that is what it is. The architecture is built to transfer. Proving the transfer is the next thing to do, not a thing already done.
Closing principle
I would rather tell you precisely what the system reads, and be right, than tell you it reads everything, and be vague at the edge. The boundary is the product. A system that knows exactly where its competence ends is worth more, in this domain, than one that claims it has no edges. You never build an AI pipeline. You tell Khaonix which items your documents carry. Khaonix builds the model.
If you have a document type this method should read, the conversation starts with your specification, not your documents. Contact me at kees@khaonix.ai.