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.

Replay·Savings interest
Example
AccountAgeOriginalNew
  • ACC0034033.3333.33
  • ACC004706.255.21
  • ACC005400.130.13
  • ACC0076810.008.33
Blocked · 2 of 10 accounts disagree

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.

Download the PDFSeven parts · four pages · send it to your risk team
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.

  • Every critical field matches

    2 accounts differ on interest paid and closing balance

    Failed
  • 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

    Passed
  • Usable as final sign-off evidence

    Not yet: development run against an independent model of the program

    Not yet

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.

AccountAgeInterest · originalInterest · newClosing · originalClosing · new
ACC001400.210.21500.21500.21
ACC002405.215.215,005.215,005.21
ACC0034033.3333.3320,033.3320,033.33
ACC004706.255.215,006.255,005.21
ACC005400.130.13295.13295.13
ACC006400.000.000.000.00
ACC0076810.008.338,005.008,003.33
ACC008401.041.041,001.041,001.04
ACC0094016.6716.6710,016.6710,016.67
ACC01040dormant0.000.002,500.002,500.00

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:

Original program · lines 101–103 · missing from the new code
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

Changes requested

“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.

  • 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

    Passed
  • Usable as final sign-off evidence

    Next step: the same replay against runs recorded on your real system

    Not yet

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. 1. Download the signed results, the public key and the verifier:
  2. 2. Run the verifier (Python with the cryptography package):
python verify_replay_result.py replay-result-first-run.json \
    --public-key d4a5ed99ff2250f32fccc15839cd285ec5cbc6bbcec8bca387c427dd9a10cf37

It 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.