DEV Community: srinath thota

I Gave My AI Assistant a Memory — It Started Calling Out My Broken Promises

srinath thota — Tue, 29 Sep 2026 18:23:15 +0000

How I built Ahead, a Hindsight-powered pre-meeting agent that remembers what was promised, finds what is overdue, and turns context into action.

By Srinath

Most AI meeting assistants can summarize what just happened. Far fewer can answer the question that matters before the next meeting: what did I promise this person, and did I actually do it?

The best meeting brief is not the one with the most information. It is the one that prevents the next avoidable mistake.

A forgotten promise is more dangerous than a bad meeting

A meeting can go perfectly and still damage a relationship weeks later. The problem is usually not a dramatic failure. It is the technical document you said you would send by Friday. The pricing discussion you agreed to revisit next quarter. The introduction you promised to make and then forgot. Each item looks small in isolation, but together they decide whether a client sees you as reliable.

Most AI meeting assistants are good at summarizing what just happened. Far fewer can answer the more important question before the next meeting: what did I promise this person, and did I actually do it?

That gap led me to build Ahead, an AI pre-meeting briefing agent powered by Vectorize Hindsight. Its job is simple: know what matters before you meet — and never let the same promise be broken twice.

A fluent agenda is useless if it forgets the relationship

Ask a stateless assistant to prepare you for a meeting and it can produce a polished list of generic prompts: ask about priorities, understand the current stack, discuss next steps. The answer sounds professional, but it has no relationship-specific stakes.

In Ahead's seeded demo, Jordan Reyes has a history across several meetings. Pricing was intentionally postponed. An integration concern came up. Most importantly, a technical follow-up document was promised within 48 hours and was never sent.

A generic assistant does not know any of that. It prepares you as if you are meeting Jordan for the first time. Ahead instead leads with the overdue commitment, because that is the fact most likely to shape the conversation. The difference is not better wording. It is memory.

Design thesis: relationship context is valuable only when it changes what the user does next.

Ahead turns memory into a pre-meeting safety net

Ahead creates a dedicated Hindsight memory bank for each contact. Meeting notes, decisions, promises, and outcomes are retained as relationship history. When a user clicks Brief me, the app retrieves the most relevant evidence, checks for outstanding commitments, and generates a concise executive brief.

The brief is intentionally action-oriented. It can surface overdue promises that need to be acknowledged immediately, topics that were postponed and are now ready to revisit, a recommended opening for the first minute, and the raw memories behind every warning.

From the same screen, the user can draft an accountable follow-up email. Ahead does not hide behind corporate language; it restates what was promised and moves the user toward a concrete resolution. It can also create an account handoff brief for a new owner, combining relationship history, open commitments, client priorities, and a first-week action plan.

This changes the product from a passive summary tool into a follow-through system.

Retain, recall, reflect: a clean lifecycle for agent memory

Retain — store meetings, decisions, promises, dates, and outcomes as durable relationship history.
Recall — retrieve the evidence relevant to today's meeting, including unresolved actions and timing.
Reflect — reason across the full bank to produce strategic guidance and account handoffs.

The sequence matters: retain creates durable history, recall grounds the immediate answer, and reflect converts accumulated history into judgment. Groq then formats that grounded context into the final user-facing brief and follow-up actions.

The demo makes the value of memory visible

I wanted the difference between "AI with context" and "AI with memory" to be obvious, so Ahead presents them side by side.

Without memory: a polished but generic agenda — ask about priorities, the current stack, and next steps. It treats every interaction as day one.

With Hindsight: an evidence-backed brief that surfaces the overdue document, the postponed pricing discussion, and the right opening for the meeting.

In the Jordan demo, the most important item is impossible to miss: an overdue commitment appears in a high-priority callout. The brief also recommends addressing the missed document before moving to a new agenda.

Just as important, Ahead shows its work. The Memory Found inspector displays the raw recalled memories, while Why this brief? presents an audit trail: the earlier meeting, the promise, whether it was fulfilled, and why it matters now.

That transparency was deliberate. A relationship warning can change how someone opens a high-stakes conversation. Users should not have to trust an unexplained model output when the underlying evidence can be shown directly.

After the brief, Ahead connects memory to action. The user can generate a follow-up email, create a handoff brief, review a chronological meeting timeline, or open a dashboard that audits commitments across every contact bank. The product moves from one meeting to an organization-wide view of reliability.

Transparency is a feature. The model summarizes; the memory inspector preserves the source evidence.

The architecture stays deliberately small

Ahead is built as a single full-stack Next.js 14 application with TypeScript and route handlers. Hindsight is the long-term memory layer, and Groq is used for language-model synthesis. The current architecture does not require a separate application database for relationship memory.

