Sample evidence pack
The proof your risk committee will ask for.
Every change Montora migrates comes with evidence: each recorded account replayed, every difference caught and explained, every decision on the record. This one is real.
- ACC0034033.3333.33
- ACC004706.255.21
- ACC005400.130.13
- ACC0076810.008.33
What this run caught
The migrated code ran without a single error. It would have underpaid every senior customer’s interest, every month.
Replay caught it on two accounts and blocked the merge before it shipped. Below is the full evidence: the verdict, every account, the cause, the decision, the fix and the proof it held.
One pack, three audiences.
Engineering
The exact account, field and lines of code behind every difference, so a fix takes minutes, not a war room.
Risk
No change merges with an unexplained difference on a critical field, and every override needs a reason on the record.
Audit and regulators
Who decided what and when, what the replay covered, and fingerprints that tie every result to exactly what was run.
- Program
- Month-end savings interest
- Unit
- 2000-CALC-INTEREST
- Migration
- COBOL → Python
- Recorded runs
- 10 accounts
A sample built from a public demo COBOL program and ten synthetic accounts, run through the real Montora engine. No customer data. The reviewer decision in Part 4 is illustrative.
Part 1
Verdict
Blocked: 2 of 10 accounts disagree.
The migrated code returned different interest and closing balances for two accounts. Both are critical fields, so the change cannot merge until the difference is resolved.
- Failed
Every critical field matches
2 accounts differ on interest paid and closing balance
- Passed
No critical path diverges
Control flow matched on every account
- Passed
Coverage above the 90% floor
100% of the program's behaviours exercised
- Passed
Critical fields confirmed by your team
Closing balance, interest paid, fee charged, account status
- Not yet
Usable as final sign-off evidence
Not yet: development run against an independent model of the program
Part 2
Account by account
Each recorded account was run through the original program and the migrated code, and every output field compared with exact decimals.
Part 3
Why they differ
Both accounts belong to customers aged 65 or over. The original program adds a senior bonus to the interest rate; the migrated code leaves it out. The difference was traced to one unit of the program:
IF LK-ACCT-AGE >= WS-SENIOR-AGE ADD WS-SENIOR-BONUS TO WS-APPLIED-RATE END-IF
Business rule affected: savings customers aged 65 or over earn a 0.25% bonus on top of their tier rate.
Part 4
Reviewer decision
“Senior bonus missing from 2000-CALC-INTEREST. Re-migrate the unit and replay before approval.”
Recorded with the reviewer, the time and the reason. (Example)
Part 5
After the fix
10 of 10 accounts match.
The re-migrated code was replayed against the same recorded accounts. Every critical field is identical, so the change can go to a reviewer for approval.
- Passed
Every critical field matches
10 of 10 accounts identical on every critical field
- Passed
No critical path diverges
Control flow matched on every account
- Passed
Coverage above the 90% floor
100% of the program's behaviours exercised
- Passed
Critical fields confirmed by your team
Closing balance, interest paid, fee charged, account status
- Not yet
Usable as final sign-off evidence
Next step: the same replay against runs recorded on your real system
The last check stays open on purpose. Montora will not present a development run as final sign-off evidence; that needs the same replay against runs recorded on your real system.
Part 6
Coverage
The ten recorded accounts exercised all ten of the program’s behaviours, so the result speaks for every path through it, not just the common ones.
- Tier 1 rate (balance under 1,000)
- Tier 2 rate (balance under 10,000)
- Tier 3 rate (balance 10,000 and over)
- Senior bonus applied (65+)
- No senior bonus
- Low-balance fee charged
- Fee capped at the balance
- No fee
- Active account
- Dormant account (no interest, no fee)
Part 7
Integrity
Both results are signed with Montora’s Ed25519 key, and every version of the code is fingerprinted. Anyone can check that this evidence is exactly what was run, and that it came from Montora, using only the public key: no login, no access to our systems, no trust required.
- Original COBOL program
- sha256:77c4e534229da9dd2a77ad327ae8441b
- Migrated code, first run
- sha256:9e1ee94066d2af0f73cc29bbce0d1e78
- Migrated code, after the fix
- sha256:f26a95d5dba149794d44177616bf825e
- Signature, first run
- ed25519:49eaf693dc8459d71e10be2f6039e564…
- Signature, after the fix
- ed25519:4159e64bec22a3c0ecffa7350c338e5c…
- Signing key
- ed25519-721ed1a9292adfc9
Verify it yourself
- 1. Download the signed results, the public key and the verifier:
- First run (signed result)montoralabs.com/evidence/replay-result-first-run.json
- After the fix (signed result)montoralabs.com/evidence/replay-result-after-fix.json
- Montora public signing keymontoralabs.com/.well-known/montora-replay-signing-key.json
- Verifier script (Python, 1 dependency)montoralabs.com/evidence/verify_replay_result.py
- 2. Run the verifier (Python with the cryptography package):
python verify_replay_result.py replay-result-first-run.json \
--public-key d4a5ed99ff2250f32fccc15839cd285ec5cbc6bbcec8bca387c427dd9a10cf37It prints VALID for each result. Change a single number in either file and it reports the result as tampered.
Want this for your own code?
A four-to-six-week pilot ends with an evidence pack like this for a real system of yours, and a forecast for the rest of your estate.