Why determinism matters to your auditor

The first question an auditor asks after a migration is not about speed or cost. It is: how do you know the new numbers are right?

The honest answer most teams give is a set of test cases and a sign-off meeting. That works when the migration is small. It starts to fail when hundreds of objects are in scope, and it fails completely if the tool that produced them could have produced something different had you run it on another day.

What does determinism actually mean in a conversion?

Determinism means the same input produces the same output, every run, on every machine. In a conversion tool it means the tool is driven by rules and a versioned knowledge base, not by a model that re-reads your code each run and improvises a plausible answer.

The distinction is easy to state and hard to overstate. A rules-based converter either converts an object to a known pattern or flags it for a human. It never quietly invents a variant because it felt like a Tuesday. The output you reviewed last month is byte-identical to the output you would get if you ran the conversion again today.

Why can you not just test a non-deterministic conversion more?

The core problem is not quality. A model-assisted conversion can be correct. The problem is provability. Evidence is something you can reproduce on request, months later, in front of a reviewer who does not trust you. A run that cannot be repeated is not evidence. It is a claim.

How does deterministic conversion behave when it is unsure?

It stops. That is the whole design. The rules cover the patterns the knowledge base knows. An object outside those patterns is flagged, with the reason, for a named engineer to resolve. Nothing is guessed, so nothing has to be un-guessed later.

This is why determinism and honesty travel together. A tool that stops and asks is a tool whose output you can trust by default. A tool that always answers is a tool whose answers you have to check, all of them, every time.

What does the audit evidence look like?

Two artifacts. First, the conversion record: for each object, the source, the converted output, the rule set and knowledge-base version used, and who approved any resolver proposals. Second, the reconciliation report: what was compared, how it was compared, and what matched.

Reconciliation does not mean sampling a few tables and calling it done. It means proving, per object, that the migrated logic reproduces the source results. Row counts, key distributions, financial totals at the level your business owners care about. When a stored procedure feeds a number the market sees, the reconciliation of that procedure is not optional.

Together, the two artifacts answer the auditor's question without requiring the auditor to trust anyone's memory. The evidence is in the system, it is reproducible, and it is dated.

How do you test that claim before committing?

Run the same conversion twice. Diff the outputs. A deterministic converter passes trivially, and the test itself becomes part of your evidence: same input, same output, verified.

Then ask the vendor where the conversion engine runs and what the model is allowed to touch. If the engine and the data both stay inside your environment, the proof is yours to keep, not the vendor's to promise.

Determinism is the floor, not the ceiling

Determinism does not make a migration correct. Reconciliation does that. But determinism is what makes reconciliation meaningful: you are proving something that will not change underneath you while the audit is in progress.

That is the standard we hold ourselves to. Every object, the same answer, every run, with the evidence to show for it.