Each contact has an isolated bank. API routes call Hindsight to retain new events, recall relevant facts, and reflect across history. The app then uses a language model to structure the result into sections such as overdue items, topics to revisit, strategic opening advice, and a relationship summary.

A critical implementation decision was to detect overdue commitments from recalled evidence before asking the language model to write the brief. The model helps synthesize and communicate; it is not treated as the source of truth. That separation makes the system easier to inspect and reduces the chance that a polished sentence is mistaken for a stored fact.

The application also handles failure explicitly. If memory or model services are unavailable, the interface reports the problem instead of silently inventing context. For a product built around trust, an honest error is better than a confident hallucination.

One contact, one memory boundary. Isolating every relationship in its own bank prevents unrelated histories from bleeding into each other and gives each retrieval a clear scope. The same pattern scales from an individual brief to a portfolio audit without losing provenance.

Useful memory must be scoped, inspectable, and tied to action

1. Memory needs boundaries. One bank per contact prevents unrelated histories from bleeding into each other and gives every retrieval a clear scope.

2. Memory needs provenance. Users should be able to inspect the event behind a summary. Timestamps, raw recalled text, and an explanation chain make the system accountable.

3. Memory should end in action. Follow-up drafts, opening advice, handoff plans, and the commitments dashboard turn a remembered promise into a next step.

4. The user must close the loop. Ahead can retain a new outcome and detect whether an older commitment was resolved. Without updates, even a sophisticated memory system becomes stale.

The bigger opportunity is organizational follow-through

Ahead began as a pre-meeting briefing tool, but the architecture points to a broader use case. Relationships survive team changes, account handoffs, and long gaps between conversations. The knowledge needed to protect them is usually scattered across notes, inboxes, and individual memory.

A shared, evidence-backed memory layer can make that history operational. A new account owner can see what matters in their first week. A manager can review commitments across a portfolio. A team can distinguish promises made by them from actions expected from the client. The goal is not to remember everything. It is to remember the obligations that shape trust.

That is the idea behind Ahead: the best meeting brief is not the one with the most information. It is the one that prevents the next avoidable mistake.

Know what matters before you meet. Never break a promise twice.

Live demo: https://ahead-u.vercel.app/
Source code: https://github.com/tsrinath2007/Ahead
Hindsight: https://github.com/vectorize-io/hindsight

TigerGraph Agentic Fraud Investigation Hackathon 2026 Team GOA-T

srinath thota — Fri, 25 Sep 2026 05:50:15 +0000

Team

Thota Sai Eswar Srinath — Team Leader & Agentic Architecture
Nikhil Kadiri — Graph Systems & TigerGraph Traversal Engineering
Bondugula Pranav Teja — Policy Engine & GraphRAG Implementation

Project Links

Live Cockpit: https://task-4-nvan.onrender.com/
GitHub Repository: https://github.com/tsrinath2007/Task-4
Benchmark Report: docs/BENCHMARK_REPORT.md
Demo Script: docs/DEMO_VIDEO_SCRIPT.md

A Fraud Score Isn't an Investigation

Modern fraud detection systems can assign a risk score to every transaction.

For example:

Transaction Risk Score: 0.87

But a risk score alone doesn't answer the questions an investigator actually needs:

Why is this transaction suspicious?
Has this card interacted with other suspicious accounts?
Is the device being used by multiple customers?
Has this device appeared in previous fraud cases?
Is this an unusual transaction or simply legitimate travel?
Is this a recurring subscription?
What action should the bank take?
Does the action require human approval?
Should a regulatory report be generated?

The problem becomes significantly harder when fraud is not isolated to one transaction.

A fraud ring might look like this:

Customer A
    |
  Card A
    |
Transaction
    |
 Device X
   / | \
  /  |  \
Card B Card C Card D
  |     |     |
 ...   ...   ...

A single suspicious transaction can therefore be connected to dozens or even hundreds of other entities.

This is where we saw an opportunity for graphs.

Introducing SENTINEL

We built SENTINEL, a graph-native autonomous fraud investigation system designed to investigate suspicious transactions using:

TigerGraph for multi-hop relationship analysis
Model Context Protocol (MCP) for live graph investigation tools
GraphRAG for historical case retrieval
Deterministic fraud detectors for explainable pattern detection
A deterministic policy engine for action and approval decisions
LLM synthesis for human-readable explanations and regulatory narratives
An interactive analyst cockpit for investigation and visualization

The key architectural principle was:

Let the graph gather evidence, let deterministic code enforce policy, and let the LLM explain the result.

