Varad

I support View B — Do not rely on non-explainable AI. In the Indian insurance context, if you cannot explain a claim decision, you are not just inefficient — you are non-compliant, untrustworthy, and operationally incomplete. Where Bex’s argument breaks in IndiaBex assumes this is a simple trade-off: speed vs explainability. That logic might work in e-commerce. It does not work in insurance, especially in India. Because here, the real objective is: Speed is important, yes. But in India, the reason behind a claim decision is part of the product itself. If a family asks, “Why was my ₹10 lakh hospitalization claim rejected?” and the answer is “The AI decided” — that is not a bad experience. That is a system failure. Ground reality: AI adoption is rising — but with cautionIndian insurers are already using AI in: Claims triaging Fraud detection Document processing Risk assessment AI is clearly improving efficiency and reducing turnaround times But here’s the critical part: Industry leaders are explicitly warning against “cold automation” without governance Explainability is becoming a regulatory expectation, not a nice-to-have Systems must provide audit trails for IRDAI scrutiny 👉 In other words: AI is being adopted — but not blindly. ⚖️ The Claims Settlement Ratio (CSR) realityIndian insurance is hyper-competitive. Every major insurer markets: 95%–99% Claim Settlement Ratios (CSR) This is not just a metric — it is the core trust signal for customers. Now imagine introducing a black-box AI: Even a 2–3% drop in CSR due to unexplained rejections Leads to: Loss of market credibility Regulatory scrutiny Customer distrust And unlike speed gains, trust loss compounds. Once a customer loses faith in claims fairness, they don’t come back. 📉 The hidden operational impact (simple math)Let’s say: 1 lakh claims/month CSR = 96% → 4,000 rejections Now introduce black-box AI: CSR drops to 92% (just 4% change) Rejections = 8,000 That’s 2x increase in rejected claims Each rejection leads to: Customer grievance Escalation to ombudsman Manual review (human override) Potential legal exposure 👉 You didn’t reduce cost. You created a parallel system to explain decisions the AI cannot explain. 💥 Real human impact (this is not abstract)In India, insurance claims are not convenience decisions. They are: ICU bills Cancer treatments Emergency surgeries An incorrect or unexplained rejection doesn’t just create friction — it can financially break a family when they are most vulnerable. And importantly: Customers are legally entitled to clear written reasons for claim rejection (and can escalate to IRDAI/ombudsman if not satisfied) So a black-box system is not just inconvenient — it is legally indefensible. 🏛️ Regulatory reality: IRDAI will not allow thisIndia is not a “move fast and break things” market. Insurance Regulatory and Development Authority of India requires: Auditability Fairness Non-discrimination Explainability in AI systems Black-box AI creates: Compliance gaps Audit failures Regulatory risk In fact, even today: So the idea that such a system can be deployed at scale is not realistic. 🧠 The deeper insight (this is the real issue)This is not a technology problem. It is a decision design problem. The AI is optimizing: But the system actually requires: So the AI is not “imperfect” — it is solving the wrong objective function. 🔚 Final verdictIn Indian insurance: The decision is the product The explanation is part of the product The regulator enforces both So deploying non-explainable AI is not innovation — it is outsourcing critical judgment to a system you cannot defend. Faster claim decisions mean nothing if you cannot justify them when it matters most.

My position is View B: Do not implement the change.. Speed gains that come with higher error rates destroy value at the system level. You fix accuracy first, then scale speed—not the other way around. A strong real-world parallel is Zappos, especially in how they built their fulfillment and customer service operations. Zappos made a very explicit choice early on: accuracy and customer trust over raw speed. What this looked like operationally:Warehouse pickers were trained to double-check SKUs and quantities before packing Packers verified items again before sealing boxes Customer service agents had visibility into order accuracy metrics, not just delivery times At one point, there was internal pressure to push faster shipping SLAs. That meant: Reducing verification steps Increasing pick rates per worker What happened when speed was pushed too aggressivelyAction:Picking targets were increased Verification steps were relaxed Immediate effect:Orders went out faster But then:Incorrect shipments increased Customers received wrong sizes, wrong items Cause → Effect chain:Faster picking → Less verification → More errors → More returns and complaints → Increased reverse logistics cost → Customer trust dropped And here’s the critical part: Customer service teams got flooded. More calls More refunds More manual intervention So even though the warehouse was “faster,” the end-to-end system slowed down and became more expensive. Zappos reversed course. They reintroduced stricter accuracy controls—and accepted slightly slower fulfillment. This is exactly what I’ve seen in my own experience as well. Real life example in current organizationWe implemented a GenAI-based OCR solution for invoice processing in Oracle to automate data capture. What we expected:Faster invoice processing Reduced manual effort What actually happened:Only about 20% of invoices were captured accurately end-to-end The rest had missing or incorrect fields Operational impact:Invoices were getting ingested quickly But the data wasn’t reliable This created risk in downstream processes like payments and reconciliation Cause → Effect:Automation introduced → Faster ingestion → Low accuracy → Data inconsistencies → Risk of financial errors At that point, we had a choice: Let it run and fix issues later, or control it upfront. We chose to add a verification layer before submission into Oracle. What that looked like:AP/finance teams reviewed extracted data Corrected errors before posting Ensured system integrity Yes, this reduced the “pure automation” benefit—but it stabilized the process. If I map this back to the warehouse scenario, the pattern is identical: OCR Case Warehouse Case Faster invoice capture Faster order fulfillment Incorrect data extraction Incorrect shipments Financial risk Customer trust + return cost Added validation step Need accuracy guardrails The argument for implementing anyway is: “We’ll take the speed and fix errors separately.” I don’t agree with that, and my experience proves why. In reality: Errors don’t disappear—they move downstream Fixing them later is always more expensive You end up reintroducing manual checks anyway So the system becomes: Faster upfront → messy in the middle → expensive at the end Final takeawayThe biggest takeaway for me is this: I’m not against automation or speed. But I’ve learned that speed only works when accuracy is already under control. Otherwise, all we’re doing is making mistakes faster—and paying for them later.

