Formal Verification in Marketing Models: Why Lean 4 Solves the Compliance Question

Software development has agreed for decades on a cultural convention: code is secured through unit tests, integration tests, and end-to-end tests. These tests examine examples. If input X arrives, output Y must follow. Running a million such examples gives you high statistical confidence that the software works correctly. But statistics are not proof. A finite number of tests will always leave edge cases unexplored. Exactly this gap is closed by a different discipline, which over the last fifteen years has migrated from academic niche to industrial practice: formal verification.

Formal verification proves properties of a program for all possible inputs. Instead of asking 'does my code work for these thousand examples', it asks 'is this property mathematically guaranteed regardless of input'. The tools of this discipline are theorem provers like Coq, Isabelle, Agda — and since roughly 2021 Lean 4, a modern prover from Microsoft Research that unifies mathematical proofs and software verification in a single language. Lean 4 has established itself rapidly in academic mathematics — the Liquid Tensor Experiment formally verified a theorem by Peter Scholze — and from 2024 onward increasingly in industrial applications, from cryptographic libraries at Cloudflare to smart-contract verification in DeFi.

For regulated ML applications, this method is strategically interesting. Imagine a marketing-mix model recommends to a Swiss bank that the display budget be increased by 23 percent and the print budget reduced accordingly. The Bayesian pipeline behind this recommendation runs with MCMC samples, floating-point arithmetic, and channel-interaction effects. The compliance officer asks: 'Can you guarantee that the sum of recommended budgets exactly matches the sum of current budgets? Can you guarantee no negative recommendation arises? Can you guarantee that identical input plus identical seed produces bit-identical outputs?' These three properties — budget conservation, non-negativity, determinism — are exactly the kind of properties that a classical unit test can only probe through samples, but a Lean 4 theorem proves for all possible inputs.

A concrete theorem from the MMM-Wizard verification repository makes this tangible. The function `runMmm` accepts input data and a seed and produces a recommendation. The theorem `budget_conservation` states: for every ChannelAllocation `alloc` and every recommendation `rec` computed from it, `alloc.totalSpend = rec.totalRecommended` holds. The proof uses algebraic manipulations over the internal data structures, which Lean 4 checks mechanically. If a developer later changes the Meridian service code and accidentally introduces a floating-point accumulation that increases the budget total by 0.0001 francs, the `lake build` run in the CI pipeline fails. The proof breaks. The merge is blocked. This is a qualitatively different security level than a test that happens to miss this specific floating-point wave.

Why does this matter qualitatively for regulated industries? Three reasons. First, the compliance logic: nDSG Art. 22 and GDPR Art. 22 demand explainability of automated decisions. A machine-checked Lean 4 proof is the most robust form of explainability a software vendor can offer — more robust than 'we have a thousand tests', more robust than a code-review approval. Second, the audit argument: anyone who has to defend a marketing recommendation against an internal audit at a bank can attach the Lean 4 proof to the audit report and point to a mechanical check that runs independently of human reviewer judgment. Third, the investor argument: for VCs and strategic investors evaluating ML companies, machine-checked correctness is a differentiator against generalist platforms that rely on 'we have good tests'.

This method is not new — what is new is its transfer to marketing models. Cloudflare, AWS, and Google have used formal verification for years for cryptographic libraries and consensus protocols. Nexbid, a sibling platform within the opua brand family, has formally verified forty-seven Lean 4 theorems for its auction engine in the `protocol-commerce` repository. These theorems cover properties such as auction truthfulness, Pareto efficiency, revenue equivalence, and manipulation resistance. MMM-Wizard now adopts the same pattern for budget allocation: the verification sub-repository is being populated with six to eight core theorems that prove exactly the properties relevant for regulated-industry audits.

Strategically, this is the mathematical DNA that holds a brand family like opua together. Nexbid verifies auctions. MMM-Wizard verifies budget allocation. Mineralis, another opua tool for mining and energy equity research, can apply the same pattern to equity recommendation properties — for instance, 'the recommendation follows the fundamental valuation metrics monotonically'. What sounds like a technical specialty is a strategic architectural decision: every brand within the opua family uses the same verification pattern, which produces cross-brand consistency, shared tooling investment, and a defensible USP against generalist marketing platforms.

Academically the pattern is already validated. Holger von Ellerts, co-founder of the opua brand family and a lecturer on AI at Swiss universities, wrote a 2025 transfer thesis at the Lucerne University of Applied Sciences on KAN Shadow Scoring and Lean 4 Property Verification for the Nexbid Auction Engine. The thesis connects two strands: Kolmogorov-Arnold Networks as an interpretable ML architecture, and Lean 4 as a verification layer. The transferability from the academic application (auctions) to productive marketing applications (budget allocation, equity research) is not accidental — it is the strategic logic that holds opua together as a brand family.

For CTOs, compliance officers, and tech investors evaluating software vendors in regulated industries, three pragmatic questions are useful. First: which properties does your pipeline check mechanically? If the answer is 'unit tests', the security level is classical. If the answer is 'formally verified theorems in an established prover', the security level is qualitatively higher. Second: can you make the theorems in the repository publicly visible? Open-source Lean 4 files are a form of trust signal that a VC or compliance officer can verify directly. Third: how is the CI integration? A theorem prover that runs only once and not in the CI pipeline offers no continuous protection against refactoring waves.

Anyone who wants to see the pattern in practice can inspect the public repository at github.com/digital-opua/protocol-commerce. The forty-seven nexbid auction theorems are fully documented there. The mmm-wizard-verification sub-repository follows in Sprint 6. Both repositories are licensed Apache 2.0, because opua positions the verification layer as a shared Swiss open-source asset for the brand family. Tech investors, compliance officers, and university researchers who want to understand the methodology in depth can sign up for an audit-trail workshop at audit@digital-opua.ch.