The LLM is deliberately not allowed to decide whether a card should be blocked or which approval route should be assigned.

What We Built

SENTINEL is an end-to-end investigation system composed of eight major components:

Live TigerGraph Savanna Cloud + MCP Client
Hybrid GraphRAG Memory
Eight Deterministic Fraud Detectors
Legitimacy Checklist
Deterministic Policy Engine
Dynamic Next-Best Action Engine
LLM Synthesis Layer
Interactive Analyst Web Cockpit

Our evaluation used:

590,742 IEEE-CIS / Vesta transactions
5,565 closed historical cases
20 benchmark cases (HHG-001 → HHG-020)
A live TigerGraph graph containing approximately 1.45 million transaction vertices

The benchmark validation suite produced:

20 / 20 PASS
100% policy validation pass rate

The benchmark also covered both fraudulent and legitimate behavior, allowing us to test whether the system could avoid blindly treating every anomaly as fraud.

Architecture Overview

At a high level, SENTINEL follows this pipeline:

                    ┌───────────────────────┐
                    │      ALERT TRIGGER    │
                    │ Risk Score / Dispute  │
                    │ Analyst Escalation    │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   TIGERGRAPH + MCP    │
                    │                       │
                    │ Customer Cards        │
                    │ Card History          │
                    │ Shared Devices        │
                    │ Prior Cases           │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   EVIDENCE ENGINE     │
                    │                       │
                    │ 8 Fraud Detectors     │
                    │ Legitimacy Checks     │
                    │ GraphRAG Retrieval    │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │ DETERMINISTIC POLICY  │
                    │       ENGINE          │
                    │                       │
                    │ Rules R1 → R10        │
                    │ Approval Routing      │
                    │ Initial Actions       │
                    └───────────┬───────────┘
                                │
                       Evidence Required?
                          /           \
                        YES           NO
                         │             │
                         ▼             │
              ┌──────────────────┐    │
              │ Evidence Loop     │    │
              │                  │    │
              │ Customer Verify  │    │
              │ Step-up Auth     │    │
              └────────┬─────────┘    │
                       │              │
                       ▼              │
              ┌──────────────────┐    │
              │ Reassessment     │◄───┘
              │ decide_after_    │
              │ evidence()       │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ LLM Synthesis    │
              │                  │
              │ Explanation      │
              │ Case Summary     │
              │ SAR Narrative    │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ Persistence       │
              │                  │
              │ Case Vertex      │
              │ Audit JSON       │
              │ SAR XML          │
              │ Audit CSV        │
              └──────────────────┘

The important architectural boundary is between evidence, policy, and language generation.

Why We Chose a Graph

Traditional relational databases are excellent at structured transactional data.

Fraud investigation, however, often becomes a relationship problem.

Consider this investigation:

Transaction
     ↓
Device
     ↓
Other Cards
     ↓
Previous Transactions
     ↓
Previous Fraud Cases

The investigator is effectively asking:

"What else is connected to this transaction?"

That is naturally represented as a graph.

Instead of treating every transaction as an isolated row, SENTINEL models relationships between:

Customers
Cards
Transactions
Devices
Billing regions
Email domains
Historical cases

TigerGraph Data Model

Our live TigerGraph graph contains vertices including:

Customer
Card
Transaction
DeviceProfile
BillingRegion
EmailDomain
ClosedCase
Case

And relationships such as:

Customer
   └── OWNS ──> Card

Card
   └── MADE ──> Transaction

Transaction
   └── FROM_DEVICE ──> DeviceProfile

Transaction
   └── BILLED_IN ──> BillingRegion

Transaction
   └── PURCHASER_EMAIL ──> EmailDomain

Transaction
   └── NEXT ──> Transaction

ClosedCase
   └── ON_CARD ──> Card

ClosedCase
   └── INVOLVES ──> Transaction

Case
   ├── CASE_ON_CARD ──> Card
   ├── CASE_INVOLVES ──> Transaction
   └── CASE_CONNECTED_TO ──> Card

This lets an investigation move through the transaction network rather than querying isolated records.

Multi-Hop Fraud Investigation

One of our important graph traversals follows this pattern:

Transaction
      │
      │ FROM_DEVICE
      ▼
DeviceProfile
      │
      │ USED_ON
      ▼
Card
      │
      │ HAS_CLOSED_CASE
      ▼
ClosedCase

In GSQL:

