I spent four years helping Fortune 500 OEMs make sense of complex manufacturing data. Today, I'm applying the same systems thinking to build products that transform public and operational data into clear, actionable intelligence.
Whether you're working with operational data, internal documents, or large public datasets, I build decision systems that turn your data into information people can search, understand, and act on.
Tell me what you're building, the data you're working with, and where you're getting stuck. I'll review your submission before the call so we can spend our time discussing solutions rather than gathering context.
Publyq transforms raw public grievance records into a searchable civic intelligence layer. By combining data enrichment, geospatial mapping, and conversational analytics, it helps users understand what is happening across a city instead of searching through thousands of individual complaints.
Every day, cities receive thousands of public grievances covering roads, drainage, waste management, street lighting, and other civic issues. While this data is publicly available, it remains fragmented across individual complaints, making it difficult to identify recurring problems, accountability gaps, or city-wide trends.
Governments are publishing more operational data than ever before, but most public systems are still built to track individual complaints rather than understand the bigger picture. Advances in modern search and language models now make it practical to explore large civic datasets using natural language instead of complex dashboards or SQL.
I spent four years building enterprise analytics systems that helped engineering teams identify recurring failures across millions of manufacturing records. Publyq applies the same engineering mindset to public infrastructure, turning fragmented civic data into systems that support better decisions.
Keeps conversational analytics responsive while reducing inference costs and avoiding dependence on external APIs.
Lower reasoning capability than frontier models, but significantly better control over latency, privacy, and operating cost.
Public grievance data is highly structured and benefits from relational queries, spatial enrichment, and deterministic retrieval before language model inference.
More engineering effort during data ingestion, but produces more reliable and explainable answers.
Kashiq automatically parses bank statements, categorises transactions, and combines multiple accounts into a single, searchable view of personal finances with intelligent transaction clustering.
Strengthening the parsing and auto-clustering engine to enable multi-format document ingestion (PDF, CSV, XLSX) and MECE-based transaction classification.
Every bank exports statements in its own format, with different column names, date formats, and transaction descriptions. Understanding real spending, savings, and runway across several accounts means opening each statement by hand and re-classifying the same recurring merchants every month, so most people fall back to a rough mental estimate of where their money goes.
Bank-exported statements are universally available, yet remain fragmented across formats and institutions. Advances in document parsing and transaction intelligence now enable these records to be consolidated into a single, structured financial ledger that works consistently across banks.
Clusters are keyed on the normalized counterparty and debit/credit direction only, not amount or bank. The same merchant, like rent or a food delivery app, is grouped into one cluster regardless of how much was spent or which account it came from, so it only needs to be classified once.
Correctness now depends entirely on the counterparty-extraction step being clean; two genuinely different payees with similar noisy descriptions can collide into the same cluster if the name-cleaning rules aren't precise enough.
Bank statement descriptions follow predictable prefixes (UPI, NEFT, RTGS, IMPS, ATM, POS), so a sequential regex pipeline extracts clean merchant names without calling a model per row, keeping parsing instant, free, and fully explainable.
Every new bank or statement format needs an explicit pattern added to the pipeline, and formats outside those rules fall back to a generic heuristic that's less accurate than the bank-specific matchers.
For a single-user, self-hosted tool, a flat JSON file keeps the entire dataset transparent, portable, and trivial to back up or inspect, without the operational overhead of running a database.
It won't scale to concurrent multi-user access or very large transaction volumes, but for one person's transaction history it's simpler to reason about and debug than a full relational database.