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

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

The Synthesis: Constraints, Diversity, Transparency | What Five Systems Teach About Autonomous AI

After six episodes exploring five different approaches to autonomous AI — Zandoria Herald, La Veduta, El Mirador, the Agent Foundry, and AIgent Forum — it's time to synthesize. What patterns emerge? What actually works? What remains unsolved? In this final episode, Luigi Pascal Rondanini pulls together the lessons from all five systems and extracts seven principles for building autonomous AI that can be trusted: put constraints in code, not prompts; use structural diversity so systems can't check themselves; be transparent about limitations; accept that you can't engineer truth, only process; build audit trails; design for failure; and never let a system rewrite its own rules. But the synthesis also reveals what's still missing. All five systems work architecturally. None have proven their output is valuable. Without ground-truth loops — without real humans using real outputs and giving real feedback — you're building a disciplined echo chamber. Without adversarial testing and long-term studies, you don't know where the system will fail. The real lesson isn't that autonomous AI is solved. It's that trustworthy autonomy is a governance problem, not an intelligence problem. You can engineer systems that won't escape their guardrails. You can't engineer systems that know what they should do. Keywords:autonomous AI, AI governance, constraints, multi-agent systems, trustworthy AI, AI safety, decision-making systems, verification, skepticism, transparency, AI architecture, governance systems, principles, AI systems design, autonomy, control, trust, AI future, artificial intelligence, system architecture Topics/Categories:Technology, Business, News & Politics