CREATE OR REPLACE QUERY find_shared_device_ring(STRING txnId)
FOR GRAPH Transaction_Fraud {

    StartTxn = {Transaction.*};

    TargetTxn =
        SELECT t
        FROM StartTxn:t
        WHERE t.TransactionID == txnId;

    // Hop 1: Transaction → Device
    Dev =
        SELECT d
        FROM TargetTxn:t
        -(FROM_DEVICE:e)->
        DeviceProfile:d;

    // Hop 2: Device → Cards
    ConnectedCards =
        SELECT c
        FROM Dev:d
        -(USED_ON:e)->
        Card:c;

    // Hop 3: Cards → Previous Fraud Cases
    PriorFraud =
        SELECT cc
        FROM ConnectedCards:c
        -(HAS_CLOSED_CASE:e)->
        ClosedCase:cc
        WHERE cc.outcome == "fraud";

    PRINT
        ConnectedCards.size() AS syndicate_size,
        ConnectedCards,
        PriorFraud;
}

This traversal can expose relationships that are difficult to reason about when the investigation begins from a single transaction.

In our benchmark cases HHG-014 and HHG-017, the graph revealed device relationships connecting 299 distinct card accounts.

TigerGraph MCP

We didn't want the agent to directly manipulate the graph using arbitrary queries.

Instead, we exposed a controlled set of specialized investigation tools through MCP.

Our MCP client provides:

query_customer_cards(customer_id)

query_card_history(card_id, limit)

query_shared_devices(txn_id)

query_prior_cases(card_id)

write_case(case_data)

This creates a controlled interface between the agent and the graph.

Conceptually:

Agent
  │
  ├── query_card_history()
  │
  ├── query_shared_devices()
  │
  ├── query_prior_cases()
  │
  └── write_case()
  │
  ▼
TigerGraph

The agent doesn't need to understand the entire TigerGraph schema.

It only needs to know:

"I need the cards connected to this device."

The MCP tool handles the graph-specific implementation.

The Evidence Layer

After graph retrieval, SENTINEL runs deterministic detectors against the collected evidence.

We implemented eight primary detectors.

1. Recurring Merchant Detection

We look for repeated transactions with:

Similar merchant
Similar amount
Periodic intervals
Consistent historical behavior

For example:

Day 1    → $49.00
Day 30   → $49.00
Day 60   → $49.00
Day 90   → $49.00

A simplistic fraud detector might repeatedly flag these transactions.

Our detector can instead recognize the recurring pattern as potential legitimate subscription behavior.

2. Card Testing Detection

Card testing can produce small authorization attempts before a larger purchase.

For example:

$1.23
$2.11
$4.80
$7.42
$450.00

We look for rapid sequences of micro-authorizations followed by larger transactions.

3. Shared Device Detection

We investigate whether a device is associated with multiple cards.

For example:

Device D123
   ├── Card A
   ├── Card B
   ├── Card C
   ├── Card D
   └── Card E

A shared device alone does not prove fraud.

It becomes one piece of evidence that is combined with other signals.

4. New Device Detection

We determine whether the device is:

New to the customer
First seen in the customer's history
Previously associated with other suspicious activity

5. Out-of-Region Detection

We compare transaction regions against the cardholder's historical baseline.

We deliberately don't treat every out-of-region transaction as fraud.

For example:

Bengaluru
   ↓
Mumbai
   ↓
Delhi
   ↓
Bengaluru

may simply represent legitimate travel.

A single unexpected transaction combined with other anomalies can be more meaningful.

6. Card-Not-Present Burst Detection

We identify bursts of card-not-present transactions that significantly exceed historical transaction velocity.

7. Account Takeover Detection

We look for changes in digital identity signals such as:

Previous OS
Previous Browser
Previous Device
        ↓
Sudden change
        ↓
Transaction

Combined with additional identity inconsistencies, this can indicate possible account takeover activity.

8. Shared Region Detection

We identify clusters of otherwise unrelated cards originating from the same suspicious region or infrastructure.

Legitimacy Checklist

Fraud detection is not only about finding suspicious evidence.

It is also about finding evidence that explains why a transaction could be legitimate.

Our legitimacy checks consider patterns such as:

Recurring subscriptions
Historical merchant relationships
Consistent transaction amounts
Travel patterns
Customer history
Previously cleared disputes
Stable device behavior
Historical transaction velocity
Known customer behavior

This prevents the investigation engine from interpreting every anomaly as fraud.

GraphRAG: Combining Semantics With Structure

This was one of the most interesting parts of the project.

Traditional RAG primarily asks:

"Which previous cases sound similar to this case?"

Fraud investigation also needs to ask:

"Which previous cases are connected to the same entities?"

Those are different questions.

So we combined both.

Our Hybrid GraphRAG Pipeline

Historical cases are embedded using:

sentence-transformers/all-MiniLM-L6-v2

Each case becomes a 384-dimensional vector.

