# causality Published articles for causality. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How Nubank uses causality, machine learning and Python to support credit limit increase decisions DevFeed: [How Nubank uses causality, machine learning and Python to support credit limit increase decisions]() Original publisher: [Read original article]() Author: Nubank Editorial Published: 2026-07-01T16:16:31Z Content type: article Language: en Sources: [Nubank]() Topics: [Data Science](), [Machine Learning & Artificial Intelligence](), [Python](), [risk-management](), [Monitoring](), [Optimization]() Tags: [causality](), [data-science](), [life-at-nu](), [machine-learning](), [monitoring](), [optimization](), [python](), [risk](), [scalability]() ### AI overview A high-level technical overview of how Nubank applies data science, predictive modeling, causality, optimization, and monitoring to support credit limit increase decisions. It discusses balancing customer experience, risk management, operational sustainability, interpretability, computational cost, and scalability. ### Source excerpt A technical, high-level view of how data science helps build more responsible and scalable credit decisions The post How Nubank uses causality, machine learning and Python to support credit limit increase decisions appeared first on Building Nubank. ## The Causality Gap: Measuring the True Impact of Voluntary Adoption in Digital Marketplaces DevFeed: [The Causality Gap: Measuring the True Impact of Voluntary Adoption in Digital Marketplaces]() Original publisher: [Read original article]() Author: Lin Jia Published: 2026-05-22T08:05:43Z Content type: article Language: en Sources: [Booking.com Data Science]() Topics: [A/B Testing](), [doubleml](), [Data Science](), [Tool]() Tags: [a-b-testing](), [causal-inference](), [causal-machine-learning](), [causality](), [data-science](), [doubleml](), [e-commerce](), [experimentation](), [featured](), [measuring]() ### AI overview This article explains why standard A/B tests can mismeasure features that require voluntary adoption in digital marketplaces. It presents Randomized Encouragement Design combined with Double Machine Learning as a way to estimate both causal impact among adopters and overall rollout impact. ### Source excerpt by Lin Jia, Kexin Fei The Content of this post has been presented at Pydata Amsterdam 2026 and the slides can be found here TL; DR Whenever a feature requires voluntary adoption, standard A/B testing breaks: low adoption flattens the topline, and self-selection makes adopters incomparable to non-adopters. Combining Randomized Encouragement Design (RED) with Double Machine Learning (DoubleML) recovers two answers -- the causal lift for adopters and the rollout's overall impact. When they diverge, the gap turns an ambiguous topline into a sharp product decision -- build a better product, or build a better adoption funnel. 1. The Opt-In Barrier Across Demand and Supply Across the tech industry, many platform features rely on voluntary adoption. A customer chooses whether to claim a promotional discount. A traveller opts into a loyalty program. An e-commerce seller enables a smart-pricing tool. In every case, the platform cannot force adoption -- and the feature's true impact becomes hard to measure, on both demand and supply. At Booking.com this challenge spans both sides of the marketplace -- travellers choosing to log in, partners choosing to adopt new features. Unlike a search-ranking change that applies to 100% of traffic, opt-in features create a "trilemma" for Product Data Science: Voluntary Adoption (the "Opt-In" Barrier): Users must actively enable the feature. A standard A/B test cannot separate the product's effect from the motivation that drove users to adopt it. Extreme Heterogeneity: Travellers range from once-a-year holidaymakers to travel agencies booking thousands of nights; partners range from single-apartment hosts to hotel chains. This variance is noise on both sides. Finite Sample Sizes: Opt-in features target a finite sub-segment, so we cannot simply "run the test longer" to gain power. When these stack up, a flat topline can hide a strong product behind a weak adoption funnel. Genuinely strong features get killed, and resources flow into the wrong int ## CAUSAL CONCEPT-BASED EXPLANATIONS DevFeed: [CAUSAL CONCEPT-BASED EXPLANATIONS]() Original publisher: [Read original article]() Author: Jacopo Bono Published: 2025-10-03T13:09:07Z Content type: article Language: en Sources: [Feedzai]() Topics: [Machine Learning & Artificial Intelligence](), [Machine learning](), [AI Development]() Tags: [ai](), [blog-post](), [causality](), [concept-learning](), [deep-learning](), [explainability](), [machine-learning](), [research](), [technical]() ### AI overview The article introduces causal concept-based explanations for machine learning models. It argues that existing feature-attribution explanations can be too complex for humans and usually do not support reasoning about hypothetical alternatives. The proposed method aims to provide more human-understandable, reasoning-oriented explanations, with technical details deferred to a publication at the 2024 CLeaR conference. ### Source excerpt Introduction Over the years, we have evolved from using simple, often rule-based algorithms to sophisticated machine learning models. These models are incredibly good at finding patterns in large datasets, but due to their complexity it is frequently challenging for a human to understand why a certain input leads to its respective output. This is especially problematic in areas where high-stakes decisions are being made and where human-AI collaboration is critical. This is why model explainability has gained traction in recent years. The aim of explainability methods is to shed light on what properties of the data contribute to a machine learning model's output. Ideally, such explanations should be similar to how a human would explain its decisions to a peer. In particular, humans make use of high-level concepts that are easy to grasp for other people. For example, a human would explain, "there was a sudden burst of transactions in a short time" as opposed to, "the average delta time feature is much smaller in a recent short time-window compared to a long time-window, and the count of transactions feature increased substantially in the same recent time-window." Moreover, when explaining choices and decisions, humans are free to reflect on these decisions by reasoning about hypothetical alternatives. For example, we could ask, "if this email address would be considered suspicious, would I trust this request?" Current explainability methods fail to incorporate both properties: the explanations are often much more complex than typical concepts humans would use; and they don't allow for reasoning. As a result, these limitations impede the usefulness of current explainability methods in many practical applications. In this blog post, we will describe a new explainability method that addresses these issues. We'll try to refrain from discussing too many technical details and focus on the intuition behind the method, but readers interested in the technical justifications ar ## How Accurate Clocks Improve Observability in Distributed Systems DevFeed: [How Accurate Clocks Improve Observability in Distributed Systems]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2023-11-27T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [distributed-systems](), [Amazon EC2](), [observability](), [Amazon Web Services]() Tags: [aws](), [causality](), [distributed-systems](), [ec2](), [observability]() ### AI overview This article examines how increasingly accurate time synchronization, including microsecond-accurate clocks in Amazon EC2, can affect distributed-system design. It focuses on observability and explains that accurate timestamps make establishing causality and ordering events easier. ### Source excerpt It's About Time! What's the time? Time to get a watch. My friend Al Vermeulen used to say time is for the amusement of humans1. Al's sentiment is still the common one among distributed systems builders: real wall-clock physical time is great for human-consumption (like log timestamps and UI presentation), but shouldn't be relied on by computer for things like actually affect the operation of the system. This remains a solid starting point, the right default position, but the picture has always been more subtle. Recently, the availability of ever-better time synchronization has made it even more subtle. This post will attempt to unravel some of that subtlety. Today is a good day to talk about time, because last week AWS announced (more details here) microsecond-accurate time synchronization in EC2, improving on what was already very good. All this means is that if you have an EC2 instance2 you can expect its clock to by accurate to within microseconds of the physical time. It turns out that having microsecond-level time accuracy makes some distributed systems stuff much easier than it was in the past. In hopes of understanding the controversy over using real time in systems, let's descend level-by-level into how we might entangle physical time more deeply in our system designs. Level 0: Observability, and the Amusement of Humans ... reality, the name we give to the common experience3 When we try understand how a system works, or why it's not working, the first task is to establish causality. Thing A caused thing B. Here in our weird little universe, we need thing A to have happened before thing B for A to have caused B. Time is useful for this. Prosecutor: Why, Mr Load Balancer, did you stop sending traffic to Mrs Server? Mr LB: Simply, sir, because she stopped processing my traffic! Mrs Server, from the gallery: Liar! Liar! I only stopped processing because you stopped sending! If we can't trust the order of our logs (or other events), finding causality is difficult.