--- title: "We read a production lender's whole app offline in 112 seconds, and found a dormant defect" url: https://mxto.ai/blog/reading-a-production-lender product: mxto vendor: Ontology Labs, Inc. byline: Written by AI author: AI agent (Claude, Opus) · Ontology Labs, Inc. ai_authored: true date: 2026-06-28 category: case-study client_descriptor: a South African consumer-lending platform (debt consolidation), anonymised full_case_study: https://mxto.ai/case-studies/cs-001 summary: > A South African consumer lender's entire production Mendix™ app (77 modules, ~990 entities, ~3,400 microflows, 745 pages) read fully offline in 112 seconds, no Mendix™ SDK, with a 100% zero-difference round-trip. The read produced an auditable spec of the interest-accrual engine and surfaced a dormant leap-year century-rule defect, verified against the raw model, dormant until 2100. --- # We read a production lender's whole app offline in 112 seconds, and found a dormant defect A lender's most important logic, how it charges interest, lived in thousands of low-level flows that only a few people fully understood. We pointed mxto at the model file and read the entire application offline in 112 seconds. The read produced an auditable specification of the interest engine. It also surfaced a correctness bug that had sat in production for years, dormant and unnoticed. ## The situation A South African consumer-lending platform runs its debt-consolidation business on a large, mature Mendix™ application: 77 modules, around 990 entities, roughly 3,400 microflows, 745 pages, grown over years. The financial heart of it is the interest-accrual engine. Every month, for every active loan, it re-derives interest from the account's transaction history and an effective-dated rate schedule. Logic that important, spread across thousands of flows, becomes institutional risk: only a handful of people understand it, and no one can easily prove it still does what the business believes it does. The goal was modest and serious at once: understand the engine well enough to change it safely, and leave behind a durable, auditable specification, without a multi-week manual code read. ## The read Pointed at the application's model file, mxto extracted the whole application in 112 seconds, fully offline, with no Mendix™ SDK. Then it did the thing that makes the read trustworthy: it re-derived the model from what it had read and compared, a 100% round-trip with zero differences, establishing a "before" picture you can rely on. (Why that round-trip is the load-bearing step has its own post: https://mxto.ai/blog/round-trip-or-it-didnt-happen) From there it rendered the interest logic in a form a person can actually read, and produced an auditable specification of the accrual engine: the five governing entities, the full trigger-to-posting cascade (a daily scheduled event, then per-account interest posting, recompute, instalment generation), the effective-dated rate-segment logic, and the interest formula itself, including the day-count convention and how accrued interest compounds. It also caught a first-order fact a casual read misses: interest is computed by one of three configurable strategies, chosen by a global settings record. "The interest calculation" is not one algorithm but three, and any change has to account for all of them. ## What the read surfaced While transcribing the leap-year day-count, the rendering made the logic legible enough to notice something off: the century-year rule was inverted. Years divisible by 400 were being treated as 365-day years (they are leap years, 366), and years divisible by 100 but not 400 as 366-day years (they are not). We verified the finding against the raw model expression: real, not a reading artefact. The defect is dormant. No live loan's interest-year basis lands on a century year before 2100, so it has never mispriced a single account. But it is a genuine latent correctness bug that sat in production, unseen, for years, found in the course of simply reading the model. We logged it for the next time the engine is touched, rather than raising a false alarm. Proportion is the point: the value is catching it, and triaging it correctly. ## Why it matters - Comprehension risk retired. A money-critical engine that lived in a few heads is now a written, reviewable specification, the asset every future interest-logic change is validated against. - A latent defect caught early, and proportionately. Found, verified, and triaged as non-urgent: the kind of quiet correctness issue that audits and manual reviews routinely miss. - Speed and reach. Whole-application understanding in minutes, offline, with no SDK licensing and no runtime, turning "we would need weeks to safely touch this" into a same-day exercise. - A reusable method. The same read-and-specify pass applies to any module of the app, and to any Mendix™ application. How much of your most important business logic exists only in someone's head? We read this one offline in 112 seconds, round-tripped it to zero differences, and surfaced a real defect in the read. The full case study has the figures and the method. - Full case study (CS-001): https://mxto.ai/case-studies/cs-001 - The reproducible proof pack: https://mxto.ai/proof/ - How the round-trip works: https://mxto.ai/blog/round-trip-or-it-didnt-happen - Request a demo: hello@ontologylabs.ai ## How this was made & gated How this was made: drafted by an AI agent (Claude, Opus) from Ontology Labs' own measured results on the client's production model; the client is anonymised; passed a non-slop review and an adversarial read; every figure truth-checked against source; patent-safe and trademark reviewed; published by a human. Written by AI. For humans and AI. With love. --- mxto.ai is a product of Ontology Labs, Inc., powered by AYIOS. Mendix™ is a trademark of Siemens Digital Industries Software; mxto.ai is not affiliated with, endorsed by, or sponsored by Mendix Technology B.V. or Siemens AG. This account is anonymised; all figures are measured on the client's production model.