We then perform semantic similarity search.

At the same time, we query graph relationships.

Conceptually:

                    Historical Cases
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
      Semantic Search             Graph Search
             │                           │
             │                           │
             └─────────────┬─────────────┘
                           ▼
                    Relevance Fusion
                           │
                           ▼
                    Ranked Evidence

Cases that are graph-adjacent receive an additional priority boost.

Our implementation uses:

semantic_score + adjacency_boost

with an adjacency boost of:

+0.15

for relevant graph relationships.

This means a case isn't ranked highly merely because its text sounds similar.

It can also be ranked highly because it shares important graph structure.

Why Negative Evidence Matters

This was one of our biggest lessons.

Fraud systems naturally focus on confirmed fraud.

But investigators also need to know:

"Have we seen this behavior before and determined that it was legitimate?"

So we indexed historical cleared cases as well.

Our historical dataset contained:

5,565 closed historical cases

including approximately:

900 cleared cases

These became negative evidence.

For example, in benchmark case HHG-003, historical cleared cases such as CC-4922 and CC-4718 helped establish that recurring disputes associated with that merchant category had previously been resolved as legitimate billing behavior.

This is important because:

A good fraud investigation system should not only find reasons to say "fraud."

It should also find evidence that says:

"We've seen this before, and it was legitimate."

The Most Important Design Decision

The LLM Does Not Control Policy

One of our earliest architectural lessons was that giving an LLM complete control over security actions creates unnecessary risk.

An LLM can generate a convincing explanation.

That doesn't mean it should have authority to execute:

BLOCK_CARD
FILE_REPORT
BLOCK_ALL_CARDS

So we separated:

Reasoning

from:

Authority

The LLM can:

Summarize evidence
Explain detected patterns
Generate case narratives
Format regulatory narratives
Explain why a policy rule was triggered

The deterministic policy engine decides:

What action is allowed
Which approval level is required
Whether blocking is permitted
Whether a report should be filed

The architecture therefore becomes:

                  Evidence
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
   Policy Engine              LLM
          │                     │
          │                     │
      Authority             Explanation
          │                     │
          └──────────┬──────────┘
                     ▼
               Final Case

This separation became one of the defining design principles of SENTINEL.

Deterministic Policy Engine

Our policy engine contains rules R1–R10.

R1 — Weak Evidence

Weak isolated signals require additional verification rather than immediately blocking a card.

Weak Signal
    ↓
VERIFY_WITH_CUSTOMER
or
STEP_UP_AUTH

R2 — Customer Denial

If the customer denies the transaction:

Customer Denial
       ↓
BLOCK_CARD
       +
CREATE_CASE

If exposure exceeds the configured threshold or the transaction is connected to a fraud ring, escalation includes the required reporting route.

R3 — Customer Confirmation

If the customer confirms the transaction:

Customer Confirmation
       ↓
ALLOW_TRANSACTION
       +
CLOSE_NO_FRAUD

R4 — No Response

If the customer does not respond within the configured 24-hour window:

No Response
    ↓
MONITOR_CARD
    +
DECLINE_TRANSACTION

R5 — Card Testing

Card testing triggers additional protection:

Card Testing
    ↓
DECLINE_TRANSACTION
    +
STEP_UP_AUTH

R6 — Shared Origin

A sufficiently large shared-origin cluster triggers:

CREATE_CASE
+
FILE_REPORT
+
MONITOR_CONNECTED_CARDS

with the appropriate approval route.

R7 — Recurring Disputes

Recurring merchant disputes require verification.

Importantly:

Recurring Dispute
      ↓
VERIFY_WITH_CUSTOMER
      +
WARN_CUSTOMER

Blocking is prohibited by this rule.

R8 — Uncertain High-Exposure Cases

Uncertain cases above the configured exposure threshold are escalated to a human analyst.

R9 — Undocumented Patterns

Unknown patterns are escalated rather than silently handled.

R10 — Global Blocking

Blocking all connected cards is prohibited unless the required number of cards have independently confirmed fraud.

Approval Routing

Another important part of the policy layer is approval routing.

Actions can be assigned to:

AUTO
L1 — Lead
L2 — Manager

For example:

BLOCK_CARD
    ↓
L1 approval

and:

FILE_REPORT
    ↓
L2 approval

This prevents the model from simply saying:

"This looks dangerous. Block everything."

Instead, the system must follow the defined authorization hierarchy.

The Agent State Machine

SENTINEL is not a single LLM prompt.

It is an investigation state machine.

1. TRIGGER
      ↓
2. INVESTIGATE
      ↓
3. GATHER_EVIDENCE
      ↓
