About This Project
A portfolio piece demonstrating data engineering, process mining, and applied LLM integration.
Why this exists
This is a self-contained demo built to show, end to end, how a real process-mining and AI-assistant system fits together -- not a toy example, but a full slice of what an analytics platform for a mid-size company would actually look like: a relational database, live process discovery from event logs, an LLM-powered assistant grounded in real data, and a modern web frontend, all wired together and deployable for free.
The simulated company
"Nordwind Outfitters" is a fictional ~180-employee outdoor & camping gear manufacturer/distributor. Its entire database -- around 35 tables covering HR, suppliers, customers, products, inventory, sales, procurement, support tickets, CRM and general ledger -- is generated by a deterministic Python script (Faker + numpy, seeded for reproducibility). No LLM is involved in generating the data: that keeps it fast, free, and exactly repeatable. Three business processes are simulated end to end with deliberately injected bottlenecks, rework loops and rare paths, so the mined process models are genuinely interesting rather than a straight line.
How the process mining works
Event logs (case ID, activity, timestamp, resource) are derived from the underlying order/ticket status-history tables -- mirroring how a real process-mining project extracts an event log from ERP data, rather than the generator writing "the event log" directly. From there, a directly-follows graph (frequencies and average durations between steps) is computed directly in pandas, and pm4py's Inductive Miner algorithm discovers an actual Petri net with a token-based-replay fitness score -- real algorithmic process discovery, not a hand-drawn flowchart.
How the chatbot works
Rather than open-ended text-to-SQL (unreliable on small models and a SQL-injection surface), the chatbot uses a small fixed toolset of parametrized, read-only database queries. A deterministic keyword router decides which tool(s) a question needs, the results are serialized as JSON context, and the LLM is asked to compose the final answer strictly from that context -- so answers are grounded in real numbers, not invented. The LLM itself sits behind a small provider interface, so swapping between a local model (Ollama) and any hosted OpenAI-compatible API (Groq, OpenAI, OpenRouter, ...) is a one-line configuration change, not a rewrite.