DEV Community: Nirmal Joseph Ukken

700,000 people watched a VLC redesign. I built the player.

Nirmal Joseph Ukken — Wed, 14 Oct 2026 06:07:21 +0000

A VLC redesign video went up on YouTube, and I caught it the day after it was released. It already had about half a million views and around 2,000 comments, and the comments kept asking the same thing: Is this real? Can I actually use it? Will VLC ever look like this?

It's now past 700,000 views, and the answer to those comments is still no. It's a design concept, not an app.

Seeing that much demand, I thought: why not try building it myself? Within two days I had a working media player on my PC, set as my default app, with installers for Windows, Linux and macOS.

This is the story of Pylon: where the idea came from, how it's built, what broke along the way, and what I learned shipping a desktop app.

nirmaljosephukken / pylon-player

A calmer, redesigned interface for the VLC engine on Windows. Hover-only controls, drag-to-sync subtitle timeline, per-show presets, library and queue. Based on Juxtopposed's VLC redesign.

Pylon

A calmer, redesigned interface for the VLC engine, for Windows, Linux and (experimentally) macOS.

Download: Windows · Linux · macOS (experimental) · All releases
You also need VLC installed. See Install.

Pylon puts a new interface on top of libVLC, the engine inside VLC media player. VLC still does all the playback, decoding, subtitles and streaming, so Pylon plays everything VLC plays. The interface is built around the way people actually watch: quiet bars that get out of the way, a thick seek bar, subtitle timing you can see, per-show presets, and a library and queue you can reach without leaving the video.

Beta. Tested on Windows 10/11 and Ubuntu; the macOS build hasn't been tried on a real Mac yet. Bug reports are very welcome.

Credit

The interface follows the VLC redesign concept by Juxtopposed:

Video: the VLC redesign walkthrough
Design file: VLC redesign on Figma…

View on GitHub

It started with a YouTube video

Juxtopposed published a redesign concept for VLC media player. VLC is the player everyone has installed and nobody calls beautiful. The redesign kept everything that makes VLC great and rethought how it feels to watch something: quieter controls, a seek bar you can actually hit, subtitle timing you can see, and settings that don't throw a dialog over your video.

The design was shared on Figma Community under a Creative Commons licence. But it was a concept, not an app, and judging by the comments, I wasn't the only one who wanted to use it, every day, on their own files.

Skin or wrapper?

My first thought was a VLC skin. VLC does support skins, but they can only rearrange and restyle VLC's existing controls. The ideas I liked most (a subtitle timeline, a settings sidebar, a real queue, a home page with "continue watching") need new behaviour, not just new pixels.

So I went the other way: a new app with VLC's engine inside it. VLC ships its playback engine as a library, libVLC. Pylon is a new interface on top of that library. VLC still does all the decoding, subtitles and streaming, so Pylon plays everything VLC plays.

The stack:

Python for the app
Qt for Python (PySide6) for the interface
python-vlc to talk to libVLC
VLC 3.0, installed separately, for the actual playback

What it looks like

The features I built from the concept, plus a few of my own:

Quiet bars. The top and bottom bars float over the video, appear when you move the mouse, and disappear when you stop. They work in fullscreen too. H hides everything.
A thick seek bar with hover time, bookmark ticks and chapter marks.
Cone volume. A volume control shaped like a traffic cone lying on its side. Click, drag or scroll, up to 125%.
A settings sidebar (Ctrl+T) with Subtitles, Audio, Video, Playback and Bookmarks tabs, so nothing covers the video.
A subtitle timeline. You can see where subtitle lines fall around the playhead and drag them until they line up with the speech.
Per-show presets. Save subtitle timing, look, tracks and speed once, and every episode in that folder uses them.
Subtitles in bulk. Add subtitles to a whole season at once. Files are matched by episode number (S01E02, 1x02, E02).
A real queue and library. Playing an episode queues the rest of the folder, so the next one just plays.
On-screen hints. Every key you press shows what it did, and every shortcut can be changed.

The interesting problems

1. Drawing on top of a video you don't own

libVLC draws video straight into a native window, using the window handle you give it:

player = instance.media_player_new()
player.set_hwnd(int(video_widget.winId()))      # Windows
# player.set_xwindow(...) on Linux, set_nsobject(...) on macOS

