Inspector

• 

  inspector

Inspiration

A strange transaction isn't always fraud. It can be an advance payment, a refund, or a legitimate business relationship. We were inspired to build a tool that could investigate those differences and answer one essential question: "What evidence supports this conclusion?"

We wanted to combine the speed of artificial intelligence with verifiable results, without delegating accusations to a language model.

What it does

Inspector turns financial datasets into traceable investigations. It accepts SQLite, CSV, XLSX, or ZIP files, identifies their structure, and normalizes the data for analysis.

The engine looks for signals of shell vendors, improper reimbursements to employees, money circulation, purchase splitting, and revenue inflation. Every finding must cite existing records and reconcile their amounts.

Two AI agents then complement the investigation: one challenges the results, and the other explores a sample of entities with no flagged signals. Their observations don't automatically change the engine's conclusions.

Users can explore findings, review dismissals, trace money movements, and download a case file with evidence, limitations, and execution metrics.

Key features

The standout feature is Inspector's self-learning system. As the engine investigates each entity, it doesn't just apply a fixed set of fraud heuristics — it builds and refines a logical model of how money legitimately moves through the organization: which relationships are expected, which explanations recur, and which patterns genuinely deviate from that baseline.

That self-learning loop is what let us generate a genuinely complex logical model, one far richer than a static rulebook. Instead of flagging transactions against hardcoded thresholds, the system continuously incorporates confirmed explanations and prior findings, so its notion of "normal" gets sharper with every case it reviews. This is also what makes the distinction between a real fraud scheme and an incidental relationship possible at scale: the model has enough accumulated context to tell them apart, while still requiring every conclusion to cite verifiable records.

Other features that stood out:

• Multi-format ingestion (SQLite, CSV, XLSX, ZIP) with automatic structure recognition, even across inconsistent column names and date formats.
• Five fraud-pattern detectors — shell vendors, improper employee reimbursements, money circulation, purchase splitting, and revenue inflation — each producing evidence-backed, reconciled findings.
• Dual AI cross-examination: one agent challenges findings, another explores unflagged entities, without either one silently overriding the engine's conclusions.
• Visible dismissals: the system shows why an entity was NOT flagged, not just why one was.
• A fully reconstructible, self-contained case file (evidence, limitations, execution metrics) that doesn't require re-querying the model to regenerate.

How we built it

We built the interface with Next.js, React, TypeScript, and Tailwind CSS. We used Supabase and PostgreSQL for application data, and Python with SQLite for the investigation engine.

We split the process into stages: ingestion and normalization, detection, investigation, AI cross-examination, and case file generation. We integrated Codex CLI for the agents' reviews, with bounded context, JSON contracts, and tool restrictions.

Before publishing the report, we run validations on format, references, and reconciliation. We store inputs and results so the case file can be reconstructed without querying the model again.

Challenges we ran into

One of the biggest challenges was accepting data that didn't share column names, date formats, or accounting conventions. We had to recognize structures and declare when there wasn't enough information to investigate.

It was also difficult to distinguish incidental relationships from real evidence. Sharing a bank or having one unusual transaction isn't enough to accuse. We built in alternative explanations and validations before issuing findings.

Another challenge was correctly representing the money trail — preserving movements and avoiding double-counting an invoice and its payment as separate losses.

Finally, we had to separate the engine's reproducibility from the AI's variability: a new review can change, while the saved case file must be reconstructible.

A major challenge beyond the technical work was adapting our ideas into a solution that was actually applicable to real cases — one that was profitable and functional enough to be viable, and that could generate real impact above everything else. It's easy to build something technically interesting; making it something an auditor could rely on, and that made business sense to run, meant constantly cutting features and reshaping the product around what would actually work in practice.

Accomplishments that we're proud of

We achieved a complete flow: upload a dataset, run the investigation, cross-examine it with AI, and deliver a verifiable case file.

In our final synthetic evaluation with five seeds not used to tune that version, the engine detected 24 of 25 schemes and did not accuse any of the 50 decoys. These results describe that evaluation only and don't guarantee performance on any dataset.

We're also proud that dismissals became a visible part of the output. Showing why we did NOT flag an entity is just as important as justifying a finding.

What we learned

We learned that a useful investigation needs explicit boundaries. When data is missing, the right answer can be to declare insufficient evidence.

AI adds value by challenging interpretations and raising new questions, while calculations, references, and validation rules need deterministic controls.

We also learned to separate what we measure: passing the delivery format doesn't prove accuracy, and reconciling amounts doesn't mean every scheme was found.

What's next for Inspector

We want to expand the evaluation with independent datasets, improve recognition of unfamiliar structures, and reduce missed cases without increasing false accusations.

We also aim to broaden agent coverage, deepen the analysis of intermediaries, and make it easier for humans to review additional hypotheses.

The next stage is testing Inspector with audit professionals and turning their feedback into measurable improvements.

Additional information for judges and organizers

Inspector combines a deterministic engine with an AI cross-examination layer. The engine runs the main investigation with the LLM disabled; the agents receive results and bounded samples to challenge them and explore hypotheses.

The delivery includes submission.json and a self-contained HTML case file. Before publishing, we check the official format, dataset references, amount reconciliation, and reconstruction from the saved artifacts.

The engine's final evaluation achieved 24/25 schemes detected and 0/50 decoys accused on synthetic data. This does not represent a guarantee of generalization. Agent coverage is limited by sampling; a new AI run may vary. The MXN cost attributable to the subscription used is undetermined and is not presented as zero.

Built With

• next.js
• postgresql
• python
• react
• sqlite
• supabase
• tailwind
• typescript