Geet Rajamanickam

I support View B — Preserve flexibility. Standardization improves consistency, but reducing local flexibility too much weakens real-world effectiveness. Example (Dispute Management Process): In a dispute resolution workflow: AI can standardize validation checks, categorization, and recommended actions → faster and consistent handling for ~80% of cases. But for complex disputes (e.g., cross-team dependencies, billing exceptions, or long-term customer relationships), local teams need judgment. If flexibility is removed: Valid exceptions may get wrongly rejected Customer escalations increase Resolution time actually worsens for complex cases If flexibility is preserved: Teams can override AI when justified Better handling of high-impact or unique cases AI + human judgment together improve both speed and quality So The strongest model is AI-led standardization with human override, not reduced flexibility.

I support View B — limit dependence on AI View A assumes a smooth trajectory: as AI improves, humans can step back. But operational reality is not smooth—it’s spiky. 95% of decisions → predictable → AI excels 5% of decisions → rare, ambiguous, high-impact → AI is weakest here If humans degrade capability during the 95%, they fail exactly in the 5% that matters most. Example: Digital Payments Failure (UPI outage scenario) India runs heavily on Unified Payments Interface (UPI). People use apps like Google Pay, PhonePe, and Paytm for daily transactions. With AI & automation: Fraud detection is AI-driven Transaction routing and approvals are automated Payments are instant and smooth Result: Fast, efficient system (like your 25–30% improvement case) What happens when AI/system fails? UPI outages have happened multiple times in India. During such outages: Shopkeepers cannot accept payments Customers don’t carry cash anymore Support teams rely on automated systems and dashboards But: Many frontline staff don’t know manual fallback processes Few understand how transactions actually flow between banks Issue resolution becomes slow and confusing Result: Even though the system is advanced, recovery becomes weak Simple takeaway AI made payments faster, but also made people less prepared for failure. That’s why organizations should: Use AI for speed But retain human knowledge for backup

I support View B — do not adopt the AI system in its current form. The 15% average improvement is real and valuable. But in aviation, the cost of a 2–3% catastrophic failure rate is not a rounding error — it is a structural flaw that disqualifies the system as currently designed.Improving averages while increasing the probability of high-impact failures is not a trade-off you accept in tightly coupled systems like airline operations. This isn’t a normal efficiency problem — it’s a systemic risk problem. ________________________________________ Why View B is the correct stance Airline operations behave like a networked system, not isolated events. A small disruption doesn’t stay local — it spreads. When AI removes buffers to optimize efficiency, it unintentionally creates fragility: • Crews, aircraft, and gates are interdependent • Delays propagate across hubs • Recovery windows shrink or disappear So that “2–3% failure rate” is misleading. These aren’t independent failures — they are cascade triggers. A system that performs better on average but fails catastrophically under stress is worse than a slightly less efficient but stable system. Examples Supporting View B 1. 🛫 IndiGo Airlines — Cascading Delay Crisis (2019–2023) IndiGo, India's largest airline with over 55% market share, repeatedly faced mass cascading delays due to tightly optimised turnaround schedules with minimal buffers. What happened: • IndiGo optimised aircraft utilisation to near-maximum efficiency • When a single aircraft developed a technical snag or faced ATC delays, the same aircraft operating 6–8 sectors per day had no recovery time • One disruption cascaded across hundreds of flights • In peak seasons, 500–800 flights were delayed on single days • DGCA (Directorate General of Civil Aviation) issued formal notices and fined IndiGo multiple times The parallel: Exactly like the scenario described — average on-time performance looked acceptable in reports, but the tail risk was catastrophic and frequent enough to be structurally unacceptable. DGCA's response was not "manage it separately" — they mandated buffer requirements and operational changes. This proves View B correct — regulators themselves rejected the efficiency-first model.So no — this AI system should not be adopted until it is redesigned to handle extreme scenarios, not just optimize the average.