4. ASSESS_UNCERTAINTY
      ↓
5. GATHER_MORE_EVIDENCE
      ↓
6. REASSESS
      ↓
7. RECOMMEND_ACTION
      ↓
8. UPDATE_CASE_MEMORY

Each state has a specific responsibility.

This makes the system easier to debug and audit than an open-ended agent loop.

Dynamic Next-Best Action

A particularly important feature is that the recommended action can change after new evidence arrives.

Consider:

Initial Investigation
        ↓
VERIFY_WITH_CUSTOMER

The customer then denies the transaction.

The system reassesses:

Customer Denial
        ↓
BLOCK_CARD
        +
CREATE_CASE
        +
MONITOR_CONNECTED_CARDS

The system also records:

what_changed

This creates an audit trail explaining why the action changed.

The goal is not simply:

"What did the system decide?"

but:

"What evidence caused the system to change its decision?"

Stopping Rule

Autonomous systems need to know when to stop.

Otherwise an agent can continuously gather evidence without improving the decision.

SENTINEL stops when one of the configured stopping conditions is met.

For example:

Fraud probability ≥ 0.85

or:

Fraud probability ≤ 0.15

provided sufficient independent evidence exists.

Other stopping conditions include:

Customer verification settles the dispute
Authentication settles the transaction
Additional graph traversal cannot change the permitted policy action

This turns investigation into a bounded process rather than an open-ended agent loop.

LLM Synthesis Layer

Once the deterministic investigation is complete, the LLM is used for synthesis.

We used:

Groq
LLaMA 3.3 70B

for:

Executive case summaries
Evidence explanations
Policy-rule explanations
FinCEN SAR narrative generation

The important architectural boundary remains:

LLM
  ↓
Explanation

Policy Engine
  ↓
Authority

If the LLM produces an explanation that doesn't match the deterministic evidence, the explanation can be regenerated without changing the underlying policy decision.

Interactive Analyst Cockpit

We also built an interactive web cockpit for investigators.

The dashboard includes:

Fraud case overview
Live graph visualization
Multi-hop relationship exploration
Evidence timeline
Next-best-action display
Watchlist management
SAR generation
Audit logs
CSV exports
AI Copilot
Live MCP investigation

The cockpit is available at:

https://task-4-nvan.onrender.com/

Live MCP Investigation

The MCP investigation modal allows an analyst or evaluator to select a case and execute the complete investigation against the live TigerGraph environment.

The pipeline becomes:

Case
 ↓
MCP Tools
 ↓
TigerGraph
 ↓
Evidence
 ↓
Policy Engine
 ↓
LLM Explanation
 ↓
Case Write-back

The fast-path investigation completed in approximately 1.2 seconds in our benchmark environment.

This is a project runtime measurement, not a production SLA.

Benchmark: 20 Ground-Truth Cases

We evaluated SENTINEL against 20 benchmark cases:

HHG-001 → HHG-020

Our validation suite produced:

20 / 20 PASS

The benchmark included both fraudulent and legitimate cases.

Complete Benchmark Results

Case	Trigger	Verdict	Fraud Probability	Primary Pattern	Exposure	SAR	Validation
HHG-001	Risk Score 0.61	Legitimate	0.07	None / Recurring	$77.07	No	PASS
HHG-002	Risk Score 0.79	Fraud	0.95	CNP Fraud	$292.36	No	PASS
HHG-003	Customer Report	Legitimate	0.07	None / Recurring	$49.00	No	PASS
HHG-004	Customer Report	Fraud	0.90	Card Testing	$55.89	Yes	PASS
HHG-005	Risk Score 0.54	Fraud	0.94	CNP New Device	$100.07	Yes	PASS
HHG-006	Customer Report	Fraud	0.93	Card Testing	$1,906.07	Yes	PASS
HHG-007	Risk Score 0.87	Legitimate	0.08	None / Subscription	$111.92	No	PASS
HHG-008	Customer Report	Legitimate	0.07	None / Recurring	$55.68	No	PASS
HHG-009	Customer Report	Fraud	0.95	CNP New Device	$30.02	Yes	PASS
HHG-010	Risk Score 0.90	Fraud	0.96	CNP New Device	$1,000.03	Yes	PASS
HHG-011	Customer Report	Legitimate	0.08	None / Recurring	$131.30	No	PASS
HHG-012	Risk Score 0.55	Legitimate	0.07	None / Recurring	$30.91	No	PASS
HHG-013	Risk Score 0.76	Fraud	0.95	CNP New Device	$35.66	Yes	PASS
HHG-014	Analyst Request	Fraud	0.95	CNP New Device	$74.96	Yes	PASS
HHG-015	Risk Score 0.77	Fraud	0.92	CNP New Device	$599.94	Yes	PASS
HHG-016	Customer Report	Fraud	0.94	CNP New Device	$59.67	Yes	PASS
HHG-017	Risk Score 0.57	Fraud	0.93	Card Testing	$300.14	Yes	PASS
HHG-018	Customer Report	Legitimate	0.07	None / Recurring	$39.08	No	PASS
HHG-019	Risk Score 0.90	Fraud	0.91	CNP New Device	$99.92	Yes	PASS
HHG-020	Risk Score 0.52	Fraud	0.95	CNP New Device	$125.08	Yes	PASS

