Every regulated institution has rules. Most cannot prove that their systems enforce those rules consistently. A payment threshold approved by a committee in 2019 is implemented in Python by one team, Java by another, and a COBOL batch job on the mainframe that nobody wants to touch. Each drifted from the original intent. When audit asks which line of code enforced that limit on the 15th of March, the room goes quiet. That gap — between what the institution says its rules are and what its systems actually enforce — is a governance failure. OrbaLang addresses it. OrbaLang is a transpilation-first business-logic language. You write business rules once in a small, readable syntax. You validate them. Then you emit them — to Python, TypeScript, Java, Go, SQL, COBOL, and other targets. Not a proprietary runtime. Not a central rules server. Source code your teams deploy wherever they already operate. The same rule. The same logic. The same audit trail. Across every target. Each OrbaLang file is one of two things: a function (typed inputs, deterministic steps, typed return — what is the value?) or a rule (typed inputs, Boolean condition, required governance action, audit metadata — what must we do, and under what control?). That distinction separates a business-logic language from a governance-logic language. In this episode, Luigi Pascal Rondanini introduces OrbaLang through a treasury desk use case: daily limits, high-risk escalation paths, invoice approval thresholds, blocked jurisdictions. Each encoded as a rule or function. Emitted to Python for the microservices team, TypeScript for the web tier, COBOL for the settlement engine. The same when clause. The same then action. The same audit block. Not three interpretations that drift over quarters. The episode covers why OrbaLang differs structurally from Drools, OPA, DMN, and Python-alone approaches. Drools gives you a runtime and a vendor dependency. OPA gives you policy as data. OrbaLang gives you policy as auditable language with multi-target code generation, including legacy validators that some programmes still require. Python alone is infinitely flexible, which is the problem. Flexibility without governance vocabulary becomes ten styles in ten repositories. OrbaLang connects directly to the Coordination Capital Doctrine (Chapter 15) and the OrbaOS governance formalisation architecture. The Coordination Capital Ratio tells you how much coordination exists and what it costs. The Structural Floor tells you how much is mandatory. OrbaLang tells you what the rules actually say — in every system, in one language, with one audit trail. Measurement without enforceable logic is observation. Logic without measurement is assertion. Together, they create a governance system that can explain itself. OrbaLang is MIT licensed and lives in the open. Playground available at lang.orbaos.com. Part of the OrbaOS ecosystem alongside OrbaOS Instruments, ScenarioForge, and the Coordination Capital Doctrine. Hosted by Luigi Pascal Rondanini, author of The Coordination Capital Doctrine and founder of OrbaOS. Keywords: OrbaLang, transpilation, business logic, governance logic, rules engine, policy as code, write once emit everywhere, treasury transformation, payment threshold, sanctions, compliance, audit trail, audit metadata, governance chain, regulated financial institution, COBOL, legacy systems, mainframe, Python, TypeScript, Java, Semantic IR, code generation, transpiler, decision tables, governance vocabulary, OrbaOS, coordination capital, coordination capital ratio, structural floor, governance formalisation, CFO governance, audit committee, risk management, Drools, OPA, DMN, policy language, version control, traceability, enterprise governance, institutional governance, Rondanini Publishing, Post-Project World Topics/Categories: Business, Technology, Management