That's fast, but it means Qt can't paint over that area. Any button you put "on top" of the video simply isn't visible. The fix was to make the top and bottom bars their own small frameless, translucent windows that float above the video and follow the main window around. It sounds hacky, but it's how you get controls that fade over the picture.

2. The player froze, and then it didn't play at all

libVLC reports events (playing, paused, ended, length changed) from its own thread. My first version called back into VLC from inside those event handlers, and every so often playback froze. The rule I ended up with: event handlers only emit a Qt signal, nothing else. The GUI thread then asks the player for the real values.

# runs on a VLC thread: never touch the player here
em.event_attach(vlc.EventType.MediaPlayerPlaying,
                lambda e: self.state_changed.emit("playing"))

# and connect it so Qt delivers it on the GUI thread
engine.state_changed.connect(self.on_state, Qt.QueuedConnection)

Qt.QueuedConnection turned out to matter. stop() fires its "stopped" event on the calling thread, so a direct connection could re-enter the player while it was still stopping, and the app locked up.

Then, on my actual Windows PC, nothing played at all. The clock sat at 0:00. A small diagnostic script showed play() returning -1. The cause was a single character: Qt gives you paths with forward slashes (D:/Movies/file.mkv), and VLC on Windows wanted backslashes. One os.path.normpath() later, it played.

3. Making it the default player on Windows

I wanted to double-click a video and have it open in Pylon. Windows lists apps in Default apps by their .exe, and Pylon was a Python script, so it showed up as "Python" or not at all.

The fix was a tiny launcher, Pylon.exe, written in C. It finds the bundled Python next to it and starts the app with the file you clicked. It's about 90 KB and has Pylon's own icon, so Windows treats Pylon like any other app. The installer then registers Pylon under "Open with" for 34 video and audio types. Windows doesn't let apps make themselves the default, so the last click is still yours.

4. One-click installers

Asking people to install Python, then pip packages, then run a script, loses most of them. So each download now carries its own Python and Qt:

	Download
Windows 10/11	`Pylon-Setup.exe`, a per-user installer (no admin needed)
Linux	an AppImage: `chmod +x`, then run
macOS (experimental)	a zipped `.app`

Qt is big, so I trimmed it to the modules Pylon actually imports (Core, Gui, Widgets, Svg, Network) by reading each library's import table. That keeps the Windows installer around 22 MB.

VLC is never bundled. You install VLC yourself and Pylon finds it. That keeps the licensing simple and means you get VLC's own updates.

5. The bug my first real user found

Version 1.1.0 worked on my test setups, then didn't find VLC on my own PC. The reason: when you pick a folder with the installer's Browse button, the installer adds \Pylon to the end. My VLC was at E:\Softwares\VLC, Pylon ended up in E:\Softwares\Pylon-1.1\Pylon, and Pylon only looked one folder up.

Version 1.1.1 now looks in a few folders above itself as well as the usual places, setup saves the VLC location it finds, and if you point Pylon at VLC by hand it starts using it immediately instead of asking for a restart. Small fix, but it's exactly the kind of thing you only find by installing your own app like a stranger would.

The name

It started as "Cone Player", after VLC's traffic-cone logo. That was too close to VLC's trademark, so I renamed it Pylon: another word for a traffic cone, and a nod to where it came from without borrowing anything.

Doing it properly: credit and licences

Because this builds on other people's work, I tried to get the boring parts right:

The design is credited to Juxtopposed in the README and in the app's About box. The Figma file is under CC BY 4.0, which allows adaptations with credit. No files or artwork from it are included; the interface is rebuilt in code.
VLC and VideoLAN: Pylon says clearly that it isn't affiliated with or endorsed by VideoLAN, and it doesn't use the VLC name or cone logo as its own.
The code is MIT licensed. The bundled Python, Qt for Python and python-vlc keep their own licences (PSF, LGPLv3, LGPL 2.1+), and those licence texts ship with every download.

How I built it

