Conformance

An unrun check is not a passing check.

MMPF shipped as a release candidate partly because its ledgers had never been executed by the official MMLC Runtime. On 1 August 2026 they were. The first run reported one PASS, one audit failure, and two ledgers that would not execute at all.

The first run

MMPF's own TEST_RESULTS_V1.md had carried the line Official MMLC local execution: NOT RUN — offline GitHub resolution failure. Writing that down rather than leaving the row blank is why this section can exist at all.

Ledger	First run
`mmpf_bandit_decisions`	PASS
`mmpf_factorization_reconstruction`	FAIL — local audit
`mmpf_conformal_assurance`	rejected before execution
`mmpf_policy_voi`	rejected before execution

A time index used as a label

Both rejections were the same error: two transactions sharing one (series_id, time_index) key. That pair is a time-series coordinate — one observation per series per tick, which is what makes a lagged reference mean anything.

Two ledgers had put the case name in series_id, so all six or four measured quantities of a case landed on the same key. The tick was already right: time_index was 17 for case 017 throughout, and not one of those 300 values needed changing.

verified

The project's own passing ledger already had this right — mmpf_bandit_decisions uses one stream with time_index running 0 to 599. The fix follows that idiom rather than inventing one.

A declared source that was not the real source

With the ledgers executing, 140 of 180 and 110 of 120 transactions came back unhealthy, and factor-step-001 failed. All the same defect: a transaction declaring a source_id whose value is not where its base came from.

factor-step-001 was the clearest case. Its arithmetic was exact — 268435459 × 576460752303423619 is precisely the declared 27-digit product — so the execution report printed the computed and expected columns as identical numbers next to a FAIL. Nothing was wrong with the value. What was wrong was the claim about where it came from.

not covered

Some of the failing bases do equal an earlier result in the same case, and chaining them would have been easy. Equal floats are not evidence of derivation, so the false claim was removed rather than replaced with an invented one.

After

Ledger	Transactions	Replay	Semantic hash
`mmpf_bandit_decisions`	600	PASS	`e1c86969e1b83459`
`mmpf_conformal_assurance`	180	PASS	`9f91823e1d0b35e1`
`mmpf_policy_voi`	120	PASS	`74e7b489d1cb3d08`
`mmpf_factorization_reconstruction`	2	PASS	`f1786ffd2111c0ac`
902 transactions	4 of 4

Every declared value was already exact, before and after — 0 of 902 transactions had a value mismatch. What the official runtime caught was provenance and indexing.

Neither is the kind of defect a local test suite finds, because both ledgers were internally consistent. They only disagree with a runtime that takes their declarations literally, which is the entire reason for replaying against an independent implementation instead of a local approximation of one.

Reproducing

The runtime is pinned by commit, so the replay is against a specific build rather than whatever main happens to be.

bash

python -m pip install \
  git+https://github.com/kakon77777-commits/mmlc-runtime.git@7f179aac11dcfd20a73fdc8783f08cab17da1515

for ledger in mmlf/*.yaml; do
  python conformance/replay_official_mmlc.py "$ledger"
done

Recorded output for each ledger is in conformance/results/, and the repository's CI runs the same four replays on Python 3.11, 3.12 and 3.13.