OrbaLang — Write Rules Once, Emit Them Everywhere

OrbaLang — Write Rules Once, Emit Them Everywhere

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

OrbaOS Deep Dive: Proving FRTB & GloBE for the Post-Project World

In this extended 50-minute technical session, we explore why institutional regtech must move toward falsifiable lineage. For bank CROs and Group Tax Directors, the challenge is no longer just the calculation—it is the provenance. We break down the OrbaOS doctrine ("Admitted Before Calculated") and its application across two of the most complex regulatory regimes today: the Fundamental Review of the Trading Book (FRTB) and OECD Pillar Two (GloBE). Key Technical Topics: * The Merkle DAG Architecture: Why every capital or tax figure must be a node in a hash tree to prevent "silent drift". * FRTB Standardised & Internal Models: Handling sensitivities, default risk, and liquidity horizons with regulator-template exports. * GloBE Article 5 Walks: Navigating the jurisdictional top-up process from book profit to GIR XML export. * QDMTT / IIR / UTPR Routing: How the engine uses OECD-published facts to determine exactly which jurisdiction collects top-up tax. * Self-Hosted Governance: Deploying Postgres + FastAPI + React within your own network to ensure data residency and security. * For FRTB: frtb.orbaos.com [https://www.google.com/url?sa=E&q=https%3A%2F%2Ffrtb.orbaos.com] * For GloBE: globe.orbaos.com [https://www.google.com/url?sa=E&q=https%3A%2F%2Fglobe.orbaos.com] "Your regulator can replay our exports offline with a single Python file. No backend access required." Keywords: FRTB, OECD Pillar Two, GloBE Model Rules, RegTech, Market Risk, Basel 3.1, Merkle DAG, QDMTT, IIR, UTPR, GIR XML, Bank Capital, Tax Governance, PRA SS21/15, EBA COREP, APRA APS 116. Call to Action: Institutional risk and tax leaders can request access to a private demo tenant to walk the doctrine end-to-end on synthetic data. Podcast Episode Chapter Timestamps * 00:00 – 05:00 | Opening: Institutional Infrastructure in the Post-Project World: Framing the shift from temporary consulting "projects" to permanent, living infrastructure. Why OrbaOS is built for a world where "one-and-done" compliance is no longer enough. * 05:00 – 12:00 | The Reconciliation Crisis: Why FRTB and Pillar Two Programs Fail: A deep dive into the operational failure modes where Risk, Finance, and Audit cannot agree on input rows. Discussing why "most FRTB programmes don’t fail on the math — they fail on reconciliation". * 12:00 – 22:00 | The Doctrine: Admissibility Before Calculation: Technical breakdown of the Merkle DAG and the hash-echo commit flow. Explaining why "admitted before calculated" is the core governing principle of the engine. * 22:00 – 32:00 | FRTB Specialist Segment: SA, IMA, and Regulator-Ready Exports: Walkthrough of the SBM, DRC, and RRAO modules, alongside the Internal Models (IMA) pipeline including Expected Shortfall and RFET. How exports map to PRA, EBA, and APRA templates. * 32:00 – 42:00 | Pillar Two Specialism: Article Walks and Top-Up Routing: Detailed navigation of the Article 3.2 and 4.1 walks, Article 9 safe harbors, and the deterministic routing of QDMTT, IIR, and UTPR based on OECD Central Record facts. * 42:00 – 47:00 | Operational Governance: The Warn-Gate-Block Path: How to deploy the system without breaking legacy paths. Moving from observational logging to strict four-eyes control and eventually "fail-closed" production. * 47:00 – 50:00 | The Verification Replay & Demo Tenant Experience: How to use the standalone verify_lineage.py for offline audit replay and an invitation to the 45-minute private demo tenant for experiential proof.

Does ChatGPT Know Your Company Exists? Introducing Arbor | Bonus Episode.

Search engines rank pages. AI assistants assemble answers. In this bonus episode of The Post Project World, Luigi Pascal Rondanini, using some AI actors, introduces Arbor, a platform designed to measure how companies appear within the answer layer of generative AI. As buyers increasingly ask ChatGPT, Claude, Gemini and other AI systems for recommendations, explanations and comparisons, traditional search rankings no longer tell the whole story. An organisation may perform well on Google while remaining absent, misrepresented or incorrectly described in AI-generated answers. This episode explores how Arbor helps organisations examine: • visibility across major AI models • citation frequency and source attribution • factual accuracy and hallucination risks • competitive positioning within generated answers • gaps in authority, evidence and discoverability • changes in AI visibility over time Rather than relying on opaque visibility scores or marketing claims, Arbor uses an auditable, evidence-led methodology. Each result can be traced back to the prompt, model, response, citation and date on which it was observed. The discussion also considers why answer-engine visibility matters to communications teams, SEO specialists, PR professionals, digital strategists and enterprise leaders—and how organisations can move from being merely present online to becoming trusted sources that AI systems recognise and cite. Arbor is available through cloud-based and self-hosted deployment options for organisations requiring greater control over their data and monitoring processes. Learn more at arbor.berta.one. A bonus episode of The Post Project World, produced by Luigi Pascal Rondanini for Rondanini Publishing Ltd.

The Governance Engine — Confidence-Driven Progression, Decisions as Assets, and the Architecture of Governance

What replaces the cycle of friction, debt, and declining throughput described in Episode 1? Not more governance. Better governance. In this episode, Luigi Pascal Rondanini introduces the Governance Engine — a continuous governance system with 6 states: Observe, Interpret, Decide, Execute, Validate, Learn. Unlike the traditional model of periodic meetings and scheduled reviews, the Engine operates continuously. Different workstreams are in different states at the same time. Governance doesn't wait for meetings. Meetings become decision points within the continuous system, not the system itself. Three properties distinguish this model. Governance is recursive — governance itself is governed, and evolves alongside programme maturity. Every decision is evaluated across 3 time horizons — immediate, programme, and enterprise — preventing governance from becoming purely reactive. And governance energy is finite — a programme can exhaust its governance capacity before it exhausts its delivery energy. The episode then goes deep on 2 components of the Engine: Stage Gates as Confidence Decisions. Programmes should progress because confidence has increased, not because time has passed. Time is a planning mechanism. Evidence is a governance mechanism. Every stage gate concludes with one of 4 decisions: Proceed, Proceed with Conditions, Hold, or Reject. Delaying progression frequently represents effective governance. Proceeding without confidence rarely does. Decisions as Enterprise Assets. Requirements are version controlled. Source code is version controlled. Documents are version controlled. Decisions often are not. The framework treats every significant decision as a governed asset with a full lifecycle: Identification, Analysis, Recommendation, Approval, Communication, Implementation, Verification, Closure. The Programme Decision Register becomes the authoritative repository — every decision uniquely identifiable, traceable, and searchable. The episode closes with the 3-layer architecture that makes governance durable: Doctrine (timeless principles — the Coordination Capital Doctrine), Framework (evolving best practices — stage gates, the Governance Engine, decision registers), and Implementation (constantly changing tools — OrbaOS Instruments, dashboards, AI-assisted narrative drafting). When you separate these layers, governance survives platform changes, leadership transitions, and programme boundaries. Every governance component must pass 4 tests: the Practical Test (did it solve a real problem?), the Simplicity Test (can it be explained in 2 minutes to a steering committee?), the Implementation Test (can it be operationalised in software?), and the Adoption Test (would another organisation use it without the reference programme?). A governance framework succeeds when it becomes easier to use than to ignore. Hosted by Luigi Pascal Rondanini, author of The Coordination Capital Doctrine and founder of OrbaOS. Visit instruments.orbaos.com to run a CCR diagnostic. Keywords: governance engine, stage gates, evidence-based governance, confidence-driven progression, decision management, programme decision register, governance architecture, 3-layer architecture, coordination capital, governance operating system, enterprise transformation, programme governance, continuous governance, decision lifecycle, RACI, evidence pack, acceptance criteria, governance body, steering committee, PMO, vendor oversight, technical design authority, organisational throughput, governance friction, coordination debt, governance methodology, OrbaOS Instruments, CCR, structural floor, coordination drift, regulated financial institution, CFO governance, audit committee, governance standard, enterprise governance, transformation governance, AI governance Topics/Categories: Business, Technology, Management

The Governance Friction — Why Programmes Fail When Everyone Is Working Harder Than Ever

Why do enterprise transformation programmes slow down even when activity increases? In this episode, Luigi Pascal Rondanini tells the origin story of the Coordination Capital Framework — born not from a textbook but from a real treasury transformation programme at a medium-size regulated financial institution. When he reviewed the vendor's proposal, the functional scope scored 9.3 out of 10. The governance scored 5.5. That gap — between technology readiness and governance readiness — is where most enterprise programmes fail. From the 20 governance gaps discovered in that programme, 3 new concepts emerged that explain why transformation programmes degrade over time: Governance Friction — the expenditure of organisational effort that does not increase delivery capability. The meetings that produce no decisions. The reports that duplicate information already available. The approvals that consume weeks for changes that take hours. Friction is not waste. It's subtler. The activity might be legitimate. But the effort exceeds the governance value produced. Coordination Debt — the accumulated consequence of governance shortcuts. Deferred decisions. Incomplete evidence. Unvalidated assumptions. Skipped reviews. Informal approvals with no documented rationale. Each shortcut is small. The programme continues. But debt compounds. When the foundation is finally questioned, rework cascades through every layer built on top of it. The Throughput Trap — the cycle that locks programmes into decline. As Coordination Debt accumulates, Organisational Throughput — the finite capacity to process governance — declines. The response is to add more governance. More governance increases friction. Friction further reduces throughput. Activity rises. Progress falls. Everyone is busy. Nobody is moving forward. This episode also introduces the foundational insight behind the entire framework: enterprise transformation is fundamentally a coordination problem, not a technology problem. Two programmes with identical budgets, identical schedules, and identical technology can produce dramatically different outcomes. The difference lies in coordination capability. Projects don't fail because people stop working. They fail because people stop coordinating. The Coordination Capital Doctrine (published July 7, 2026) measures coordination as institutional capital. This episode describes the complementary governance layer: the methodology for running the transformation itself. The Doctrine measures. The Framework governs. Hosted by Luigi Pascal Rondanini, author of The Coordination Capital Doctrine and founder of OrbaOS. Keywords: governance friction, coordination debt, organisational throughput, enterprise transformation, programme governance, treasury transformation, coordination capital, governance operating system, vendor governance, stage gates, programme management, PMO, delivery risk, governance methodology, acceptance criteria, requirements traceability, performance obligations, governance gaps, coordination capability, programme failure, transformation governance, regulated financial institution, CFO governance, audit committee, risk management, OrbaOS, coordination capital framework, governance architecture, decision-making, evidence-based governance Topics/Categories: Business, Technology, Management