A number you cannot reproduce is not a number you can trust
Every figure from Hamilton, our CFO agent, carries a fingerprint of its inputs and of the exact code that produced it, and each validated release is timestamped in the Bitcoin blockchain.
An AI that talks about money has two ways to be wrong: it can pick the wrong inputs, and it can do the arithmetic wrong. Hamilton never does arithmetic himself. Every figure comes from a deterministic calculation engine, and a public registry lets anyone check, without trusting us, that the numbers come from a specific, validated, unchanged engine, and when that engine existed. We publish the proof, not the engine.
What every number carries
Each result the engine produces is wrapped in an envelope with two fingerprints. Together they say: this code, run on these inputs, printed this. Anyone holding the inputs and the engine can rerun the calculation and must get the same bytes.
The input fingerprint
A SHA-256 hash of the exact inputs, in canonical form. If even one input value changes, the fingerprint changes.
The engine fingerprint
A SHA-256 fingerprint of the exact engine code that produced the result, with a short form like ham-04350554a5e3. Every code change produces a new fingerprint.
Who sees which fingerprint. Input fingerprints are shared with the people who hold the inputs and with auditors. They are never posted publicly, because the hash of a small private file can sometimes be guessed back to its contents. Only engine fingerprints are public.
How each release is locked
Each time the engine changes, it is revalidated and released, and the release publishes a manifest with the engine fingerprint and the validation results. Two mechanisms make the registry tamper evident.
A hash chain
Every release manifest names the previous manifest's hash. Changing or deleting any past release breaks every link after it.
A Bitcoin timestamp
The hash of each manifest is committed to the Bitcoin blockchain through OpenTimestamps, a free, open protocol. The proof shows the manifest existed no later than a specific Bitcoin block. Nobody, including us, can backdate it.
Commit publicly, reveal privately. The full validation dossier behind each release is private and goes to auditors under NDA, but its hash is public and timestamped. An auditor who receives the dossier can confirm it is exactly the one committed on that date, unchanged.
Validated against outside standards
Every release is validated against outside standards, not only our own tests. The framework follows computerized system validation practice from regulated industries (installation, operational, and performance qualification, as in GAMP 5), because that is what quality engineers already audit against.
| Study | Standard | What it shows |
|---|---|---|
| Performance qualification | NIST Statistical Reference Datasets, scored by log relative error (McCullough, 1998) | Statistical results match values NIST certified with 500 digit arithmetic |
| Independent cross check | Differential testing against separate implementations (numpy, scipy) | Tens of thousands of random cases agree with independently written formulas |
| Repeatability and reproducibility | Gauge R&R framing, exact Clopper-Pearson bounds | Hundreds of thousands of reruns, across processes and Python versions, produce identical bytes |
| Agent agreement study | Blind repeated trials, attribute agreement | How often Hamilton picks the right inputs and reaches the right answer |
Release 1.2.1 at a glance
Validation finds real defects. Validation of the previous engine found real defects. All were fixed, the engine got a new fingerprint, and every study was rerun on the new code before this release. A release never cites validation that ran on different code: the release tool refuses.
Verify it yourself
The registry is public at github.com/QualityEngineer-ai/hamilton-integrity. Checking it requires only Python 3. For the Bitcoin check, install the OpenTimestamps client, or drop the proof file onto the verifier at opentimestamps.org.
# chain and manifest hashes
python verify_release.py releases/registry.jsonl
# plus the Bitcoin timestamps
python verify_release.py releases/registry.jsonl --otsWhat this does not claim
It does not claim Hamilton's judgment is perfect. The agent agreement study measures it and publishes the interval.
It does not prove any particular number was correct for your business. It proves which code produced it and that the code was validated as described.
The Bitcoin timestamp proves when a manifest existed, not that its contents are true. The validation dossier, which auditors can inspect, is what backs the contents.
Think a check is weak?
Have a standard we should test against, or found a case where the engine is wrong? Tell us. If you are right, it becomes a permanent test in the next release.
Open an issue on the registry