Aggregate Benchmark Metrics

Metric	Result
Benchmark Cases	20
Validation Pass Rate	20 / 20 — 100%
Fraud Cases	13
Legitimate Cases	7
Regulatory Filings	12
Dynamic Policy Progression	20 / 20
Total Fraud Exposure Managed	$5,174.77
Average Fraud Probability — Fraud Cases	93.5%
Average Fraud Probability — Legitimate Cases	7.3%
Live Fast-Path Investigation	~1.2 seconds

These are results from our project benchmark and should not be interpreted as production fraud-detection performance.

Benchmark Examples

HHG-003 — Legitimate Recurring Behavior

The system identified recurring transaction behavior and retrieved historical cleared cases with similar patterns.

Result:

Verdict:
Legitimate

Fraud Probability:
0.07

Final Actions:
ALLOW_TRANSACTION
CLOSE_NO_FRAUD

This case demonstrated why negative evidence matters.

HHG-017 — Card Testing

The system detected a card-testing pattern.

Result:

Verdict:
Fraud

Fraud Probability:
0.93

Primary Pattern:
card_testing

The system updated its recommended actions after evidence evaluation.

HHG-014 — Shared Device Network

The investigation exposed a large connected-card structure through graph traversal.

The important evidence wasn't isolated to the transaction itself.

It came from:

Transaction
    ↓
Device
    ↓
Multiple Cards
    ↓
Historical Cases

This is exactly the type of relationship that motivated the graph-native architecture.

What We Learned

1. Policy and Reasoning Should Be Separated

Our biggest architectural lesson was simple:

Don't give an LLM authority just because it can reason about the problem.

The model is useful for language and synthesis.

The policy engine is better suited for deterministic authorization.

2. Negative Evidence Is Extremely Valuable

A fraud system that only remembers fraud can become biased toward finding fraud.

Cleared historical cases provide an important counterweight.

They answer:

"Have we seen this pattern before and cleared it?"

3. Graph Context Improves Retrieval

Semantic similarity answers:

"What sounds similar?"

Graph adjacency answers:

"What is connected?"

Combining both gives us a richer retrieval signal.

4. Agentic Does Not Mean Uncontrolled

We initially thought of an agent as something that could freely decide which actions to execute.

Our final architecture was different.

The agent has freedom to:

Investigate
Retrieve
Compare
Request evidence
Reassess
Explain

But it operates inside deterministic boundaries for:

Policy
Approval
Actions
Auditability

That distinction became one of the most important design principles of SENTINEL.

Engineering Challenges

Deterministic Card Reconstruction

The source transaction dataset required deterministic reconstruction of card relationships from partially masked identifiers.

The ordering of missing and sequential card identifiers mattered for maintaining consistent mappings across the dataset.

This was not a glamorous problem, but it was critical.

Small preprocessing inconsistencies can propagate into:

Card Mapping
      ↓
Graph Relationships
      ↓
Fraud Detection
      ↓
Benchmark Results

Deterministic preprocessing therefore became part of the investigation pipeline rather than a separate data-cleaning concern.

Asynchronous UI Orchestration

The frontend initially relied on independent timers and asynchronous operations.

That introduced race conditions.

For example:

Graph Loading
       ↓
Evidence Animation
       ↓
Policy Result
       ↓
Case Write-back

could appear out of order.

We replaced this with sequential asynchronous orchestration so each stage completed before the next stage began.

The result was a much more predictable investigation experience.

What We Would Build Next

1. Graph Neural Networks

We would investigate GCN/RGCN-based models for learning structural fraud representations directly from the transaction graph.

The goal would be to complement deterministic detectors with learned graph-level features.

2. Real-Time Streaming

A production-oriented version could integrate streaming ingestion such as Kafka:

Transaction Stream
        ↓
Kafka
        ↓
TigerGraph
        ↓
Investigation Agent
        ↓
Policy Engine

This would allow investigations to begin immediately after authorization events.

3. Human Approval Webhooks

