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.
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 have to build an AI pipeline. You tell Khaonix which items your documents carry. Khaonix builds the model.