Khaonix replaces a person's routine check. That is only acceptable if a confirmation from Khaonix is at least as reliable as the one it replaces, and if someone can later see why it was given. This page explains how both are ensured. The examples on this page are from payroll, the first application. The method is the same for any pair of documents where a result must match what triggered it.
For each pair of documents, a control states which fields on the result must agree with which fields on the trigger, and how. Every rule has exactly one of four outcomes. Nothing is assumed. The rules below are examples from the salary letter control; a client's control carries its own.
payslip.salary = letter.salary ÷ 13 | ÷ 12The monthly salary matches the annual salary in the letter, in 13 or 12 instalments. Which one held is recorded.payslip.bonus = letter.bonusThe bonus paid equals the bonus authorised, within a tolerance you define.payslip.period ≥ letter.effective_dateThe payslip belongs to a period on or after the date the change takes effect.payslip.employee = letter.employeeBoth documents concern the same person, matched on employee number and name, independent of name order across systems.The rule held. The confirmation carries the position of both fields on both documents.
The rule did not hold. The case goes to a person, with both values and both positions.
A letter without a payslip, or a payslip without a letter. Reported, never silently dropped.
A field outside the control, or a value the model could not read with confidence. Reported as such, never as fine.
The models that read the documents are trained without any of your documents. They are built from a specification of what the documents contain, and they read exactly that.
You name the fields your documents carry: amounts, totals, dates, identifiers. In payroll that is the standard backbone plus the fields specific to how you pay.
From that specification, Khaonix manufactures training documents in your layouts and languages, covering the layouts and edge cases real data happens not to contain.
A model is trained on the generated documents only. No real document of yours enters a training set, now or later.
The model reads the specified fields and nothing beyond. Its scope is written down, versioned and checked before it ships, so its limits are known in advance, not discovered in production.
This is why Khaonix can run on personal and financial documents at all. Where the documents are the ones you are least allowed to share, the only usable model is one that never needed them.
Each document type and each control is tested against a frozen population with known answers before it is used on a client's documents.
The pass criterion is not accuracy on average. It is zero false confirmations: no case where Khaonix said SAME and the answer was DIFF. On that population the stated coverage is measured as well, the share of fields the model reads with enough confidence to evaluate, so what the control covers is a number, not a claim. Zero on a finite population is a qualification result, not a guarantee about production; what makes it hold in production is that anything outside the qualified scope, an unreadable value, an unknown layout, a field without a rule, is escalated rather than confirmed. The size of the population and the errors injected into it are part of every qualification record.
The same test is repeated whenever anything changes: a new control, a new layout, a new model version, an added field. Nothing reaches a client's documents on the strength of an earlier result.
Injected errors are part of every population: salary changed, bonus altered, letter missing. Each must be found. A control that misses one does not ship.
A result you cannot trace is an opinion. Every Khaonix result records what was compared, where, by which rule, and by which version of everything involved.
The record is designed so that an internal control function or an external auditor can rely on it under frameworks such as SOC 1 or ISAE 3402: a complete population, a documented control, a reproducible outcome per case.
It does not access your systems. No interface, no database, no configuration in HR or payroll. It reads documents.
It does not determine why a difference occurred. It establishes that the result does not match the trigger. Where in the chain it went wrong is for the person who gets the case.
It does not learn from your documents. Models are trained on generated data before they ever see a client document, and they are not updated from client documents afterwards.
It does not report what it did not evaluate as fine. Fields outside a control, and values it could not read with confidence, are reported as not evaluated.
It does not guess a pairing. A letter and a payslip are paired on identifiers; where that fails, both are reported as unpaired.
It does not read everything. Each model reads the fields in its specification, for the layouts and languages it was qualified on. The scope is documented and can be extended, through the same qualification.
It does not certify the payroll calculation. A salary letter authorises an amount and a date; it does not specify working time, retroactive changes or collective agreements. Khaonix verifies that the authorised instruction is reflected in the result. Whether the rest of the payslip is computed correctly is the payroll system's job, and its own controls.
Khaonix would rather state precisely what it reads and be right, than claim it reads everything and be vague at the edge. A control that knows exactly where its competence ends is the only kind that can replace a person's.
One payroll month, or a handful of letter-and-payslip pairs, anonymised if you prefer. You see the review page, the evidence and the coverage on your own documents.