L1 and L2 reviewers could receive actionable notifications through systems such as Slack or Microsoft Teams.

For example:

Fraud Investigation

Exposure: $1,906
Connected Cards: 299
Required Approval: L2

[Review Case]
[Approve]
[Reject]

This would connect the autonomous investigation pipeline with real human governance.

4. Regulatory Submission Integration

The current system can generate structured regulatory output.

A future implementation could integrate directly with an appropriate regulatory filing environment after the necessary security, compliance, authorization, and certification requirements are satisfied.

Project Structure

A simplified view of the implementation:

Task-4/
│
├── src/
│   ├── agent/
│   │   ├── orchestrator.py
│   │   └── llm_adapter.py
│   │
│   ├── graph/
│   │   └── mcp_client.py
│   │
│   ├── detectors/
│   │   └── ...
│   │
│   ├── memory/
│   │   └── retriever.py
│   │
│   └── policy/
│       └── policy_engine.py
│
├── cases/
│   └── generated/
│
├── scripts/
│   ├── embed_cases.py
│   └── validate_answers.py
│
├── docs/
│   ├── BENCHMARK_REPORT.md
│   └── DEMO_VIDEO_SCRIPT.md
│
└── README.md

Reproducibility

The project source code and implementation are available here:

GitHub:

https://github.com/tsrinath2007/Task-4

The live investigation cockpit is available here:

SENTINEL Cockpit:

https://task-4-nvan.onrender.com/

The benchmark validation can be reproduced using the project's validation tooling:

python scripts/validate_answers.py

Hackathon Rubric Alignment

The architecture was designed to address the major evaluation dimensions of the hackathon.

Rubric Category	Weight	How SENTINEL Addresses It	Evidence
Investigation Accuracy	25%	8 deterministic detectors + legitimacy checklist	`src/detectors/`, generated cases
Next Best Action	25%	Pre-evidence and post-evidence action gating	`src/policy/policy_engine.py`
Case Summary & Explainability	10%	LLM synthesis, policy explanations, SAR narratives	`src/agent/llm_adapter.py`
Agentic Design & Engineering	15%	8-stage state machine + MCP + graph write-back	`src/agent/orchestrator.py`
Innovation	15%	GraphRAG + adjacency boost + negative evidence	`src/memory/retriever.py`
Demo Quality	10%	Interactive cockpit + graph visualization + MCP modal	Live cockpit

The benchmark validation suite produced:

20 / 20 PASS

Key Takeaways

Building SENTINEL taught us that autonomous fraud investigation isn't simply about adding an LLM to a fraud detector.

The more interesting engineering problem is combining several different forms of intelligence:

                    SENTINEL
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
     GRAPH          RULES          MEMORY
   TigerGraph     Policy Engine    GraphRAG
        │              │              │
        └──────────────┼──────────────┘
                       │
                       ▼
                    AGENT
                       │
                       ▼
                  LLM SYNTHESIS
                       │
                       ▼
                HUMAN-READABLE
                  EXPLANATION

The graph provides relationships.

The detectors provide evidence.

GraphRAG provides historical context.

The policy engine provides authority.

The agent provides orchestration.

The LLM provides explanation.

That separation is what makes SENTINEL more than a chatbot sitting on top of a database.

Conclusion

Fraud rarely exists as a single suspicious transaction.

It exists as a network.

A device connects cards.

Cards connect transactions.

Transactions connect customers, regions, merchants, and historical cases.

That is why we built SENTINEL around a graph.

Our goal was not to create an LLM that simply says:

"This looks like fraud."

We wanted to build an investigation system that can answer:

What happened?

What is connected to it?

What evidence supports the conclusion?

What historical cases are relevant?

What policy permits us to do next?

And why did the recommended action change?

The resulting architecture combines TigerGraph, MCP, GraphRAG, deterministic policy enforcement, agentic orchestration, and LLM synthesis into a single investigation workflow.

And most importantly, we learned that in high-impact systems:

Agentic doesn't have to mean uncontrolled.

The most useful autonomous systems may be the ones where the model has enough freedom to investigate—but enough constraints to remain auditable and predictable.

Built by Team GOA-T

Thota Sai Eswar Srinath

Team Leader & Agentic Architecture

Nikhil Kadiri

Graph Systems & TigerGraph Traversal Engineering

Bondugula Pranav Teja

Policy Engine & GraphRAG Implementation

Project Links

🚀 Live Cockpit:

https://task-4-nvan.onrender.com/

💻 GitHub Repository:

https://github.com/tsrinath2007/Task-4

SENTINEL — Investigate the transaction. Understand the network. Enforce the policy.