I support View B — wait until the organization is ready, and I’ll go a step further: rushed implementation of a good AI idea is one of the fastest ways to make people distrust AI altogether. Why View B is the stronger approach A 25% improvement on paper is valuable — but execution risk can easily erase that gain if people are confused, resistant, or misaligned. AI gives you a recommendation, not a guaranteed outcome. The outcome depends on people. If you implement too fast: Teams may misapply the new workflow Managers may silently resist or revert to old methods Short-term disruption may hurt performance more than 25% Most importantly, trust in AI drops if the rollout feels chaotic And once trust is lost, even better future AI recommendations will be ignored. Performance improvement ≠ successful implementation AI answers: “What is better?” But organizations must answer: “Can we actually make this work right now?” Some Sample: KSRTC (Karnataka State Road Transport Corporation) — Bus Scheduling with AI KSRTC introduced an AI-based bus scheduling system to optimize routes, reduce fuel costs, and improve on-time performance across Karnataka. The AI analyzed passenger data, traffic patterns, and fuel consumption — and recommended significant changes to existing bus routes and driver shift timings. What Went Wrong Management pushed the new schedule quickly across multiple depots. But here is what they didn't account for: Drivers had followed the same routes for years — they knew every road, every stop, every shortcut The new AI-recommended routes were unfamiliar to them Union representatives were not consulted before the change Depot managers didn't fully understand how to read the new scheduling software The result: Drivers reported to wrong depots Some buses ran late because drivers took familiar old routes out of habit Passenger complaints increased in the first few weeks Driver unions called for a rollback The AI's recommendation was technically sound. Fuel savings were real on paper. But the implementation collapsed because people were not prepared. What Should Have Happened A simple three step approach would have saved the situation: Step 1 — Pilot first Test the new schedule in just two or three depots. Let drivers experience it. Collect feedback. Step 2 — Train before switching Show drivers the new routes. Walk depot managers through the software. Answer their concerns. Step 3 — Then expand Once confidence is built, roll out to remaining depots with people who now believe in the system. Reason for failure Drivers didn't resist because they were lazy or difficult. They resisted because nobody explained the why behind the change. A bus that runs on the wrong route — even with perfect AI scheduling — still fails the passenger. Readiness is not a delay. It is the difference between a change that works and a change that collapses. A great idea implemented badly will fail. A good idea implemented well will scale.

I support View A stopping the process immediately when AI flags a potential defect. Even though stopping takes time, the cost of letting a defective product reach a customer is much higher. For example, Toyota stops its production line if a defect is detected, which has reduced faulty vehicles and recalls while keeping customers happy. Some may worry about slowing down production, but in the long run, catching problems early saves money, protects the company’s reputation, and ensures quality. In high stakes manufacturing prevention is considered over throughput. other Reasons 1 Financial and reputation risk outweighs stoppage costs 2 .Safety-critical environments Toyota’s stop-and-inspect protocol shows that acting immediately reduces faulty outputs, prevents recalls, and protects reputation. Catching problems early ensures quality and saves money in the long run.Toyota’s stop-and-inspect protocol shows that immediate action reduces faulty outputs and preserves trust. The "Quality Escape" Incident: Boeing (2024–2025) A prominent recent example involves Boeing’s quality control crisis. In early 2024, a door plug blew out on a 737 MAX 9 mid-flight. Investigations revealed that while manufacturing systems were designed to track components, "quality escapes"—defects that bypassed inspection—were systemic. The Cost of "View B": Boeing faced approximately $20 billion in immediate fines and compensation, with indirect losses exceeding $60 billion due to canceled orders. The Pivot to "View A": By 2025, Boeing shifted heavily toward an AI-driven predictive maintenance and inspection model. In their Renton and Everett factories, they implemented AI tools that flag defects in real-time, reducing the time spent fixing supplier issues by 40% compared to 2024. They prioritised these "stops" because the cumulative cost of a single mid-flight failure dwarfed the operational cost of production pauses.