I built Pylon with Claude (Anthropic's AI) as my pair programmer. My part was the product side: deciding what to build from the concept, testing every version on my own Windows PC, finding what broke, and deciding what "good" looked like. Claude wrote most of the code, the installers and the documentation with me, one problem at a time.

What surprised me most is how much of shipping software isn't the main feature. Getting a video on screen was the easy part. The rest was paths, threads, file associations, installers, licences and an installer that adds \Pylon to your folder.

What's next

Not built yet from the original concept: thumbnails while seeking, a waveform seek bar, music sorted by artist and album, and casting. The macOS build also still needs someone with a real Mac to try it.

Try it

Code and downloads: github.com/nirmaljosephukken/pylon-player
You'll need VLC installed (Pylon uses its engine).
It's a beta. If something breaks, please open an issue. Bug reports are the most useful thing you can send me.

To everyone in those comments asking "can I actually use this?": now you can. I'd love to hear what you think, especially which feature you'd want next. And if you haven't seen Juxtopposed's video, go watch it. None of this exists without it.

When Does a Question Need an Agent? RAG vs GraphRAG vs Agentic GraphRAG on TigerGraph

Nirmal Joseph Ukken — Wed, 07 Oct 2026 11:04:12 +0000

Everyone is building agents. Fewer people are asking when an agent is actually worth it. An agent plans, calls tools, checks its work and tries again, and every one of those steps costs tokens and time. If a single retrieval answers the question just as well, the agent is overhead.

For the TigerGraph Agentic GraphRAG Hackathon I tried to answer that question with numbers. I built three question-answering pipelines on the same TigerGraph graph, gave them the same LLM and the same questions, and measured where each one succeeds and fails. I called the project OlympicRAG, because most of the corpus is about Olympic events.

The setup

The hackathon provides 2,951 Wikipedia articles (Olympic events from 1988 to 2022, plus films and people), 100 public questions with answers and 50 hidden ones. I added three small sets of my own to stress specific behaviours: 36 harder multi-step questions, 18 questions about facts that changed over time, and 12 questions about films. Every gold answer in my sets is computed or quoted by code from the corpus, never written by an LLM.

All three pipelines use Gemini 3.1 Flash-Lite and one TigerGraph Savanna graph that holds both the structure and the vectors:

RAG: vector search over 22,554 text chunks, then one LLM call.
GraphRAG: link the entities in the question to the graph, fetch the matching events and their neighbours, search vectors only inside those articles, then one LLM call.
Agentic GraphRAG: an orchestrator LLM plans the investigation one step at a time. It chooses one of 13 specialised agents (entity linking, graph traversal, multi-hop reasoning, GSQL aggregation, similarity search, document retrieval, fact history and others), reads what came back, and decides the next step. An evidence evaluator written in code decides whether it may stop.

Building the graph without an LLM

Most Olympic articles start with an infobox: venue, date, number of competitors, nations, and the gold, silver and bronze medallists. I parse these directly into Event, Games, Sport, Venue, Athlete and Nation vertices, and link each event to the same event at the previous and next Games. No tokens are spent on extraction, and no relationship is invented.

One rule mattered more than I expected: team names are split into individual athletes only when the split is certain. If an infobox lists a relay team without separators, no Athlete vertices are created at all. A guessed split creates people who never existed.

The agents reach the graph through the official TigerGraph MCP server. Every step in a trace records whether MCP served it.

The rule I cared about most: never release an unsupported answer

In a previous TigerGraph hackathon, the main feedback on our entry was that the LLM made up details and merged several items into one answer. So this time the safeguards live in code, not in the prompt. Before the agent may answer:

the whole answer must be supported by one cited evidence item;
every name and number in the answer must appear in that evidence (a count must equal the GSQL aggregate, not a number the LLM computed);
a silver medallist can never be released as the gold winner;
an answer that combines facts from two events is rejected.

A rejected answer goes back to the orchestrator with the reason. After two rejections the result is "unknown", never the rejected text. When several events match a question equally, the agent answers for one of them and the code attaches a note naming all the candidates.

Results

On the 100 public questions:

	RAG	GraphRAG	Agentic GraphRAG
Accuracy	47%	65%	99%
Tokens per question	3,116	2,364	3,095
Tokens per correct answer	6,629	3,638	3,126
Answers fully supported by one cited source	69	57	100

GraphRAG is the cheapest per question. The agent is the cheapest per correct answer, and it is the only pipeline whose every answer is backed by its evidence.

The more interesting view is by question type, because it shows where the agent earns its cost and where it does not.

Question type	RAG	GraphRAG	Agent	Verdict
Counting (21)	0%	29%	100%	Agent needed
"Held immediately before" (22)	64%	9%	100%	Agent needed
Single lookup (19)	63%	100%	100%	GraphRAG is enough, and cheaper
Venue and date (28)	64%	100%	96%	GraphRAG is enough, and cheaper
Superlatives (10)	30%	100%	100%	GraphRAG is enough, and cheaper

Counting is where LLM pipelines break. In 14 of GraphRAG's 15 misses on counting questions, every relevant event and its competitor count was already in its context. The LLM simply miscounted. The agent does not count in the LLM at all: it calls a GSQL aggregation and cites the result.

Hops through time need structure. For "who won the event at the Games held immediately before 2016", GraphRAG fetches the events of 2016, because that is the year named in the question, and the answer never reaches its context. The agent's multi-hop agent finds the 2016 event, follows the edge to the previous edition and answers from there, with evidence at each hop.

Where the agent is overkill

To test the other side, I wrote 12 questions about films. The corpus contains 546 film articles, but the graph only models Olympic events, and each question describes a film without naming it ("the 1995 film directed by Bryan Singer and starring Stephen Baldwin").

Films (12)	RAG	GraphRAG	Agent
Accuracy	100%	58%	100%
Tokens per question	2,684	3,218	7,002

Plain RAG is as accurate as the agent here, at under 40% of its tokens. When the answer sits in one article that a description can find, an agent is not worth it.

GraphRAG's 58% follows an exact pattern. It failed every question set in an Olympic year (1992, 2002, 2004) and answered every other one correctly. For "the 2002 film directed by Kunal Kohli", the only entity the graph recognises is the year, so it returns 40 events of the 2002 Winter Olympics and searches only those articles. The film can never be reached. In a non-Olympic year the graph finds nothing, GraphRAG falls back to searching everything, and it gets the answer. That is GraphRAG's blind spot: it trusts the graph's view of the question, which helps when the answer is in the graph and hurts when it is not.

Facts that change

The hackathon's stretch goal is reasoning over evolving and conflicting facts. Wikipedia has plenty: a weightlifter "originally won" and was later disqualified, or the infobox says 48 competitors while the article text says 47.

I extract each version of a fact with code and store it as a Claim vertex in TigerGraph, with a SUPERSEDES edge from a dated decision to the original result. The source policy is explicit: a dated change supersedes the original, the infobox is the current official record, and a disagreeing statement is reported, never dropped or averaged. On 18 such questions RAG scored 78%, GraphRAG 94% and the agent 100%. The agent reported both versions in all 5 count conflicts and flagged the change in all 13 questions where a result had changed.

Running everything twice

Before submitting, I ran every pipeline on every question a second time, independently. Out of 216 questions:

	Same answer in both runs
RAG	206
GraphRAG	191
Agentic GraphRAG	216

Most of GraphRAG's changes were counts: 8 in one run, 7 in the other, for the same question. The LLM counts differently each time. The agent's counts come from the graph, so they do not move. One question shows the conflict problem directly: for the 2016 men's triple jump, RAG answered 48 in one run and 47 in the other, GraphRAG did the opposite, and the agent answered 48, the official record, both times and reported the conflict.

What I learned

The answer to "do I need an agent?" is per question type. Counting, hops through time and multi-step chains need one. A single lookup or a single article found by description does not.
Put your guarantees in code. A prompt that says "do not merge events" is a hope. A check that rejects any answer citing two events is a guarantee.
Let the database do the arithmetic. Most of the accuracy gap on counting questions and most of the run-to-run instability came from the LLM counting.
Measure where your system is overkill, not just where it wins. The film questions were the most useful 12 questions in the project.

It still has limitations. The provided questions are templated and Olympic-heavy, my extra sets come from the same corpus, and the agent costs more per question than GraphRAG on simple lookups. The one question the agent missed (out of 100) is ambiguous in the corpus itself: three finals share the same venue and date. The agent answered for one of them and the code flagged all three, which I prefer to blending them into one answer.

The code, every trace, the hidden-set outputs and a dashboard with every question are in the repository.

Thanks to TigerGraph for the hackathon, the Savanna credits and the MCP server.

Built for the TigerGraph Agentic GraphRAG Hackathon.
Code, results and traces: github.com/nirmaljosephukken/olympicrag-agentic-graphrag ·
Live dashboard: nirmaljosephukken.github.io/olympicrag-agentic-graphrag/dashboard

The Agent That Knows When to Stop: Agentic Fraud Investigation on TigerGraph

Nirmal Joseph Ukken — Thu, 24 Sep 2026 09:22:08 +0000

Task #4 · TigerGraph problem statement · Hacker House Goa 2026

A risk score pings. Is it fraud, a holiday, or a new phone?

We built SentinelGraph, an AI agent that works the alert like a sharp analyst: it digs through the graph, admits what it doesn't know, asks for the one piece of evidence that would settle it, and recommends the next move with the right person signing off.

590,742 transactions in the graph · 5,565 closed cases as memory · 16 GSQL queries via MCP · 0.914 memory-model AUC (bank score: 0.866) · 28 cards in the biggest ring we found

🔗 Code: https://github.com/nirmaljosephukken/HH_GOA_Task_4

1. What we built

Fraud teams are never short of alerts. They're short of time to turn each one into a call they can defend. For every ping an analyst pulls the card history, checks the device, hunts for other victims, rereads the policy, decides whether to phone the customer, and writes it all up. Usually after the money has moved.

SentinelGraph runs that loop end to end:

Triggers: a bank risk score, a customer report, or an analyst request.
Investigates the card, the latent cardholder, devices, emails, regions and other cards through TigerGraph.
Remembers 5,565 closed investigations and every case it opened before.
Measures its own uncertainty and stops only when two independent lines of evidence agree.
Asks for more evidence through policy-approved actions (customer validation, step-up authentication, analyst review) when it isn't sure.
Recommends the next best action with its approval route (auto / L1 team lead / L2 fraud manager), drafts a SAR when policy requires one, and writes the whole case back into the graph.
SentinelGraph console (Streamlit) shows the alert, the live investigation, what it found, how certain it is, what happens next, the evidence graph, and why it stopped.

We ran it on the 20 benchmark alerts: 10 legitimate, 9 fraud, 1 uncertain, 6 SARs. Re-running all 20 gives the same decisions every time.

Reading the room first

The dataset is the IEEE-CIS card data with the fraud label taken away. In its place: a bank risk score, 5,565 closed investigations (July to October), a fraud policy, five documented patterns, and 20 alerts from November and December. Three findings shaped everything:

A "customer" isn't a person. Customer IDs come from an issuer code, so one card can hold 2,788 transactions across dozens of billing regions. We added a Client vertex: a latent cardholder built from card + billing region + account-open day. In closed cases, 85% of a fraud client's transactions are fraud.
The bank's memory is lopsided, and that's useful. All 4,665 confirmed frauds began with a cardholder report. All 900 cleared cases began with a model score the cardholder explained (travel 716, new phone 158, intended purchase 26). A risk score is a reason to look. Never a verdict.
Card IDs come back exactly. Ranking each customer's card6 values reproduces every card ID in the closed cases and the case pack.

2. The architecture

Every layer has one job. Graph queries find facts. A deterministic evidence layer weighs them. A policy engine picks the actions. The LLM probes open questions and writes the story, and it never sets a probability or an action.

Trigger (score / customer / analyst)
   │
   ▼
Case orchestrator ── state machine + audit trail ──────────────┐
   │  MCP: tigergraph__run_installed_query   GraphRAG: vectorSearch
   ▼                                                            │
TigerGraph Savanna (FraudGraph)                                 │
   │                                                            │
   ▼                                                            │
Evidence layer ── detectors → likelihood ratios by family       │
   ▼                                                            │
Uncertainty engine ── log-odds fusion, confidence, open questions
   ▼                                                            │
Policy engine ── R1–R10, case vs report, stop rule, routes, guardrails
   │                       │                                    │
   ▼                       ▼                                    │
ask for evidence     next best action (auto runs, L1/L2 wait)   │
(verify / step-up)         │                                    │
   └──► re-assess          ▼                                    │
                     FraudCase + CaseEvents written back ◄──────┘

LLM (Gemini): bounded extra tool calls + narrative/SAR writer, output validated

One alert, six moves:

Open the case with an audit trail.
Dig the graph: 16 installed GSQL queries through the TigerGraph MCP server, about 0.1 s each.
Remember: GraphRAG vector search over closed cases, earlier agent cases and policy clauses.
Weigh it: each finding gets a likelihood ratio and an evidence family (ml, trigger, sequence, network, device, behaviour, history, customer). Within a family only the strongest counts, so correlated signals can't pile up. Families multiply in log-odds.
Stop or ask: two independent families agree past 85% or 15%? Stop. Otherwise request the evidence that would settle it.
Act and write back: auto actions execute, L1/L2 actions wait for a human, the case goes back into the graph as memory.

3. How TigerGraph is used

One graph, three layers:

Evidence graph: Customer–Card–Client–Txn, with Txn linked to DeviceProfile, EmailDomain (purchaser and recipient) and BillingRegion, plus a NEXT_TXN chain per card.
Case memory: 5,565 ClosedCase vertices linked to their transactions, cards, connected cards and pattern. Every FraudCase the agent opens is stored too, with edges to the transactions, cards, devices and closed cases it used, and a CaseEvent chain as its audit trail.
Knowledge: PolicyChunk vertices, one per policy rule, plus fraud typologies, a FinCEN/FATF/FFIEC digest and lessons mined from closed cases.

ClosedCase, FraudCase and PolicyChunk carry TigerGraph's native 256-dimension vector attribute, so memory lookups are a vectorSearch() inside an installed query, right next to the graph hops.

Sixteen installed GSQL queries, each exposed to the agent as a tool. Highlights:

peer_txns: two hops, flagged transaction → its device or email → purchases on other cards at a similar amount within 48 hours. This is the "what happened on other cards?" question.
card_profile: a behavioural baseline in one pass with MapAccums over products, regions, devices and emails.
ring_components: weakly connected components (min-label propagation adapted from tg_wcc) over the client↔device co-usage graph. It isolates the 28-card ring as one component.
device_ring_scan and amount_band_scan: sweep the whole exam period, so the agent raises alerts nobody reported (monitor.py).
prior_cases and device_cases: memory by adjacency. Which closed cases touched this device?

TigerGraph MCP. The agent launches the official tigergraph-mcp server over stdio, discovers its tools, and calls tigergraph__run_installed_query for every read, vector searches included. Argument names come from the tool schema at runtime. If MCP is unavailable it falls back to RESTPP, and every call in the trace records which transport served it.

Loading. Streamed parallel RESTPP upserts loaded 590k transactions and about 3M edges into Savanna in under two minutes.

4. The agentic capabilities

Explicit uncertainty. Every detector returns a claim, the query it came from, the entity IDs it rests on, a likelihood ratio and a family. The case records the prior, the posterior, each family's contribution, which families argue each way, and the open questions ("device ownership not established", "evidence conflicts").

A calibrated prior learned from case memory. The closed cases cover about 3.4% of July to October transactions, close to the true fraud rate, so we trained a gradient-boosted model on them. Trained on July to September and tested on October: AUC 0.914 vs 0.866 for the bank's score, with nearly double the average precision.

Knowing when to stop. Policy section 6, as code: stop at ≥ 0.85 or ≤ 0.15 with two independent families agreeing. Otherwise the agent picks the evidence request that best resolves the case: step-up authentication for an online score alert, customer verification for a dispute, R7 verification for a disputed charge that matches the customer's own recurring pattern. Replies aren't provided in this round, so a simulator assumes the reply the evidence supports, records the assumption and its basis, and the agent re-assesses. The next best action is recorded before and after the evidence, with what changed.

Policy as code, with permissions. R1–R10, the case-vs-report rule, exposure-based routing, action ordering, and a guard that refuses breaches (blocking on a single weak signal, BLOCK_ALL_CARDS without two compromised cards, blocking a recurring dispute). Only auto actions execute. L1 and L2 actions wait in the console's approval queue, and every approval is written to the case's audit trail in TigerGraph.

Memory that changes the answer.

HHG-014: device_cases returns closed cases analysts labelled undocumented, so the agent labels the new ring undocumented too and escalates under R9.
HHG-006: vector retrieval surfaces five undocumented September structuring cases.
Legitimate alerts: cleared cases on the same card ("confirmed travel") are cited as precedent.

The LLM where language is the product. Gemini gets a bounded budget of extra tool calls to probe open questions, then writes the summary, pattern description and SAR narrative. Any text that cites an ID not present in the evidence is rejected. Its notes carry zero weight in the probability, which is why decisions are reproducible.

What the graph caught

HHG-006 · Threshold structuring. Four online purchases in 30 minutes, each just under $500 ($1,906.07 total). Same trick on 11 other cards; matches five undocumented September cases. SAR, R9 escalation.
HHG-014 · A 28-card device ring. One Samsung profile behind an anonymous proxy, marked New on every account. The November wave of the August ring.
HHG-019, HHG-011, HHG-016 · Rings you can't see from one card. Each purchase looks ordinary on its own card. On the graph, the same rare device made near-identical purchases on 3–5 other cards within days. R6: report and monitor connected cards.
HHG-018 · Disputed, but it recurs. A $39.08 charge recurring at the same amount, region and product since August. R7: verify and remind, no block.
HHG-003 · Honest about doubt. A denied $49 purchase in a region the card uses all the time. The card is blocked (R2), but the outcome stays uncertain and goes to an analyst (R8).

Scoreboard: all 20 alerts

Case	Outcome	P(fraud)	Pattern	Exposure	Linked cards	SAR	Evidence asked	Final next best action
HHG-001	legitimate	0.01	none	$0.00	0	no	none	`ALLOW_TRANSACTION` → `GENERATE_REPORT` → `CLOSE_NO_FRAUD`
HHG-002	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`
HHG-003	uncertain	0.63	out of region use	$49.00	0	no	customer validation	`BLOCK_CARD` → `CREATE_CASE` → `ESCALATE_TO_ANALYST`
HHG-004	fraud	0.73	card not present new device	$128.33	0	no	customer validation	`BLOCK_CARD` → `CREATE_CASE`
HHG-005	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`
HHG-006	fraud	0.99	undocumented	$1,906.07	11	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS` → `ESCALATE_TO_ANALYST`
HHG-007	legitimate	0.01	none	$0.00	0	no	none	`ALLOW_TRANSACTION` → `GENERATE_REPORT` → `CLOSE_NO_FRAUD`
HHG-008	fraud	0.99	card not present fraud	$166.97	1	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS`
HHG-009	fraud	0.98	card not present fraud	$30.02	0	no	none	`BLOCK_CARD` → `CREATE_CASE`
HHG-010	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`
HHG-011	fraud	0.95	card not present new device	$131.30	5	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS`
HHG-012	legitimate	0.01	none	$0.00	0	no	none	`ALLOW_TRANSACTION` → `GENERATE_REPORT` → `CLOSE_NO_FRAUD`
HHG-013	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`
HHG-014	fraud	0.89	undocumented	$439.61	27	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS` → `ESCALATE_TO_ANALYST`
HHG-015	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`
HHG-016	fraud	0.99	card not present new device	$59.67	3	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS`
HHG-017	legitimate	0.03	none	$0.00	0	no	none	`ALLOW_TRANSACTION` → `GENERATE_REPORT` → `CLOSE_NO_FRAUD`
HHG-018	legitimate	0.02	none	$0.00	0	no	customer validation	`CREATE_CASE` → `WARN_CUSTOMER` → `CLOSE_NO_FRAUD`
HHG-019	fraud	0.99	card not present new device	$99.92	4	yes	none	`BLOCK_CARD` → `CREATE_CASE` → `FILE_REPORT` → `MONITOR_CONNECTED_CARDS`
HHG-020	legitimate	0.01	none	$0.00	0	no	step up auth	`ALLOW_TRANSACTION` → `CREATE_CASE` → `CLOSE_NO_FRAUD`

5. What we learned

Schema design is investigation design. The Client vertex and the device fan-out query did more for accuracy than any model tuning.
Put the LLM where language is the product. When it computed probabilities, runs weren't repeatable. As a bounded prober and a validated writer, it helps without drifting.
"Uncertain" is an honest answer. When evidence disagrees, protect the customer now and let a human decide.
Graph memory beats flat memory. Retrieving past cases by adjacency (same device, same card) and by similarity (vectors) together caught things neither did alone.

6. What we'd improve with more time

Real reply channels (SMS, app push) instead of simulated replies, feeding outcomes back as training signal.
Streaming ingestion into TigerGraph with the ring and structuring scans running continuously.
Likelihood ratios learned from resolved agent cases instead of set by hand.
Louvain community detection over client↔device↔email to catch rings that share more than one element.
External enrichment (BIN/issuer, IP reputation) as additional evidence families.

Stack: TigerGraph Savanna · GSQL · TigerGraph MCP · native vector search · Python · Gemini · Streamlit

Built for Hacker House Goa 2026 with @TigerGraphDB. Code, the 20 answer files and full investigation traces: https://github.com/nirmaljosephukken/HH_GOA_Task_4