In my view we should Prioritize Learning and Root Cause Focusing on deeper learning and root cause analysis leads to more sustainable and resilient systems—especially when AI already enables rapid short-term fixes. AI can restore operations within minutes, but repeatedly relying on quick fixes creates a loop where the same issues resurface. This increases operational load, frustrates customers, and prevents systems from maturing. By prioritizing root cause analysis, teams can eliminate entire classes of problems rather than continuously reacting to them. A strong example of this approach can be seen at Netflix. Their engineering teams go beyond immediate recovery by conducting detailed post-incident reviews and using chaos engineering to proactively uncover weaknesses. This focus on learning has helped them build highly resilient systems capable of handling failures without major customer disruption. Similarly, Google applies Site Reliability Engineering (SRE) practices that emphasize blameless postmortems and systemic fixes. Instead of optimizing only for quick recovery, they ensure every incident contributes to long-term reliability improvements. From a metrics perspective, prioritizing learning may initially impact operational KPIs such as: FCR (First Contact Resolution) FTR (First Time Resolution) In the short term, these metrics might dip because teams spend additional time investigating root causes instead of closing incidents quickly. However, this is a strategic trade-off. As deeper learning takes effect: Recurring issues are eliminated Incident volumes decrease Resolution quality improves Over time, FCR and FTR not only recover but improve significantly, showing greater consistency and stability. Instead of fluctuating due to repeated incidents, these metrics become more predictable and reflective of true system health. In an AI-driven environment: AI enables rapid containment to minimize immediate impact Teams focus on learning loops, using AI insights to identify patterns and prevent recurrence Final PositionWhile immediate resolution is necessary to contain impact, prioritizing learning and root cause analysis is the more effective strategy in an AI-enabled environment. It transforms operations from: Reactive → Proactive Repetitive fixes → Permanent solutions Metric-driven closure → Outcome-driven reliability This approach not only reduces incidents but also ensures that metrics like FCR and FTR improve sustainably and consistently over time.

I strongly believe that organizations should set strict limits on how far they go with personalization, even though AI makes it possible to create highly tailored experiences. While personalization can improve engagement, my own experiences show that going too far can reduce trust, create unfair outcomes, and increase risks for users. 1. Trust factor: One of the biggest concerns for me is how intrusive personalization can feel. For example, I’ve noticed that when I have conversations with friends or family about certain topics, I start seeing related recommendations on Instagram almost immediately. A recent example was when my friend and I were discussing the pros and cons of investing in Mumbai. Soon after, I started getting suggestions related to that topic on Instagram—even though I had never searched for it online. Even if this is just a coincidence or based on indirect signals, it feels like the platform is actively listening. This kind of experience is uncomfortable and makes me trust the platform less. Instead of feeling helpful, the recommendations feel invasive and irrelevant. 2. Aggresive Personalisation: Another reason I support strict limits is that companies can use personalization in ways that don’t benefit the customer. With access to detailed personal data, organizations can: Adjust pricing based on user behavior Push certain products more aggressively Predict how much a user is willing to pay This means personalization is not always about improving the user experience—it can also be used to maximize profit at the user’s expense. I find this concerning because it creates an unfair advantage for companies and reduces transparency for customers. 3.Risk of Fraud: The more data companies collect, the higher the risk of it being misused or leaked. Today, a lot of personal data is already available online, and AI makes it even easier to analyze and exploit that data. This creates serious risks: Data breaches can expose sensitive personal information Scammers can use this data to create highly targeted frauds Users can suffer financial losses due to misuse of their data In my view, collecting excessive data for personalization is not worth the increased risk it creates. Based on these experiences and concerns, I believe organizations should not try to maximize personalization. Instead, they should focus on setting clear and strict boundaries.

Hi friends while i was doing dpmo calculation i found that i got some interactions with a dpmo of 0 and some with dpmo of 10^6. how can we infer both of these values and calculate the sigma value?

I would like to know the difference between lean Zen, Lean Sensei and Lean Samurai? What separates them from each other and their relevance?