Case Studies — full list

Competitive and regulatory context: the 2022 CCI order named MakeMyTrip and Goibibo together, and a separate CCI probe (2019) examined MakeMyTrip and OYO on related unfair-practice complaints — meaning this isn't a single-company problem, it's a pattern regulators are watching across the category. A March 2026 short-seller report (Morpheus Research) made further allegations — including that MakeMyTrip continued price-parity practices after the 2022 order, and used "mandatory" insurance opt-outs and late-revealed convenience fees. These are allegations from a party with a financial interest in the stock falling, not independently verified facts, and I'm treating them accordingly — worth naming because they're part of the public record, not because they're proven.

C — Cut Through Prioritization

Of the three personas, I'd prioritize Value Rakesh's need first. Price-sensitive comparison shoppers are both a large segment of OTA search traffic and the segment most exposed to a late fee reveal, since they've already anchored on the headline price shown at search. Business Priya's reliability need and Family Planner Anita's group-booking complexity are real, but lower-frequency, worth a later cycle rather than this one. Everything below is scoped to fixing Rakesh's need first.

L — List Solutions

1. All-in fare display at the results level: address the "drip pricing" pattern CCPA specifically names, before a regulator or a repeat of the SpiceJet outcome forces it.
2. Opt-in (not opt-out) add-ons at fare review — directly responsive to CCPA's forced-add-on pattern.
3. Persistent "compare dates" strip on results instead of reopening search.
4. Baggage/meal policy inline on the fare card, not a tap away.
5. One-tap "hold my seat 15 min" for indecisive high-intent users.
6. Smart filter defaults ranked by price + duration + layover, not price alone.
7. Payment retry with saved card + biometric re-auth to reduce late-stage abandonment.
8. Proactive delay-risk badge on results (feeds the Flight Delay Dashboard (T5)).
9. Group-booking mode for 4+ pax with a shared itinerary link.
10. Post-booking "manage trip" nudges (web check-in, gate-change alerts) via push.

E — Evaluate Trade-offs

RICE-scored, ranked by priority. Reach, Impact, and Confidence here are my own analyst judgment for illustrating prioritization method, not measured MakeMyTrip metrics — the two regulatory-motivated items are ranked P1 regardless of the exact score, because they're the two the CCPA framework and the SpiceJet precedent most directly bear on:

MoSCoW: Won't-have this cycle: the full loyalty-program overhaul (separate project, see Travel Loyalty Program Redesign below); it's a retention lever, not a fee-transparency fix.

Risks & Trade-offs

Every recommendation above has a real cost. Naming it here, before launch, not after — and grounding the scale in MakeMyTrip's own disclosed numbers, not a guess:

• All-in fare display: the honest total can look higher than a competitor's headline price at the results stage, hurting click-through from price-comparison meta-search and paid search ads. The fix that builds trust downstream may cost impressions upstream.
• Opt-in add-ons: directly reduces ancillary revenue per booking. MakeMyTrip's own FY25 filing shows $301.6M in customer-inducement-related revenue reduction already — a real, disclosed number that shows this isn't a marginal trade-off; it needs a revenue-per-booking floor agreed with Finance before shipping, not just a UX sign-off.
• Baggage/meal policy inline: minor engineering cost, no material revenue risk. The lowest-risk item on the list, consistent with its RICE ranking.
• Delay-risk badge: risks eroding trust in a different direction if the underlying prediction (see the Flight Delay Dashboard, T5) isn't well-calibrated. A wrong badge is worse than no badge.

Mitigation: ship all-in pricing and opt-in add-ons behind an A/B test, with revenue-per-booking as a guardrail metric alongside conversion, not conversion alone. A win on Fare Review conversion that quietly craters ancillary revenue is a loss dressed up as a win — and given the CCPA/SpiceJet precedent, shipping this proactively is materially cheaper than being the next enforcement case.

S — Summarize Recommendation

Ship all-in fare display and opt-in add-ons first: RICE 13.5 and 14.4, the two highest-scored and lowest-effort items on the list, and the two most directly responsive to the CCPA dark-patterns framework. Everything else on this list sequences behind those two.

Success Metrics: the HEART Framework

Using Google's own HEART framework (Rodden et al.) instead of a single catch-all "engagement" number:

