Bhargavi
Gudisa

The same ingestion code behaved differently depending on which Linux box it ran on. Environments were built by hand, so dev and production drifted apart and failures surfaced in one place but not the other — the slowest kind of bug to chase, because reproducing it is the hard part.

• Packaged the Python and Bash application into a Docker image so the runtime, interpreter version and system dependencies are fixed at build time rather than inherited from the host.
• Declared the GCP storage bucket, compute instance and service account in Terraform, so infrastructure changes go through review as code instead of being clicked into a console.
• Kept one plan across environments — the difference between dev and production is a variables file, not a different procedure.

Every Linux environment now runs the same version-controlled build. Rebuilding an environment is a Terraform apply rather than a day of manual setup, and “works on my machine” stopped being a valid explanation for a pipeline failure.

Thousands of AI chat responses needed review, and a wrong answer had two possible causes: the knowledge base genuinely lacked the fact, or the fact was there and the model failed to use it. Nobody knew which without investigating, so every failure was checked twice — once by content owners, once by engineers — and one of those investigations was always wasted.

• Built Python and Bash tooling to analyse responses at volume and produce remediation reports engineers could prioritise from, rather than a raw list of complaints.
• Designed a root-cause separation rule applied before the ticket reaches a human: if retrieval found nothing, it is a content gap; if retrieval found the entry and the answer did not cite it, it is a prompt-handling bug.
• Routed each class to the one team that can fix it, so a failure arrives with an owner already attached.

No one owned any particular area of the knowledge base. Reviews happened when someone noticed a problem, which meant content decayed quietly and the people best placed to fix an entry were never told it had gone stale. Auditing it by hand did not scale, and it was the first thing dropped under deadline pressure.

• Assigned one owner per content area so every entry has a name attached before it ever goes stale.
• Made review a release-gated step tracked in Jira, rather than an intention.
• Automated detection in Bash and had the audit open the review ticket against the mapped owner — the script does the routing, not a person.
• Made an unmapped area a hard failure: better to break the run than to silently skip entries nobody owns.

Town staff had to find the right row in a long records retention schedule before they could keep or destroy anything. The lookup was manual, easy to get wrong, and carried real consequences — destroying a record early is not a recoverable mistake.

• Built a Copilot Studio agent grounded in the Town’s own retention schedule through knowledge sources and topics, so answers come from the authoritative document rather than general model knowledge.
• Delivered it inside Microsoft 365, where staff already work, instead of as another system to log into.
• Made every answer point back to its schedule entry. The agent speeds up the lookup; it never becomes the authority.

Retention questions are answered conversationally in Microsoft 365 instead of by manually searching the schedule — and because the citation travels with the answer, a person can still verify before acting. The design treats the agent as a faster route to the source, not a replacement for it.

The Coffee Quality Institute dataset is public and messy — missing scores, unparseable harvest years, absent countries of origin. The normal way to handle that is to drop bad rows during the load, which leaves a clean table and no idea what is missing from it or why. An analyst downstream cannot tell the difference between “no data” and “data we quietly threw away”.

• Wrote the quality rules as named, individually testable predicates rather than conditions buried in a load script.
• Sent every rejected row to a reject table tagged with the rule that rejected it, so exclusions are queryable instead of invisible.
• Loaded clean records to Azure SQL and surfaced them in Power BI, with every loaded score traceable back to its source row.
• Published the lineage and a data dictionary to GitHub so other analysts can reuse the model instead of re-deriving it.

Every loaded score traces back to its source row, and every excluded row names the rule that excluded it. The lineage and data dictionary are published, so the model is reusable rather than one-off.

Permit requests lived in flat CSV exports. Status was free text, so the same state was spelled three ways; assignment was a name typed into a cell; and there was no referential integrity, no audit trail, and no safe way for two people to work at once.

• Designed a normalized schema with permit type and assignee as real lookups rather than repeated strings, modelled through Entity Framework Core.
• Wrote a T-SQL conversion script that migrates the legacy CSV, coercing dates safely and refusing rows that cannot be parsed instead of inserting nulls.
• Chose indexes from before-and-after execution plans rather than guessing — the covering index follows what the queue screen actually queries.
• Validated on both client and server, and deployed to Azure App Service.

Staff log, assign and close requests against a schema that enforces its own integrity, with legacy records migrated rather than abandoned. Index choices are backed by execution plans captured before and after, so the tuning is evidence rather than intuition.

A small business collects hundreds of reviews and reads almost none of them. The star rating tells an owner they are a 4.1; it does not tell them what to fix first, or where a competitor two streets away is beating them. Aggregate sentiment has the same flaw — one number cannot distinguish slow service from mediocre food.

• Scored sentiment per aspect rather than per review — coffee, food, service, wait time, price, ambience — by tagging each sentence to an aspect and scoring it independently.
• Scoped the comparison deliberately: 6 Philadelphia coffee shops drawn from the dataset’s 6.99M reviews, picked by review volume and proximity, so the competitor set is a real local market rather than an average.
• Chose VADER and keyword matching over an LLM. The tradeoff is accuracy for cost, speed and explainability — every score traces to the sentences that produced it, and the demo costs nothing to run.
• Landed the parsed reviews in SQLite between load and analysis, so scoring re-runs without re-parsing the source JSON.

The dashboard turns a wall of reviews into one answer: the target business trails its competitors most on food (−0.15), then service (−0.09) and wait time (−0.07) — a ranked list of what to fix rather than a rating to feel bad about. The known limits are stated in the repository rather than hidden: keyword matching misses phrasing an LLM would catch, and the public dataset covers 11 metro areas, so the live demo runs on Philadelphia.

A churn rate is a number, not a decision. Knowing that 26% of customers leave tells a retention team nothing about who to call first, and acquiring a replacement customer costs far more than keeping the one you have. The question worth answering is not how much churn there is but which segments it concentrates in.

• Cleaned and validated the raw dataset first — 7,043 rows down to 7,032 after resolving blank charge fields that would otherwise have been silently coerced to zero.
• Segmented churn by contract type, tenure, service mix and support level rather than reporting one aggregate, because the aggregate hides the only actionable finding.
• Quantified revenue at risk per segment, so the recommendations are ranked by money rather than by churn percentage.
• Specified a dashboard layout for ongoing monitoring, so the analysis does not expire the moment the notebook is closed.

Churn concentrates sharply in month-to-month contracts and short-tenure customers, which turns a vague retention budget into a specific target list. The repository carries the cleaning steps, the SQL and Python analysis, and the dashboard specification, so the method is reusable rather than a one-off notebook.

Retail organisations generate transactional data continuously and convert very little of it into decisions. The data arrives at the grain of a line item; the questions arrive at the grain of a quarter, a region or a product line. Closing that gap is modelling work, not reporting work.

• Loaded and cleaned the raw transaction data, then modelled it before analysing it — dimensions for product, region and time rather than repeated strings on every row.
• Wrote the analysis in both SQL and pandas, so the same figures are reproducible from the warehouse or the notebook and disagreements surface immediately.
• Tracked profitability alongside revenue, because the top-selling product and the most profitable product are frequently not the same one.
• Presented the result as KPIs and dashboard visuals rather than a notebook, since the audience is a manager rather than an analyst.

Month-over-month revenue movement, regional performance and the top product and customer cohorts are visible in one view, with the modelling and the queries published so the numbers can be checked rather than taken on trust.