• Happiness: CSAT specifically on "pricing clarity" (post-booking survey); NPS delta before/after the all-in pricing rollout.
• Engagement: searches per session; % of sessions using the new compare-dates strip.
• Adoption: % of eligible searchers who see and interact with the all-in fare display / opt-in add-on toggle in month one.
• Retention: repeat booking rate within 90 days, segmented by whether a user's first booking hit the old opt-out add-on flow or the new opt-in one.
• Task success: Results→Fare Review conversion (the primary metric this cycle targets — MakeMyTrip would measure this against its own internal baseline, which isn't externally visible), search-to-confirmation completion rate, time-to-book.

Tied to an OKR

Objective: Bring fare-review pricing in line with the CCPA dark-patterns framework, ahead of enforcement rather than in response to it.

• KR1: Establish an internal Results→Fare Review conversion baseline (not something an outside analyst can know) and target measurable lift after removing the late fee reveal.
• KR2: Reduce "hidden fees" CSAT verbatims by 50%.
• KR3: Ship both P1/Must recommendations this quarter, validated against an A/B test rather than shipped on judgment alone.

Sources: Morpheus Research report (allegations, not verified fact) · BusinessToday coverage · CCI probe, MakeMyTrip & OYO, 2019

Success Metrics

North Star: itineraries that convert to at least one booked leg. Supporting: time-to-first-itinerary (target <90s, ties to G1), swap rate per itinerary (a trust signal on first-pass suggestion quality: a high swap rate means the first draft is missing the mark), budget-target adherence rate, D7 return rate for pre-trip re-edits.

Launch Plan

• Phase 1 (MVP): single-destination domestic trips, 3–7 days. Itinerary generation + budget optimizer + weather sequencing only: the three P0 requirements.
• Phase 2: multi-city routing + persistent preference memory, gated on Phase 1 hitting its swap-rate and time-to-itinerary targets. Routing multiple cities is premature if the single-city itinerary still isn't trusted.
• Phase 3: live disruption reflow (Reactive Rhea's use case), gated on a flight-status API integration that doesn't exist yet.

Risks & Open Questions

Risk: hallucinated venue details (wrong hours, permanently closed) need a live data-freshness check; training-time accuracy alone won't catch them. Recommendation logic must stay auditable and explainable so it doesn't over-fit to popular/sponsored listings (same scoring discipline as the Hotel Recommendation Engine project, still on the roadmap).

Open questions this doc doesn't resolve:

• Should the budget optimizer be allowed to suggest a different destination than requested if it saves >30% of budget, or does that override user intent in a way that breaks trust?
• What's the fallback UX when no itinerary can be generated within the stated budget: degrade gracefully with a "closest match," or refuse and ask the user to adjust?
• Does surfacing restaurant/attraction rankings require a sponsored-placement disclosure, and who owns that legal review before launch?

Why Trust Is the Real Problem

Generating an itinerary is the easy half. The real PM problem is the trust layer around it: the "why this?" reasoning, the swap-not-regenerate interaction, whatever lets a user hand over planning without feeling like they lost control of the trip.

Flow 2: Baggage Policy Question (lowest-risk flow)

The contrast case: a pure information lookup with no action taken and nothing to confirm, so it needs none of Flow 1's guardrails.

• User: "How much check-in baggage do I get on my booking?"
• Agent (intent: baggage_query, 0.99 confidence) → tool call: fetch fare rules for the booking's specific fare class → "Your Economy Saver fare includes 15kg check-in. Extra baggage is ₹500/kg if you add it now, or ₹800/kg at the airport — want me to add extra baggage to this booking?"

Fully autonomous end-to-end: answered and resolved the likely follow-up (add baggage) without a human, because nothing here is irreversible or high-value enough to need a confirmation gate.

Flow 3: Booking Date Change (medium-risk flow)

Sits between the two above: it's an action, so pure information-lookup rules don't apply, but a correctable one, so it gets a lighter version of Flow 1's gate: confirm the fare difference, but no separate human-escalation trigger unless the fare-difference lookup itself fails. Intent: change_booking_date → tool call: check seat availability + fare difference on new date → agent states the fare difference and change fee → single confirmation → executes change_booking() and emails the updated ticket.

Agent Architecture

Four layers, in order: (1) Intent router: classifies the incoming message into one of the in-scope intents above, or "unclassified" → human. (2) Tool-calling layer: each intent maps to a fixed set of callable tools (PNR lookup, refund_policy_engine, fare-difference calculator, cancel_booking, issue_refund, change_booking): the agent can only call tools on this allow-list, it cannot invent new actions. (3) Confirmation gate: any tool call that is irreversible or moves money (cancel_booking, issue_refund) requires an explicit user confirmation turn before executing, never fires on the first pass. (4) Escalation router: triggers on low intent-confidence (<0.85), a tool call failing twice, explicit user frustration signals, or any query touching a hard non-goal (visa advice, disputes): handed to a human agent with the full conversation transcript attached, not restarted from zero.

Guardrails

This is the part of the design that actually differentiates a support copilot from a support chatbot, and the part a scope doc for an agent that can take real actions can't skip:

• Autonomous-action ceiling: the agent may autonomously execute cancellations/refunds up to a fixed rupee ceiling; above it, the same flow runs but ends in a human-approval step instead of auto-executing.
• Confirmation before irreversible actions: never optional, shown in Flow 1 above; a wrong autonomous cancellation is far more costly to trust than a wrong autonomous baggage-fee quote.
• No autonomous visa/legal advice: the intent router treats this as a hard non-goal, not a confidence threshold; it escalates every time, regardless of how confident the model is in an answer.
• Full audit trail: every tool call the agent executes, conversations included, is logged with the triggering intent, confidence score, and outcome, reviewable by support ops, the same operational-audit discipline as the PCMS payout reconciliation work (see Technical Execution, T27).

Evaluation Approach

Deflection rate alone is a misleading headline metric here: a bot can "deflect" a ticket by giving an answer that satisfies the user in the moment but is wrong, which shows up as a good deflection number and a bad outcome. Evaluation needs three lenses, not one: resolution accuracy (a sampled human audit of closed bot-handled tickets weighed against the bot's own confidence score), wrong-action rate: the safety metric, tracking autonomous actions a human reviewer would have executed differently, weighted far more heavily than any convenience metric, and escalation-appropriateness, checking the router escalates when it should as often as it deflects when it shouldn't.

Business Impact (modeled, not measured)

Illustrative, not a real support-cost figure: if cancellation, baggage, and date-change queries together are a modeled ~35% of ticket volume, and the copilot fully contains half of those (the baggage-query type especially, since it needs no guardrail and resolves in one turn), that's roughly a sixth of total support volume handled at near-zero marginal cost instead of a human agent's fully-loaded cost-per-ticket. The number that actually matters for a launch decision, though, is the wrong-action rate at that containment level; a model here would need real historical ticket data to size properly, which is exactly why this stays a scope doc and not a "built" project, unlike the modeled-but-labeled dataset in the Flight Delay Dashboard (T5).

Risks

The risk that actually matters isn't "the bot gives a bad answer": a Q&A chatbot has that risk too, and it's recoverable. It's the bot takes a bad action: an autonomous cancellation or refund that shouldn't have happened costs real money and leaves a damaged booking behind, well past an unhelpful chat log's worth of harm. Every guardrail above exists to keep that specific failure mode's blast radius small and recoverable (confirmation gates, action ceilings, audit trails) rather than trying to prevent it outright, which no confidence threshold can fully guarantee.

What Carries Over From T18

The same lesson as the ChatGPT Memory Feature teardown (Feature Reverse Engineering, T18) shows up again here in a higher-stakes form: the hard PM problem in agentic AI isn't language understanding or intent classification (those are largely solved). It's designing the guardrail and escalation layer that keeps the agent's inevitable mistakes cheap and reversible instead of expensive and permanent.

Architecture

Vite + @crxjs/vite-plugin + React + TypeScript, content script + service worker + side panel, all local storage: no backend, no accounts, no network calls. Reconstruction and merge are rules-based and client-side (segment by URL/submit/domain change/idle time; classify against the taxonomy; merge by step identity rather than literal position, so a single inserted or skipped step in one session doesn't break alignment for every step after it): chosen over ML because a wrong-but-explainable map the user can fix beats an opaque one, and there's no training data yet to justify the complexity.

Build Status

All 8 MVP milestones are built and gate-verified, end to end: scaffold → capture + masking + PII redaction → reconstruction spike → privacy preview → multi-session merge → map + analysis + register → brief + ticket export + ROI tracker → consent + metrics + polish. A subsequent hardening pass (an internal security/architecture review, not a third-party pen test) found and fixed a real capture-time privacy leak, redaction gaps, a cross-tab data-bleed bug, and a service-worker resilience issue where a single failure could permanently break the extension.

The AI-Opportunity Layer

Each captured step is classified by a step-signature taxonomy that maps to a likely intervention. This is the differentiated core, not the map itself:

Business Model & Moat

Land free/low-cost self-serve for a single workflow; expand paid per-team, priced against value delivered (opportunities implemented / hours saved) rather than seats, so price stays aligned with the ROI the buyer already cares about. The wedge is mid-market teams Celonis/UiPath structurally can't serve without cannibalizing their enterprise motion. Task mining itself is already a commodity; the moat is the compounding outcome-data asset built on top of it: every captured session, every thumbs-up/down, and every implemented-and-measured result teaches Weft which step patterns lead to interventions that actually saved money, which incumbents can't see because their tools stop at discovery.

Validation Plan: Riskiest Assumption First

Tests are sequenced by what would kill the product, cheapest first, with kill criteria set before each test, not "ship and see":

What the Scoping Discipline Bought

The disciplined part of this build wasn't cramming every good idea into the MVP; it was sorting six review-raised gaps by altitude. The ones that made the product invalid or unsellable without them (multi-session merge, page-content privacy) earned MVP slots; the ones with an expensive half (implementation hand-off, suggestion quality) got right-sized MVP features with the expensive part deferred; and the ones that were really principles or strategy, not build (worker-owned consent, the moat) got decided, not coded. Knowing which gap belongs at which altitude is the actual PM work, well beyond reacting to every piece of feedback the same way.

The Orchestration Layer

Planner, Critic, and Supervisor don't analyze resumes, JDs, or companies themselves; they reason about the other 15 agents. Their shared ground truth is AGENT_REGISTRY, a machine-readable catalog of every agent's required/optional inputs and real dependencies, built directly from how each agent is implemented, with every agent_id and depends_on reference in a Planner-generated plan programmatically checked against it before acceptance. This makes an entire class of hallucination (inventing an agent, or a dependency, that doesn't exist) structurally impossible rather than just less likely. Supervisor is the top-level entry point: it cross-checks Planner's execution plan against what actually ran, cross-checks every Critic-flagged issue against a named, specific fix rather than a general assurance, and renders a single go/no-go verdict while carrying forward every limitation the other 17 agents raised, instead of letting the verdict imply more confidence than the system actually earned.

What This Build Actually Surfaced

A shared registry beats trusting an agent's self-description. The tempting shortcut was describing the other agents inside each orchestrator's own system prompt, but that drifts the moment an agent's real required fields change and nobody updates three separate prompt descriptions; one machine-readable source of truth doesn't drift. Two-phase research beats one-phase "search and format": combining "search the web" and "structure the answer" into a single model call conflates two different failure modes (wrong facts vs. wrong JSON), so splitting them means a review can tell which one actually broke. And "insufficient evidence" has to be a first-class schema value, not a prompt suggestion; that's the lesson underneath the core design bet itself.

What Actually Made This Hard

Getting one agent to produce good output turned out to be the easy part. The hard part of building a trustworthy multi-agent system is designing the layer that keeps 18 agents honest about what they don't know, and makes that layer's own claims checkable rather than just plausible. Verification-by-recomputation, structural null-ability, and a shared dependency registry are three different tools solving the same underlying problem: trust that has to be earned by the system's design, not asserted in its prompts.

Q1 — "i want to make fresh project for deloitte company- analyze the whole company website and various other live websites and let me know on which problem statements they are working on?"

(deloitte.com and deloittedigital.com turned out to be blocked for direct fetching in my research environment, so this was built from indexed content, press coverage, and third-party analysis — not a raw site crawl.)

• Scaling agentic AI — and the governance gap behind it. Deloitte launched Zora AI (with Nvidia) — deployable agents for finance, HR, supply chain, procurement, customer service — already running internally on expense management (claimed 25% cost cut, 40% productivity gain). Their own Tech Trends 2026 report admits only 1 in 5 companies have a mature governance model for autonomous AI agents.
• AI output verification — and it's not theoretical for them. In 2025, Deloitte Australia delivered a 237-page government report with fabricated citations, a made-up court quote, and nonexistent academic references — and refunded ~$290,000 USD to the Australian government.
• Service orchestration at scale. TrueServe (Deloitte Digital) — an agentic service-acceleration platform already running 100+ projects across 60+ clients.
• Financial services clients are telling Deloitte their top pressures are regulatory/compliance complexity, AI adoption vs. stablecoin/digital-asset disruption, and workforce resistance to new tools.
• India-specific: Project Bharat (expansion into tier-2/3 cities), Union Budget policy advisory, and real open Product Manager roles in Bengaluru/Hyderabad/Pune.

Sources: Zora AI launch · Tech Trends 2026 · OECD.AI incident record · Computerworld · Fortune · Deloitte Digital / TrueServe · Financial services predictions · Deloitte India press room

Q2 — "product managers are working on which projects out of these"

Filtered the list down to what an actual Product Manager — not a strategy consultant, compliance advisor, or HR/infra team — would own:

• Clearly PM-owned: AI output verification/hallucination risk in client deliverables; governance maturity gap for autonomous AI agents; scaling agentic AI from pilot to production (Zora AI); AI-first process redesign vs. automating human-shaped workflows; tooling broken/suboptimized processes instead of redesigning them; service orchestration/personalization at scale (TrueServe); content supply chain fragmentation (Content Intelligence Hub); safely deploying GenAI in regulated industries (Agentforce accelerators).
• Borderline: translating AI ROI into enterprise financial impact (analytics/strategy usually owns the answer); AI ambition vs. stablecoin disruption in banking (becomes PM work only once it's a specific product).
• Not PM work (excluded): infra/security engineering, HR/L&D, org design, macro policy, compliance advisory.

Of the 8 clearly-PM ones, #1 (AI output verification) is the strongest fit — it's the one with a real, sourced, named incident behind it rather than a generic trend.

Q3 — "data management team might work on which project out of these"

Filtered for what a Data Management team (governance, quality, pipelines/ETL, master data, privacy/access) would own — not the PM layer on top:

• Primary fits: content supply chain fragmentation (Content Intelligence Hub — a named content pipeline built with Adobe/AWS); service orchestration/personalization (TrueServe's underlying "customer data platforms"); data-privacy regulation compliance; safe GenAI deployment in regulated industries (data classification/access governance before an agent can act); AI output verification (the Deloitte incident was fabricated citations — at root, a data provenance/lineage failure); scaling Zora AI (agents are only as good as the data feeds wired into them).
• Borderline: translating AI ROI (data management owns the reporting pipeline feeding it, not the answer itself); re-architecting tech orgs (data architecture is one input among several).

Interesting pattern: #21, #20, #17, #24, #1, and #3 all share the same underlying skill — building and governing the data layer under an AI/personalization product.

Q4 — "what project i should work on"

Build #1: AI Output Verification & Provenance — a guardrail product for the exact failure Deloitte already had. Reasoning given: it's not speculative (a named report, fabricated court quotes, a real refund, not a guessed trend); it bridges both the PM lens and the data-management lens at once; it extends an existing case study instead of starting from zero; and it's honest to build without pretending to have worked with Deloitte data.

Q5 — "consider me a layman person and in human centric language without considering what project i have already done- focus on deloitte and make me understand the requirement, problem statement."

Explained as a story: Deloitte Australia was hired to review a welfare compliance system; AI was used to help draft the report; nobody properly checked the AI's work before it shipped; the AI invented a quote and attributed it to a real judge in a real court case, and cited academic papers that don't exist. An outside researcher found it. Deloitte had to admit it, rewrite the report, and refund the government close to $290,000.

The real reason: not that the AI is "bad" — AI tools are known to occasionally invent plausible-sounding facts. The failure was a human process failure — whoever was supposed to verify every fact and quote either didn't do it carefully, or there was no system forcing that check to happen before the document went out. Like a newsroom publishing a fabricated quote because the editor didn't fact-check it.

What's actually needed, in plain terms: a reliable checkpoint that (1) flags anything AI-generated that hasn't been independently confirmed, (2) makes it easy to trace every fact/quote/citation back to something real, (3) refuses to let a document ship until that check has happened, and (4) keeps a record of what was checked and by whom.

Q6 — "where can i research about these things- share me links"

Grouped into: (1) the Deloitte incident itself — AI Incident Database entry, CFO Dive's two articles, Horses for Sources' industry take, with an explicit flag that outlets disagree on the refund amount ($63K–$439K depending on what's being described); (2) the general hallucination problem — Infomineo, Hatchworks, Digital Divide Data; (3) how people design the actual fix — Indium and Knostic on human-in-the-loop review, with the caveat that reviewers often approve AI output without truly verifying it when volume is high; (4) the official rulebooks — NIST AI RMF and the EU AI Act's official text, framed as "cite these, don't just cite blogs."

Sources: AI Incident Database #1193 · CFO Dive · CFO Dive (refund) · Horses for Sources · Infomineo · Hatchworks · Digital Divide Data · Indium · Knostic · NIST AI RMF · EU AI Act

Q7 — "so the incident occured in 2024, deloitte admitted in 2025, what measure steps currently deloitte is taking"

Corrected timeline: DEWR commissioned Deloitte Dec 2024; report delivered Jul 2025; a University of Sydney researcher spotted fabrications Sep 2025; Deloitte admitted, corrected, and partially refunded Oct 2025; a second, separate incident surfaced in Canada in Nov 2025 — Newfoundland & Labrador paid ~$1.6M CAD for a 526-page healthcare-staffing report also containing fabricated citations and real researchers credited with papers they never wrote.

What Deloitte actually did: in Australia — corrected the report, added a disclosure statement, partial refund. In Canada — called the fake citations "incorrect," stood behind the report's recommendations anyway, promised a citation review; no refund confirmed; a provincial accounting watchdog opened its own investigation.

The part that matters most: no public evidence of a real fix between incident one and incident two — Canada was delivered and flagged only weeks after Australia went public. Deloitte also already sells a product for exactly this problem — "aiStudio: Large Language Model Controls," including a literal "Citation Retriever" and "RAG Evaluation" control, part of "Deloitte Trustworthy AI™" — with nothing in public reporting suggesting it was used on their own report-writing.

Sources: CBC News · Fortune (Canada report) · FINRA 2026 coverage · The Independent (watchdog) · aiStudio LLM Controls fact sheet

Q8 — "which companies faced similar situations all over world- give me list"

Scale: as of April 2026, 1,313 documented court cases worldwide involve AI-fabricated content, 496 involving licensed attorneys; sanctions up ~11× in 18 months. Caveat given at the time: almost everything well-documented here comes out of the US, Canada, and Australia — most likely a visibility bias (public court records, active press), not proof the problem is smaller elsewhere.

Sources: Medium (KPMG) · LawSites · Forbes (Air Canada) · Open.cx · HAQQ

Q9 — "in india?"

The distinctive thing about India's version: the cases cluster in courts and government tax administration — not, so far, a named Indian consulting firm the way Deloitte/EY/KPMG got caught globally. Either they haven't been caught yet, or India's exposure is currently concentrated wherever the paper trail is public.

Sources: Medianama · The Wire · iPleaders · ThePrint (Delhi HC)

Q10 — "other than consulting firms which sectors and which companies made these mistakes all over world"

Tech: Google Bard's factual error in its public launch demo wiped ~$100B off Alphabet's market cap in a day; Microsoft Bing Chat gave wrong Gap/Lululemon financial figures live in its own launch demo. Media: CNET paused AI-written finance articles after errors; Gannett paused AI sports recaps after public mockery; Sports Illustrated's CEO was fired after AI-generated fake bylines. Retail/automotive: a Chevrolet dealership chatbot was manipulated into "agreeing" to sell a $76,000 Tahoe for $1. Logistics: DPD's chatbot was coaxed into swearing at a customer and calling DPD "the worst delivery firm in the world." Aviation: Air Canada held legally liable for its chatbot's invented refund policy. Government: NYC's "MyCity" chatbot still gives business owners fabricated legal information. Healthcare: a lawsuit alleges ChatGPT offered reassurance instead of urging emergency care during a serious health event. Banking: no named scandal yet, but analysts explicitly call it "not if, but when."

Pattern noted: two different failure modes — "fabrication" (Deloitte, EY, KPMG, Sports Illustrated, CNET: AI invents authoritative-looking content nobody checked) versus "loss of control" (Air Canada, DPD, Chevrolet: AI was manipulated or ungoverned in a live conversation the company had already called binding). Both point at the same missing checkpoint between "the AI said it" and "we stand behind it."

Sources: Slashdot (Google Bard) · NPR (Sports Illustrated) · AI Incident DB (Chevy Tahoe) · TechInformed (DPD) · Forbes (ChatGPT health lawsuit) · BizTech (banking risk)

Q11 — "we have noticed gemini not giving correct output or other platforms....currently which platforms are actually responsible for all these issues that happened in deloitte and other companies"

Direct answer on Gemini: Gemini is not behind any of the major professional-services scandals. Every disclosed one points to the same platform — OpenAI's GPT family via Microsoft Azure OpenAI — most likely because Azure OpenAI had the largest enterprise footprint during 2023–2025, a deployment-volume story, not necessarily a worse-model story. Pointed to the Vectara HHEM leaderboard as the real apples-to-apples comparison rather than incident anecdotes, and noted every current model still hallucinates on open-ended factual questions, Gemini included — but the paper trail on scandals specifically points at GPT-4/GPT-4o via Azure, not Google.

Q12 — "how many such ai platforms are launched till date and their names."

No official registry exists, so no exact count — but listed the ~19 organizations the industry treats as genuinely distinct foundation-model makers: OpenAI (GPT/ChatGPT), Google DeepMind (Gemini), Anthropic (Claude), Microsoft (Copilot, built on OpenAI), Meta (Llama), xAI (Grok), Amazon (Titan/Nova), Mistral AI, Cohere (Command), Perplexity, DeepSeek, Alibaba (Qwen), Baidu (Ernie), Tencent (Hunyuan), 01.AI (Yi), Zhipu AI (GLM), Stability AI, AI21 Labs (Jamba), Databricks (DBRX), IBM (Granite) — with hundreds of significant variants below that, and thousands of consumer products built on top of this handful, not separate platforms in the same sense.

Q13 — "what is india doing"

Regulation: India's Feb 2026 "AI Governance Guidelines" ("seven sutras") — an AI Governance Group, a Technology & Policy Expert Committee, an AI Safety Institute — explicitly principle-based and largely voluntary; real legal teeth currently come from the existing DPDP Act and IT Rules, not a purpose-built AI law. The guidelines themselves call for further review on generative-AI liability and accountability. Plus the judicial side already covered — the Supreme Court's July 2026 zero-tolerance ruling is doing more real enforcement than the voluntary guidelines.

Building platforms: under the ₹10,000 crore IndiaAI Mission, three sovereign AI models were unveiled at the Delhi AI Impact Summit — Sarvam AI's Vikram (30B) and a 105B reasoning model, Gnani.ai, and BharatGen. Plus Krutrim (Ola's AI arm, India's first AI unicorn, 22 languages), BharatGPT (already deployed at scale on IRCTC), and Bhashini (government language infrastructure).

Flagged as the sharpest angle: India is racing to build sovereign AI at government scale at the exact moment its own Supreme Court is ruling zero-tolerance on the failure mode those platforms haven't solved either — none of the three sovereign models have a publicly disclosed verification layer of their own.

Sources: Tribune (AI Impact Summit) · Official PIB guidelines PDF · explainx.ai · Business Standard · Rest of World

Q14 — "names of platforms other than those 19"

Added, with sourcing: Nvidia (Nemotron, and the "Nemotron Coalition" open-model alliance whose founding members include India's own Sarvam AI); TII/Falcon (UAE); Moonshot AI (Kimi, China); MiniMax (China); Huawei (Pangu — the only Chinese firm with both a frontier model and its own AI chips); Naver (HyperCLOVA X, Korea); LG AI Research (EXAONE/K-EXAONE, a government-backed Korean sovereign-model project); Samsung (health-specific foundation models). Plus a lighter-confidence list flagged as "not re-verified this session": Inflection AI (Pi), Character.AI, Snowflake (Arctic), Salesforce (xGen/Agentforce), Aleph Alpha, Sakana AI, Preferred Networks (PLaMo), Baichuan, StepFun, SenseTime, iFlytek.

Q15 — "and if any company launch their own ai platform - what measures are taken that it can be used."

Legally required, by region: EU — mandatory pre-market conformity assessment for high-risk systems (real law, real penalties). China — mandatory CAC security assessment + algorithm filing before public reach. US and India — no binding pre-launch requirement; NIST's AI RMF and India's guidelines are both explicitly voluntary. Outside the EU and China, a company can currently launch to the public with no prior approval from anyone.

What companies do on their own regardless of law: red-teaming (adversarial testing, documented with exact prompts and severity); model cards / system cards (published limitations and evaluation results); company-specific frameworks (Anthropic's Responsible Scaling Policy, Google DeepMind's Frontier Safety Framework, OpenAI's Preparedness Framework); staged rollout. Explicitly quoted the researchers' own caveat: "red-teaming practices vary widely, and there are few established standards or best practices" — closer to an honor system than an inspection.

Tied back to Deloitte directly: there was no CAC-style filing or EU-style conformity assessment standing between Deloitte and using AI in that report — the only thing that could have caught it was Deloitte's own internal review, which is exactly the layer that failed.

Sources: VDE (EU AI Act conformity assessment) · FPF (China's Generative AI Measures) · Innodata (AI red teaming) · Towards AI (model/system cards)

Q16 — "what all are actual legal documents - share me links"

Split into binding law (EU AI Act official text on EUR-Lex; China's Interim Measures for Generative AI Services, via China Law Translate and the CAC original; India's DPDP Act, 2023, via the official Gazette and India Code) versus guidance/frameworks that aren't codified statute (NIST AI RMF; India's AI Governance Guidelines PDF via PIB; FINRA's 2026 Annual Regulatory Oversight Report). Flagged explicitly: only the first group is actually law with penalties attached — the second is guidance, and conflating the two is exactly the kind of precision gap that got Deloitte in trouble.

Sources: EU AI Act (EUR-Lex) · China's Generative AI Measures (translation) · CAC original (Chinese) · DPDP Act (Official Gazette) · DPDP Act (India Code) · NIST AI RMF · India AI Governance Guidelines · FINRA 2026 Report (PDF) · FINRA guidance page

Q17 — "is there any other document that is left"

Added three more, since "legal document" specifically was asked: India's IT Rules, 2021 (Intermediary Guidelines and Digital Media Ethics Code), official MeitY-hosted PDF; Mata v. Avianca, Inc. (S.D.N.Y. 2023) — the original, most-cited AI-hallucination sanctions ruling, via CourtListener; Moffatt v. Air Canada, 2024 BCCRT 149 — the actual tribunal decision, via CanLII. Noted honestly that I could not find direct links to the Indian court orders discussed earlier (Supreme Court, Bombay HC, Bengaluru tribunal, Delhi HC, Manipur HC) since Indian judgments aren't reliably indexed by general web search — pointed to the Supreme Court's own judgment portal and Indian Kanoon as the right places to search directly instead of taking an unverified link on faith.

Sources: IT Rules, 2021 (MeitY PDF) · Mata v. Avianca (CourtListener) · Mata v. Avianca (full opinion PDF) · Moffatt v. Air Canada (CanLII)

Q18 — "what all details a company needs to submit to govt to ensure their AI models /platforms are working correctly"

EU AI Act Annex IV — the 9-section technical file (binding 2 Aug 2026, high-risk systems only): general description; design & development details including training/validation/testing data governance; monitoring, functioning & control; performance metrics (accuracy, robustness, cybersecurity); risk management; a lifecycle-changes log; applied standards; a signed EU Declaration of Conformity; a post-market monitoring plan.

China's CAC algorithm filing (within 10 working days of launch): algorithm name, type, intended purpose, technical mechanism, plus a security self-assessment report on a CAC template; only a limited public summary is disclosed (category, entity name, product, purpose, Beian filing number). 988 services filed, 598 app-level registrations completed as of mid-2026.

Everywhere else: nothing required. And the sharper point: neither real regime explicitly requires "prove every citation/fact in AI-generated output is real" — the EU governs the system in aggregate, China's filing is about the algorithm being registered, not auditing every document produced with it. Even where governments do require submissions, none of them ask the one question that would have caught Deloitte's actual failure.

Sources: EU AI Act — Annex IV (official text) · AppInChina (China's AIGC filing, plain-language)

Q19 — "before purchasing any AI tool what all things do companies verify"

Model quality (accuracy for the specific use case, disclosed hallucination rates, offline evaluation support, version-comparison); data handling (what happens to data sent to the tool, whether it trains the vendor's model, access controls, data residency); certifications (SOC 2 as baseline, ISO/IEC 42001 for AI management systems specifically, ISO 27001); contract clauses (ban on training on your data without consent, audit rights, 24–72h incident-notification SLA, no silent model swaps, clear liability/indemnification, a real exit/data-deletion plan); and ongoing monitoring — re-reviewing vendor certifications every 2–3 years or after any serious incident, not just once at signing.

Closed with the gap this doesn't cover: none of this verifies whether any specific document a team produces using the tool is actually true — vendor due diligence and output verification are two separate control layers, and most companies only build the first.

Sources: ACC (Procuring AI) · InfosecTrain (ISO 42001) · Internet Lawyer (10 clauses)

Q20 — "So deloitte purchased this right? Deloitte (Australia, welfare report) Microsoft Azure OpenAI — GPT-4o"

Confirmed: yes, almost certainly through an existing enterprise Microsoft relationship. Ran that against the Q19 checklist directly — SOC 2 ✅, ISO 27001 ✅, data residency controls ✅, no-training-on-data terms ✅ standard, established auditable vendor with SLAs ✅. Deloitte would have passed nearly every item. The vendor was not the problem — Microsoft/Azure OpenAI is one of the most heavily audited, certified platforms in existence. What Deloitte didn't have, and no vendor contract can supply, is a process step internal to Deloitte checking whether the specific citations in that specific report were real before it reached the client. Framed as the project's core insight: "Deloitte didn't fail at picking a trustworthy AI vendor. They failed at the one check no vendor relationship can ever cover: verifying their own output before a client saw it."

Q21 — "so it means deloitte or any company can buy any tool- but they shld also have internal tool that verifies if that tool is giving right output as per their clients bcs vendor might have large problem statement solved but we need to go in depth"

Confirmed and sharpened into one line: a vendor's AI tool is built to solve a broad problem, well, for millions of possible customers. It was never built to know whether it got a specific client's specific context, or a specific deliverable, right. That depth is always the buyer's job, never the vendor's. Explained why structurally: the vendor doesn't know the company's client, industry-specific facts, or what "correct" means in that specific deliverable — only the company itself has that context. So every company using AI needs a second, internal layer between "the AI produced this" and "we're sending this to a client" — one that can't be bought off the shelf, because buying it would just recreate the same problem one level up.

Q22 — "give me answer to all these questions and then i will decide on what i need to go in detail" (India-specific consulting firms, a real hallucination-rate comparison, and what Deloitte has actually changed internally)

1) Any Indian consulting firm caught yet? Not found — but the global pattern got bigger while looking. It's now all four of the Big Four, not three: KPMG's withdrawn Oct 2025 report fabricated specific claims about real, named clients (UBS, NHS Greater Manchester, Swiss Federal Railways, and a false claim that Emirates launched a chatbot called "Sara"); EY pulled a May 2026 loyalty-fraud report citing a McKinsey report that doesn't exist; and PwC was confirmed too — four separate PwC Middle East "thought leadership" reports (2024–2026) with fabricated citations, one assessed as 100% AI-generated once references are excluded, including an entirely invented governance framework called "Citizen Pulse." On India specifically: nothing found linking an Indian firm or engagement — only a mildly ironic Deloitte India press release on the same timeline titled "Indian enterprises lead global peers in at-scale AI adoption."

2) Real hallucination-rate comparison (Vectara HHEM leaderboard): two pictures exist. On the older, easier benchmark, Gemini models lead (Gemini-2.0-Flash at 0.7%). On the harder, Feb 2026 dataset (32K-token documents across legal/medical/financial domains), rankings shuffle and everything gets worse — GPT-5.4-nano 3.1%, Gemini 2.5 Flash-Lite 3.3%, Grok 3 5.8%, Claude Haiku 4.5 9.8%, Claude Opus 4.6 12.2%, Gemini 3 Pro 13.6%. The finding that matters: on the harder test, every current state-of-the-art reasoning model exceeds 10% hallucination regardless of vendor — Vectara's own hypothesis is that reasoning models' extra "thinking" steps introduce drift from the source, so more capable models get worse, not better, on this specific failure mode.

3) What Deloitte's actually changed internally: Deloitte's own position hasn't moved — still "stands by the recommendations" on Canada, still frames it as a citation-verification lapse. The real change came from the client, not Deloitte: Newfoundland & Labrador rewrote its own procurement process within days — mandatory human verification, audit rights over vendor AI use. That's a client protecting itself from Deloitte, not Deloitte fixing itself.

Sources: ThePrint (all four Big Four) · OECD.AI (KPMG) · GPTZero (PwC investigation) · Vectara (leaderboard) · Canadian Accountant (NL procurement update)

Q23 — "Lets get on 3rd problem" (deeper dive on Deloitte's internal response)

Found a brand-new, dated announcement — ControlCatalyst.AI, launched 12 Aug 2026 (days before this conversation), a suite for internal audit/SOX/risk-controls work, built on the same "Deloitte Trustworthy AI™" branding as the pre-Australia "aiStudio" product. Chased down what it actually does: automates control testing and evidence documentation for client engagements — the same pattern as aiStudio, a product sold to clients, not a fix aimed at Deloitte's own report-writing process. Verdict: this is the third AI-governance product shipped since Australia, and the third one aimed at what Deloitte sells rather than the specific internal failure that happened twice. The launch timing — 3 months after Canada, weeks after PwC's scandal broke — reads more like catching up on positioning industry-wide than a purpose-built response to this exact failure.

Sources: Deloitte press release · CPA Practice Advisor · TechEdgeAI

Q24 — "what all tools/websites/apps like ControlCatalyst.AI are present in market"

Three distinct market layers, not one:

Layer A — direct SOX/GRC competitors:

Layer B — the tools that actually caught the Big Four:

Layer C — enterprise LLM output-verification infrastructure (the category closest to a real project):

The honest read: Layer C is not empty — it's real, funded infrastructure. What doesn't exist anywhere publicly is the specific product decision to wire that infrastructure into one firm's actual report-delivery workflow. That's a PM gap sitting on solved technology, not a technology gap.

Sources: RiskWatch · Originality.AI (GPTZero review) · Braintrust (hallucination detection tools) · Galileo vs. Patronus

Q25 — "what pm gap missing didnt understand, tell me in detail"

Explained with the actual proof it's real: Deloitte already owned a citation-checker (aiStudio's "Citation Retriever") before Australia, and it still shipped fabricated citations anyway. The technology wasn't the problem. The smoke-detector analogy: owning a detector doesn't stop a fire unless someone's also decided which rooms need one, who checks the battery, what happens when it beeps, and who's accountable if it was dead for months. Six concrete decisions nobody's making at Deloitte: (1) does the check run on every report or only some; (2) where in the workflow does it run; (3) what confidence score is "good enough" to ship without a human; (4) whose job is it to actually check a flagged item; (5) what happens when someone overrides it under deadline pressure; (6) who's accountable if the whole thing gets silently bypassed. None of these are technology questions — they're business-process decisions, which is the actual, portable definition of what a PM does here that a detection vendor never will.

Q26 — "check whether our research work was complete or something left. And then check how government and deloitte are working together" (18 Sep 2026)

Completeness check on this log: Q1–Q25 hold up — every question has a primary source, and the "Where this goes next" list below was already fully resolved or pointing forward into Part 2/3. The real gaps are in the build, not the research: Part 2 is explicitly one audited report with Track C never run, and Part 3 has 4 of 7 planned screens still wireframe-only — both honestly labeled already, both blocked on this environment's network access to a source PDF, not on missing research.

New finding — Canada's accountability gap just got worse, not better. CPA NL (the professional accounting watchdog covering Newfoundland & Labrador) opened an investigation into Deloitte's fabricated citations in the $1.6M healthcare report — and in May 2026 closed it without investigating anything, on a legal-entity technicality: the report was delivered under a contract with "Deloitte Inc.," which isn't a CPA NL-registered firm, while "Deloitte LLP" (the firm that is registered) "was not a party to the contract and had no involvement in the report." Nobody has been held accountable for that report by anyone. This directly extends the project's own thesis from Q7/Q22 — not just that no internal fix is visible, but that the external oversight mechanism that might have forced one has now formally declined to look.

A correction, not an addition — checked and ruled out. A South Africa story surfaced in the same search results (a government AI policy pulled in April 2026 after 6 of 67 citations turned out to be fabricated) and it would have been easy to log as a fifth Big Four incident. Checked directly: it isn't one. The policy was drafted internally by South Africa's own Department of Communications and Digital Technologies under Minister Malatsi — no consulting firm named in any source as author or vendor. Noting this explicitly rather than silently skipping it, since conflating two similar-sounding stories is exactly the kind of unverified-citation error this whole research thread is about.

No evidence found that any government has cut ties with, blacklisted, or restricted new contracts to Deloitte specifically because of these incidents. Newfoundland & Labrador's procurement-process tightening (already logged at Q7) remains the only concrete governmental response on record — and now the one oversight body that could have added a second is off the table.

Sources: The Independent (investigation opened) · Ricochet Media (investigation closed) · Canadian Accountant · ANC Parliamentary Caucus (South Africa statement) · CNBC Africa (South Africa policy pulled)

Q28 — "what all steps should i plan by which i shld verify each thing in the document"

Formalized an 8-step verification methodology, each step mapped to what would need to be built to automate it:

Q29 — "now check each citation by going the link provided and see if statement is there"

Hit a real environment wall first: WebFetch came back EGRESS_BLOCKED on every domain tested — including a completely neutral sanity-check domain with zero sensitivity, confirming it wasn't a Deloitte-specific block but a full outage. Pivoted transparently to WebSearch as the verification method instead — same rigor, different tool. Result: all 49 present endnotes independently checked out as real — correct organization, correct date, correct author, topically accurate — across sources including DNB, IMF, World Bank, BIS, ESRB, IOSCO, BCBS, EIOPA, FSB, ECB, Bank of England, the European Commission, the Federal Reserve, UK Finance, Reuters, and Deloitte's own site. Two details worth flagging: endnotes #40 and #46 cite the identical "Future of Payments Review" report for two different points (redundant, not wrong), and #49 is a self-citation — Deloitte citing its own report on digital-asset regulation.

Then mapped every one of the 51 uncited citations (50–100) to its exact page and claim — the evidence that turns "roughly half is unsourced" into something concrete and checkable. The five below are the ones that matter most — specific, quotable statistics presented with the exact same confident formatting as the 49 verified ones, with no way for a reader to tell, just by looking at the page, which citations are checkable and which aren't:

Q30 — "so what all checks we did and what we did miss? what shld be the roadmap"

Self-audit against the 8-step framework: fully done — structural completeness, existence checks on all 49. Partial — content-accuracy (topic-level match confirmed, not full sentence-level verification) and self-citation (2 found, not run as a systematic sweep). Not done — named-author verification beyond 2 spot checks, statistical re-verification of every number, and recency (now actually possible in hindsight, since 2024 forward-looking predictions can be checked against what really happened by 2026). Turned that gap analysis into a 7-phase build roadmap — structural scan first (cheapest, catches the most), then existence + topical match, then the hard content-accuracy layer, then statistics, author-verification, self-citation/circularity, recency monitoring, and a governance policy layer last.

Q31 — "what else is missing in 8 step framework"

Pushed past execution gaps into methodology gaps — failure modes the 8 steps don't even have a step for. Found 7 more, restructured into 5 tiers by what kind of work each actually needs:

Q32 — "what all websites exist working on these frameworks"

Fresh market scan against the 5-tier structure — the finding is the shape of the gap, not any single tool:

Every specialist tool is built for a different document type, a different moment (live generation vs. after publish), or a different purpose (internal controls vs. public credibility). Nobody stitches structural + semantic + provenance + governance together, aimed at a firm's own published research output — the whitespace this whole thread has been pointing at.

Q33 — "explain me the gap in layman language"

Every existing tool is a specialist checkpoint doing one narrow job — a bouncer checking student IDs (SwanRef), a spell-checker built into a live chatbot (Patronus/Vectara), a plagiarism detector at a university (GPTZero), a lawyer's citation checker (Shepard's/NexLaw), or the internal-audit team checking a company's own books (Workiva/Diligent). Nobody's built the full check-up doctor — the one who takes a firm's own published report and runs it through every layer at once, and specifically tells you where the sourcing simply stops and nobody flagged it. That's exactly what the manual walkthrough of the Deloitte report proved by hand this week.

Q34 — "what all things need to be checked in full report"

Consolidated into a 10-item, end-to-end audit checklist: (1) document-wide structural count-match, (2) per-citation existence/attribution/topic/claim/context/placement, (3) every number and statistic, (4) every chart's data source, (5) every quote and named person, (6) self-referencing, (7) internal consistency across the document, (8) currency — did a forecast actually hold up, (9) the materiality-and-coverage decision of which claims matter most, (10) what happens after something's found wrong. This list is what the platform's architecture is a direct build-spec for.

Q35 — "does it cover — nobody has built the 'full check-up' doctor"

Mapped the 10-item checklist against the market scan, item by item, to confirm the gap is real and not just a hunch: existence/attribution (academic tools only), content-match (live-chat tools only), context/caveat-dropping (nobody, anywhere), citation-placement (nobody), derived-statistics (nobody), chart sourcing (nobody), self-citation as a standing feature (nobody), internal consistency (nobody), currency re-checking after publish (nobody), and materiality/remediation workflow (GRC tools have it, but for internal controls, not public reports). Confirmed: every specialist tool is either the wrong document type, the wrong moment in time, or the wrong purpose — the "full check-up" really doesn't exist yet.

Q36 — "what if each speciality is built so that the system is not heavy and correct output is given"

The instinct is exactly how these systems actually get built in the industry, not a simplification — confirmed against the market research itself (Braintrust, on the current RAG-eval landscape: "there is no single tool that does everything — a production stack layers an eval framework, a faithfulness checker, an observability platform, and an inline guardrail"). Laid out the shape: a cheap parsing layer runs on 100% of citations first; a router decides which specialists a given citation actually needs (a $-figure gets the statistics specialist, a quote gets author-verification, most citations trigger 2–4 of the roster, never all of them); each specialist stays small and narrow — several can be bought/integrated (Patronus, Vectara) instead of built; a lightweight aggregator combines verdicts into one score; governance sits on top as pure rules, no model at all. The real product becomes the router and the governance layer, glued around a handful of licensed specialists plus the handful nobody else has built.

Q37 — "what all specialisations are there"

Full roster, organized by what signal in a citation triggers each one:

Q38 — "what should be steps to check and conclude which route to go and which specialisation to be selected"

The router's actual decision sequence, run for every citation: (1) isolate the exact sentence and source attached to the marker; (2) the existence gate — no bibliography entry at all means stop immediately, flag unverifiable, nothing else runs (this single gate alone caught citations 50–100 in the real audit); (3) run the baseline 5 unconditionally; (4) classify the claim by scanning for $/% figures, quotes, forecast language, chart attachment, legal references, secondary sourcing, and attach only the relevant specialists; (5) score materiality separately, in parallel, deciding depth rather than which specialist runs; (6) aggregate every specialist's verdict into one tier — green/amber/red — with a full evidence record; (7) escalate anything uncertain or high-materiality to a human instead of auto-closing; (8) feed the human's decision back to sharpen future classification.

Q39 — "create a complete architecture from document extraction to final output"

Full 12-stage pipeline, grounded in the real Deloitte audit at every stage:

Q40 — "remember our main target is to find AI Hallucination"

An important correction, caught before it became an overclaim: what the manual audit found on the Deloitte report is unverifiable, not hallucinated — those are different claims. Hallucinated means the AI invented something that never existed. Unverifiable means there's nothing to check against; the claim could be entirely true. Re-sorted all 16 specialists against the real target: only 5 — Existence, Content-match, Author-verification, Statistics-match, Chain-of-custody — actually prove fabrication. Everything else (structural completeness, placement, self-citation, framing-fidelity, internal-consistency, currency, materiality/governance) is real report-hygiene value, but it isn't hallucination detection, and the pitch has to stay precise about which is which.

Q41 — "create an architecture for a platform — if required divide it into two things hallucination and unverifiable"

Split the pipeline into two tracks right after the Citation Graph stage, forking on one question — does this citation have a source at all: Track A (has a source) runs the 6 fabrication-proving specialists and can only output Real, Fabricated, or Suspicious. Track B (no source) runs a light 3-step check and can only ever output Unverifiable — it never touches the specialists that would let it claim fabrication, because there's nothing to check against. The two converge into a scorecard with 3 separate, non-blendable counts. Scored against the real report: 49 Verified · 0 Hallucinated · 51 Unverifiable — the honest number, not the inflated "51 hallucinations" headline it would've been easy to overstate.

Q42 — "what shld i make to have complete steps — architecture/wireframe/roadmap"

Recommended three linked deliverables: the architecture (the fork, the 12 stages, the specialist tiers, build-vs-buy calls); wireframes for the 7 screens a real user would need — upload, the scorecard dashboard, a per-citation detail view, the review queue, governance settings, the export report, and a cross-report trend view; and a roadmap sequencing the build so the sharpest claim ships first — Track A only (Existence, Content-match, Author-verify) as the MVP, then Track B and governance, then the remaining specialists, then monitoring, then the cross-report library.

Q43 — "now make a user diagram for complete architecture including internal architectures" (three review-and-fix passes, run against my own critique each time)

Built the diagram, then deliberately audited it against everything discussed above rather than treating a first draft as done. Round 1 found real gaps: Self-citation was missing from the specialist grid entirely, despite being the check that caught Deloitte citing itself twice in the real audit. Framing-fidelity and Internal-consistency — the two most differentiated, least-built checks in the whole market scan — were also missing. The Verdict Resolver could output "Suspicious," but the Scorecard only had 3 buckets, so a Suspicious verdict had nowhere to go. Materiality was described in a text label but never actually drawn as a real signal reaching the router. And the 5 data stores from the written spec were invisible on the diagram entirely.

Fixed all of it in two more passes: added a 4th, dashed-border Pending bucket so Suspicious verdicts can't silently disappear; drew a real materiality-signal line from Stage 1 into both tracks instead of just labeling it; drew all 5 data stores as their own elements with real connectors, including the one — Source Cache — that's genuinely read twice, once at first-check and again by Monitoring, months later. Then one more correction: re-checked whether "AI hallucination" — the stated goal — actually covered fabricated numbers, fabricated authors, and self-made claims with no citation at all. It didn't. Everything in the pipeline was triggered by a citation marker existing in the first place — a bare, uncited assertion stated as flat fact was invisible to the whole system. Added a third track, Track C, branching directly off Stage 1 before the citation graph is even built, scanning all uncited text for real factual claims and labeling them a 5th bucket: Unsupported Assertion — deliberately never confused with Unverifiable, because "cited but the trail ran out" and "never even tried to cite anything" are different failures with different fixes.

The current architecture: three tracks (Hallucination-checked / Unverifiable / Never-cited), 12 pipeline stages, 12 specialists, and all 5 data stores — nothing left as a label-only fix. Download the full diagram as a PDF →

Q44 — "at what step ai hallucination is checked" / "are fabrication of numbers, authors, and self-made claims all covered"

Precise answer, not a hand-wave: eligibility is decided at the fork (only Track A citations can ever be tested for fabrication); the actual checking happens across the 12-specialist grid; but the verdict itself — the single point allowed to output "Fabricated" — is the Verdict Resolver, one step after the grid. Nowhere else in the pipeline may produce that label. On coverage: fabricated numbers (Statistics-match, Derived-calc), fabricated authors/quotes (Author-verify), and fabricated sources (Existence) were all genuinely covered — but self-made claims with no citation at all were not, until Track C closed that specific hole.

Q45 — "create wireframe for each screen"

Built deliberately low-fidelity — gray boxes, one shared sidebar shell so all screens read as one product, and every label pulled from the real Deloitte audit rather than lorem ipsum: 49 Verified · 0 Hallucinated · 51 Unverifiable · 0 Pending · — Unsupported throughout.

The Scorecard — the headline view, gate status and the 51% gap visible before reading a single row.

Q46 — "now check wireframe and compare with User diagram — does it cover everything?"

Ran a real gap review, not a self-congratulation pass. Found: 8 of 12 pipeline stages had screen coverage, but Stages 1–3 (Extraction, Citation Graph, the Fork itself) had no visible processing state at all. Bigger problem — because the real audit came back with 0 Hallucinated and 0 Pending, every wireframe example only ever demonstrated the boring outcomes. No screen showed what it actually looks like when the system catches a fabrication, what a human sees mid-review with confirm/override buttons, or what Track C's detail view even looks like (it needs a genuinely different layout — no source panel makes sense when nothing was ever cited). Also flagged: only 5 of 12 specialists were ever shown running in any one example, and the Review Queue had no record of past reviewer decisions, only Governance's separate policy log.

Q47 — "add all missing details"

Closed every gap from the review: added a new Processing screen showing Stages 1–4 actually running as a live checklist. Expanded Citation Detail from one example to four full verdict states — Verified (real), Fabricated (illustrative, since the real audit found none, marked clearly as such), Pending under review (with the Confirm Verified / Confirm Fabricated / Request more evidence buttons that were missing entirely), and Unsupported — Track C's own layout, with no source panel and a different, 2-item specialist set. Gave Review Queue its own decision log, separate from Governance's. Added a cache timestamp to citation examples, giving the Source Cache store — invisible until now — an actual UI presence.

Q48 — "add on all specialists in form of drop down or something in roster"

Rather than force all 12 specialists into every example (unrealistic — a typical citation only triggers 2–5), added one real, working reference: a native <details> dropdown listing the complete 12-specialist roster with what triggers each one and what it checks, linked directly from every Track A example ("5 of 12 shown — view full roster →"). It's a genuinely functional disclosure, not a static image pretending to be one — the artifact is live HTML, so it actually expands and collapses.

Citation Detail's four verdict states, plus the full 12-specialist roster reference below them. Download all 8 screens as a PDF →

Q49 — "now compare this wireframe with actual tools present in world currently" / "so our is good to be launched in marketing through Deloitte"

Benchmarked each screen against real products instead of reasoning from memory. Citation Detail's split-panel layout is close to Turnitin's Similarity Report (matched-text-left, source-right, click to filter) — a mature UX pattern borrowed from plagiarism detection, not invented. Review Queue matches Optro's (formerly AuditBoard) own description of its dashboards: "purpose-built... automatically updated in real-time... quickly see what is in their queue." Governance's threshold-alerting concept is confirmed by Workiva's GRC platform. But the Scorecard's 5-way bucket split has no real precedent — GPTZero, SwanRef, and Vectara's leaderboard all collapse to one score or rate, never distinguishing "checked and fine" from "never checked." And Monitoring's per-firm trend concept has no precedent either — Vectara's leaderboard trends rates across different models, not one publisher's own report history. The finding: this product stitches together two tool categories that have never been combined — citation-checkers' simple in/out interaction, and GRC platforms' workflow/governance machinery.

On whether it's launch-ready: no, and worth being precise about why. What's real — the problem (found by hand, on an actual report), the market gap (confirmed against real tools, not assumed), and a complete, internally consistent architecture. What's missing before an actual pitch — zero working product code, a sample size of one audited report, Track C never actually run, no cost or data-handling story, and no adoption path inside a real firm. There's a real difference between this being the strongest answer in an interview room and this being ready to send to Deloitte's leadership — right now it's clearly the former, not yet the latter.

Q51 — "i want to know in detail about data... where we need to input, where we will get output, from where we will fetch, where third party api involved, where api to be created etc as a layman person" / "where do we need 3rd party apis"

Walked the whole pipeline stage by stage, in plain language, and landed on only four points where anything ever needs to leave the firm's own systems — everything else (upload, extraction, the citation graph, the scorecard, the export) stays entirely in-house:

The layman version of the answer: everything about the report you're auditing stays on your own servers by default. The only time anything goes outside is to ask a public question ("does this URL exist," "did this person really say this," "is this citation format real") — and the one touchpoint that does need to see your actual sentences runs on a copy of the model you control, not someone else's server.

Q52 — "what should i do to make mvp design prototype using the wireframe" / "make complete prompt from wireframe in detail" / "make prototype" → corrected: "first make design using wireframe than prototypr"

Answered the roadmap question the same way this whole thread had already earned the right to answer it — from the earlier wireframe pass, not from scratch: Wireframe (gray, structural — already done) → Design (static, real visual identity) → Prototype (interactive) → ship. Wrote a full build prompt translating the wireframes' 8 screens, their layout decisions, and the real Deloitte numbers into a build spec — then jumped straight to building the interactive prototype, skipping the middle stage. Caught directly: "first make design using wireframe than prototypr" — a fair, plain correction. Went back and built the missing Design stage before continuing, in the right order this time.

Q53 — the Design stage: static, full color, five screens

Built on the wireframes' exact structure, but with a real visual identity for the first time — a deep-teal accent (#146370), true green/rust status colors instead of gray labels, and every number still pulled from the real audit. Five screens: Upload, Processing, Scorecard, Citation Detail — Verified, and Citation Detail — Fabricated (illustrative only, since the real audit found zero fabrications — labeled as such on the screen itself, the same discipline kept since the wireframes).

The Scorecard in real color for the first time. The "1 Fabricated" tile is the illustrative example — the real audit's actual count is 0.

Q54 — the Prototype: the same four core screens, actually clickable

Same visual system as the Design stage, this time wired up with real state — Start audit on Upload triggers a live Processing animation that steps through the specialists actually running, which lands on the Scorecard, which links into Citation Detail's Confirm fabricated / Overturn — mark verified / Add note buttons. A visible trace of the earlier data-handling answer made it into the build itself: the Upload screen carries a real "Data sensitivity" field alongside report type, not just a file picker — a direct, checkable link between Q50's finding and what actually got built.

Q55 — "Create homepage style or first sign up page"

A screen that hadn't existed anywhere before this — every earlier build started at Upload, with nothing in front of it. Built as a genuine front door: a hero making the actual finding the whole pitch ("100 citations. We could only check 49."), a footnoted stat citing the audit itself, three proof-point numbers (4 of 4 Big Four firms with a fabricated-citation incident since 2024, 0 existing tools that audit a firm's own published reports end-to-end, 2 failure modes that look identical to a reader but need different fixes), a "how it works" walkthrough, and a working client-side sign-up form — work email, firm name, and report type, gated behind the same "Data sensitivity" thinking from Q50.

The front door the product never had until this pass — every number on it traces back to the real audit, not placeholder copy.

Q56 — the completeness pass: "what need to be on the first screen" / "how many screens" / "what each page should have like navigation bar" / "buttons" / "sections on each page" / "add up gap pages also when if something goes wrong"

A rapid, screen-by-screen audit across everything built so far, checked against the actual files rather than answered from memory:

Q3 — "check what all things are currently possible since i am not part of deloitte and what all will be possible post joining only in all phases"

Phase 0 — Diagnostic

Phase 1 — Pilot

Phase 2 — Scale

Phase 3 — Embed & Enforce

Phase 4 — Industry leadership

The standout ✅ across all five phases: running a real citation-fabrication check on an actual public Deloitte report. Almost everything in Phase 0–1 skews ✅; Phase 2–4 skew increasingly 🔒 as it requires real organizational authority — a healthy signal about where "PM work" ends and "PM job" begins, not a gap in effort.

Q4 — "which all teams shld actually be involved in these phases be it designers, developers, complaince, data etc"

Phase 0 — Diagnostic

Phase 1 — Pilot

Phase 2 — Scale

Phase 3 — Embed & Enforce

Phase 4 — Industry leadership

Noted pattern: Phase 0–1 skews technical/data/design; Phase 2–3 shifts to organizational roles (HR, Legal, partners) as it moves from pilot to mandate; Phase 4 shifts again toward strategic/external roles as it goes from internal fix to market position.

Q5 — "how PM work in each phase along with them"

Phase 0 — Diagnostic: the PM isn't building yet, just turning scattered signals into one decision-ready picture. With Data/Analytics: define the actual question (not "how many people use AI" but which practices, weighted by risk), then get it pulled. With Data Science/ML engineers: scope what "done" looks like for the exposure scan, then translate their technical output into a risk narrative leadership can act on. With delivery leads: run the post-mortem interviews personally — structured discovery, not delegated. With Legal/InfoSec: loop in early to flag landmines before they become blockers.

Phase 1 — Pilot: with the Designer, write the requirements, critique the design against a reviewer's real workflow under deadline pressure. With Backend Engineers, write the integration spec and negotiate feasibility, cutting scope yourself when needed. With Data Engineers, define exactly what the audit trail needs to capture so it's usable evidence later. With AI/ML engineers — the big one — don't set the confidence threshold alone or hand it fully to engineering either; understand the tradeoff curve together and own the number and its consequence. With QRM/Legal, write the first policy draft yourself rather than waiting for Legal to author it. With the practice lead and delivery teams, run the pilot rollout personally, collecting friction weekly. With Procurement, do the actual vendor bake-off yourself.

Phase 2 — Scale: with L&D, define the learning objectives, not the training content itself. With Data/Design on the dashboard, define what decision a QRM leader makes differently because of it, before anyone builds anything. With HR, make the case with data — you influence this lever, you don't own it. With each new practice lead, adapt the pitch to their specific risk profile rather than reusing one deck. With Internal Comms, write the core narrative; they own the channels and cadence.

Phase 3 — Embed & Enforce: with Legal/Contracts, supply the plain-language description of what the process does; they turn it into binding language. With Backend Engineers, define the hard-gate requirement and work through real edge cases (emergency overrides) together. With Partners — the hardest conversation in the whole plan — translate this into their language: risk avoided, not process added, usually one-on-one, not a group memo. With Sales/BD, supply the real flag-rate and override-rate trend data as ammunition. With Compliance/Internal Audit, welcome being audited without getting defensive.

Phase 4 — Industry leadership: with Data Science, define what "improving the model" should optimize for, based on real complaints collected over the previous phases. With Corporate Comms/PR, supply the honest data and actively guard against over-claiming — you know the real limitations better than anyone. With Strategy leadership, make the actual build-vs-sell recommendation, backed by years of real data, not a guess.

The pattern that repeats every phase: the PM sits between two people who each see half the problem, and makes the call neither owns alone — that's the actual, portable answer to "what does a PM even do here that the specialists don't already do."

Q6 — "who is decision maker in each phase"

The pattern: your decision authority stays roughly constant in scope while the stakes around you keep rising, so your relative power shrinks every phase even as the work gets no less rigorous — the real skill on display is building recommendations good enough that people with more authority keep saying yes to them.

Q7 — "once everything is approved in these reasearches - what should be next steps"

Step 1 — decide what this research is actually for. If it's becoming a portfolio project, the buildable slice is Phase 0–1, not the full 5-year roadmap. If it's interview/application prep, the deliverable is a tight, spoken 90-second version, not the full document. If both (the likely right call), the portfolio project becomes the interview prep — walking in having built the thing, not just described it.

Step 2 — do the one real, non-hypothetical thing first. Run the citation-fabrication check on an actual public Deloitte report. Everything else in this research is analysis of other people's findings; this would be a finding of your own — the highest-leverage action still sitting unstarted.

Step 3 — turn the diagnostic memo into something real. The Phase 0 content already exists (thesis, sourced pattern, the aiStudio irony, the KPMG/EY/PwC pattern) — package it as the actual one-page artifact a real PM would produce, written as if going to a QRM sponsor tomorrow.

Step 4 — scope the buildable prototype. Once the memo exists, decide exactly what Phase 1 looks like as a working demo — the reviewer screen, the confidence threshold, the audit trail — same pattern as OpsPilot, aimed at document/citation verification instead of a case queue.

Step 5 — decide on the real-world application angle. Real, live Deloitte India Product Manager roles exist (Bengaluru/Hyderabad/Pune) — worth deciding whether this body of work is also meant to feed an actual application, since that changes some of the framing.

Recommended sequencing: Step 2 first (fast, genuinely novel, de-risks everything after it), then Step 3 (mostly writing, not new research), then pause and decide Steps 4–5 together once the memo and the audit findings can be seen side by side.

Q8 — "i will decide this later- first tell me thinking i am PM of Deloitte and working on these phases"

Walked through it as a lived narrative rather than another table:

Phase 0 — Diagnostic. You've just been handed this mandate after the Canada incident made leadership nervous. Your first move isn't a meeting — it's a message to the AI Center of Excellence asking for raw usage numbers, and a separate, quieter message to two people who were on the Australia and Canada engagements, asking if they'd talk to you off the record first, before anything official. Those conversations are uncomfortable. Nobody wants to relive it. You're not there to assign blame — you keep saying that, and you mean it — but you still walk out with a clear picture: the citation-check tool existed, someone knew about it, and it just wasn't part of the actual checklist anyone followed under deadline pressure. That single sentence becomes the spine of your diagnostic memo. Meanwhile Data Science runs the citation-fabrication scan on a sample of 60 recent reports. The number comes back worse than expected. You land on: "14 of 60 sampled reports contain at least one citation we could not independently verify. At current volume, that's a material, recurring exposure, not an isolated incident." That one paragraph is what gets you Phase 1.

Phase 1 — Pilot. You pick government/public-sector engagements — same domain as both scandals, easiest case to make. The practice's Managing Partner is skeptical; his exact words are something like "we already have QA, why do we need another gate." You don't argue. You show him the memo, the 14-of-60 number, and one sentence: "This gate would have caught both of the incidents that already happened." He signs off, but tells you plainly he'll pull out if it slows delivery by more than a day. Now you're in the room with an ML engineer arguing about a threshold. She wants 85% — fewer false flags, less reviewer fatigue. You push for 95%, because you've just spent three months reading two post-mortems and you know exactly what a missed citation costs. You settle on tiered thresholds by report type, which is more work to build but is the right call, and you're the one who has to justify it later if it's wrong either way. By the end of the pilot, adoption is real but not universal — about 70% of eligible reports go through the gate. You report that number honestly instead of rounding up.

Phase 2 — Scale. This phase is less building, more repeating yourself to different audiences. You give the same pitch to four more practice leads, and each time you adjust it — Tax cares about a different kind of citation risk than Consulting does, so you actually go learn enough about each practice's report types to make the pitch land, rather than reusing one slide deck everywhere. The dashboard ships. Within a month you notice one practice has a flag-override rate three times everyone else's. You don't go in accusatory — you go find out why, and it turns out their reviewers genuinely don't have time allocated for this work, so the check exists but gets rubber-stamped. That's a staffing problem disguised as a compliance problem, and it's not something you can fix with a threshold. You escalate it as a resourcing gap, not a rule-breaking problem.

Phase 3 — Embed & Enforce. This is the phase you spend more time with partners than with any technical team. Making the gate mandatory firm-wide means asking the Executive Committee to change how every partner signs off on every deliverable — and you don't get that meeting easily. It takes a champion, someone senior enough to get you the room, and weeks of making sure the business case is airtight beforehand: adoption trend, override trend going down, zero incidents since rollout, and — quietly — the fact that two more competitors have now had the identical failure publicly. The meeting itself is short. Someone asks "what does this cost us in delivery time." You have the real number ready, because you tracked it honestly the whole time instead of hoping nobody would ask. It's small enough that the room moves on. Legal takes the plain-language description you wrote and turns it into three paragraphs of contract language you barely recognize, but it says what it needs to say.

Phase 4 — Industry leadership. By now this isn't your pet project anymore — it's just how the firm works. You spend more time on the feedback loop, tightening the model against years of real override data, than on convincing anyone of anything. Comms wants to publish a transparency report and asks you to write the technical section. You catch yourself pulling one sentence back — a draft that says "we've eliminated this risk" — because you know that's not true, and you'd rather it say "we've built a system that catches this before it reaches a client, and we keep improving it," which is honest and still strong. Someone in Strategy asks if this should become a product. You say yes, but only after showing them what it actually costs to run well — because you've watched enough well-intentioned tools get sold before anyone checked whether they were profitable to support.

Q9 — "dont tell year wise- i just need answer like if this problem statement in phase 0 is solved and approved then next step will be coversing with operations team, designer, developer etc according to the issue we solving" (refined over two follow-ups — "table," then "phase wise and each problem wise" — into this final form)

Q10 — "now make four plans- one that in this week as a PM outside deloitte - I should do, second include all things in the phases as discussed can be done even if not part of deloitte. Third plan as a PM of Deloitte to complete all phases. FOurth- tell me what all things already covered by non PM of Deloitte and left for the time I become PM of deloitte."

Plan 1 — this week, as a PM outside Deloitte:

Plan 2 — everything across all phases doable without being a Deloitte employee:

Plan 3 — the full plan to complete all phases as an actual Deloitte PM:

Plan 4 — what's already covered outside Deloitte vs. what's genuinely left for after joining:

The honest bottom line: Plan 2 covers the thinking and design layer of every phase — genuinely real, genuinely buildable. Plan 4's right column is where it stops being design and starts requiring actual organizational authority, actual people, and actual data that only exists inside the building.

Q11 — "now tell me genuine tentative timeline for plan 2 shld be kept"

Sequential: ~16–17 weeks (~4 months). With realistic parallelization: ~10–12 weeks (~2.5–3 months). Flagged two items not worth compressing further regardless of time pressure: the citation scan and the prototype — both lose their entire value if rushed.

Q12 — "plan 3" (same treatment, for the full insider plan)

Sequential total: ~3–4.5 years. With realistic overlap: ~2.5–3.5 years. Plan 2 (you, alone): ~3 months, gated by your hours. Plan 3 (as an employee): ~2.5–4 years, gated by other people's calendars and committees — roughly a 10x gap, and it's not about effort, it's the real difference between building something and getting a large organization to adopt it.

Q13 — "make roadmap for each team including all phases"

Flipped the axis — one row per team, showing its complete arc across all five phases:

What this view makes obvious that the phase-view didn't: Regulatory Affairs is the only team with zero gaps, active from Phase 0 straight through Phase 4 — literally the function I've been personally performing this whole research thread. QRM and Legal are the backbone, touching four of five phases each. Data Science has the strangest arc — heavy in Phase 0, silent through Phases 1–3, then back for all of Phase 4, a real staffing risk if that team scatters to other projects in between. Six teams (AI COE, InfoSec, Data Engineers, Procurement, Sales, Finance) appear in exactly one phase each — the easiest stakeholders to manage precisely because their ask is bounded.

Q14 — "now plan 4" (the same genuine-timeline treatment, applied to Plan 4 — the integrated real-world timeline)

Stage 1 — now, as an outsider (already covered by Plan 2): ~3 months, starting today. Tool inventory, regulatory tracking, the citation-audit, the diagnostic memo, the written policy, the working prototype, the training outline, the dashboard mockup, sample contract language, the mock transparency report — all done or in motion regardless of employment status.

Stage 2 — the honest gap in between: unknown duration. Applying, interviewing, getting an offer, onboarding. Genuinely not mine or yours to control, so no fake number gets attached to it.

Stage 3 — once actually hired: the leftover (Plan 4) items, with real timing. Everything below only starts counting from Day 1 as an employed PM:

The one number worth keeping: the outsider work doesn't get thrown away once hired — it compresses Stage 3's start. Walking in with an already-written policy draft, an already-built prototype, and an already-run citation audit means Phase 0–1 likely move faster than the table above suggests, because it's revising real work instead of starting from a blank page.

Methodology: the calculation, step by step

For every one of the 8,000 simulated flights:

• Draw a base delay from Gamma(shape=1.3, scale=3.2): mean ≈ 4.2 minutes, right-skewed.
• Multiply by that flight's airline reliability index (a single fixed number per airline, see table below), the only airline-level effect in the model, kept deliberately simple so differences between the fictional carriers stay modest rather than dramatic.
• Multiply by a time-of-day multiplier (0.90 Early Morning → 1.55 Night) to model how delays cascade later into an operating day.
• Add a fixed route congestion term (see table below), scaled by 0.35, a stand-in for how much busier Delhi/Mumbai/Bengaluru are than smaller airports.
• If the route is monsoon-sensitive and the month falls in Jun–Sep, add an extra Gamma(1.6, 5.0) term (mean ≈ 8 min).
• If the route is fog-sensitive and the month is Dec/Jan, add an extra Gamma(1.8, 6.0) term (mean ≈ 10.8 min), amplified 1.3× for Early Morning departures, since fog is worst at dawn.
• Cancellation is decided separately, as its own probability: a 0.6% base rate, +1.8pp if monsoon-exposed that month, +2.4pp if fog-exposed that month. If cancelled, delay is zeroed; a cancellation is a different outcome from "a very late flight," not the same thing at the extreme end.
• A flight counts as delayed if its final delay exceeds 15 minutes (the standard on-time threshold) and it wasn't cancelled.

Why these specific numbers: not derived from any real source, chosen and then iterated. The first draft produced an implausible 48.9% on-time rate; I scaled the base gamma parameters and congestion multiplier down until the fleet-wide rate landed at 84.4%, inside a plausible real-world range, while preserving the relative shape of every effect (which season is worst, which route is worst, night vs. morning). What this deliberately doesn't model: real distributional parameters fit from a published dataset (none was reachable from this environment), or flight-to-flight correlation (a delayed inbound aircraft delaying its own next outbound leg). A real airline operations model would need that, and it's a materially harder problem than this exercise set out to solve.

Methodology: the calculation, step by step

For every one of the 6,000 simulated flights, in order:

• On-time performance: starts from a base probability of 90%, reduced by that hub's congestion index (Delhi and Kolkata run busiest), then reduced further by −22pp if the hub is fog-sensitive and the month is Dec/Jan, or −14pp if monsoon-sensitive and the month is Jun–Sep.
• Cancellation: decided separately as its own probability (base 0.6%, +hub congestion, +weather exposure). A cancelled flight is always counted as not on-time, never the reverse.
• Load factor: drawn from a normal distribution around a base of 79%, shifted up in the Oct–Nov festive season and down in the Jan–Feb low season and at monsoon-exposed hubs during monsoon months.
• Revenue: ticket revenue = passengers × a per-hub base fare × a seasonal fare multiplier; ancillary revenue (bags, seats, meals) added per passenger on top. Both zero for a cancelled flight.
• Complaints: drawn from a weighted distribution that shifts hard toward more complaints when the flight was delayed, and harder still when it was cancelled — the one deliberate correlation this generator exists to demonstrate.
• Baggage mishandling: one independent per-bag draw, rate rising with hub congestion and on any day operations went irregular (delayed or cancelled).

A data-quality decision worth naming: the dataset tracks two different passenger counts — passengers_expected (a demand estimate, computed the same way regardless of outcome) and passengers_boarded (zero for a cancelled flight, by definition). Load factor and revenue are correctly built on boarded passengers, since those only exist for flights that actually flew. My first pass used boarded passengers as the denominator for the complaints-rate metric too, which made cancelled flights show zero complaints per 1,000 passengers: the exact opposite of reality, purely because a cancelled flight boards nobody. I caught this by sanity-checking the output before building the chart, not after — the reliability-vs-complaints chart on the dashboard would otherwise have shown cancellations as the "safest" outcome for a customer, which is backwards. Complaints are rated against expected passengers instead: the people actually affected by the flight, whether it flew or not. This is the same kind of judgment call as excluding cancelled flights before averaging delay minutes in the sibling dashboard — a metric's denominator has to match what the metric is actually claiming to measure, and getting it wrong doesn't throw an error, it just silently produces a plausible-looking wrong number.

Why these specific numbers: not derived from any real source, chosen and then checked against public ballpark ranges for plausibility (domestic OTP typically 70–88%, load factor typically 75–85%, baggage mishandling typically 4–8 per 1,000 bags industry-wide). The fleet-wide numbers landed at 77.9% on-time, 78.9% load factor, and 5.4 bags mishandled per 1,000 — all inside those ranges. What this deliberately doesn't model: real distributional parameters fit from a published dataset (none was reachable from this environment), or knock-on delay (one late inbound aircraft delaying that same tail number's next departure) — a real ops model would need that, and it's a materially harder problem than this exercise scopes to.