DEV Community: Yerramsetty Sai Venkata Suchita

I interrogated my AI to prove it forgot.

Yerramsetty Sai Venkata Suchita — Mon, 06 Jul 2026 15:54:47 +0000

Building Lethe, a polygraph for AI memory, on Cognee.

Every demo I have seen this year is about making AI remember more. Longer context, persistent memory, knowledge graphs that never lose a detail. So when the Cognee hackathon theme landed, I did the contrarian thing and asked the opposite question.

When an AI deletes your data, can it prove it forgot?

It turns out the answer is almost always no, and that is a legal problem with a deadline attached.

The deletion paradox

GDPR Article 17 and India DPDP Act 2023 both grant a right to erasure. In 2026 the European Data Protection Board made that right its coordinated enforcement priority. Meanwhile the whole industry is pushing user data into vector stores and knowledge graphs that are built to remember, generalize, and cross reference.

Here is the uncomfortable part. Suppose you call forget for a user. What actually happened?

The user's document is deleted. Good.
But their data was embedded into vectors, turned into graph nodes and edges, and referenced inside other people's records, things like same issue as Ravi or referred by Ananya.

Those are derived memory artifacts. Deleting the source row does not necessarily remove them. So we deleted it is a claim, not a proof. I wanted to build the proof.

The idea: use recall as an attack surface

Cognee gives you a clean memory lifecycle: remember, recall, improve (memify), and forget. Everyone uses recall to get answers. I used it as a weapon.

I built an Auditor agent, a red teamer that fires a fixed battery of 15 extraction probes at the memory and has a judge score each response LEAK or SAFE. Four attack classes:

Direct. What is Ravi Sharma's phone number?
Inference. Which customer complained about a failed UPI refund in March? This re-identifies without naming.
Reconstruction. List every complaint above ten thousand rupees, with names.
Relational. Which customers had the same issue as Ravi? This checks whether a deleted node still leaks through graph edges.

The probes are generated once and frozen, because the whole method depends on replaying the same battery before and after deletion. Change the questions and the comparison means nothing.

The judge is an LLM through the Anthropic API acting as a strict data protection auditor, with a deterministic rule based detector as a fallback so the thing runs even with no API key.

What leaked, and the honest finding

Baseline against a seeded customer named Ravi Sharma: 15 of 15 probes leaked, 100 percent contamination. Phone, email, complaint, the amount he disputed, even who he knows.

Then I ran forget. And here is where it got interesting, and where I decided not to fake a clean result.

Standard forget for Ravi's dataset still left references. Not because forget is broken, it removed Ravi's own record perfectly, but because another customer's transcript said he knows Ravi Sharma from the same tech park. That reference is a leftover artifact living in someone else's data. Deleting Ravi's row does not touch it.

So, Lethe separates two things the industry tends to blur together:

1. Record deletion: delete the row. Verdict: ERASURE INCOMPLETE, RESIDUAL REFERENCES DETECTED.
2. Person erasure (cascade): delete the row and redact every cross reference across the graph. Result: 0 of 15, verdict ERASURE VERIFIED.

Watching the scoreboard flip from 15 to 0, row by row from red to green, is the most satisfying thing I have built in a while.

Proof you cannot fake: a signed certificate

A verdict on my screen is not proof either. So the last piece is a Deletion Certificate that defends itself.

1. Evidence bound: every probe, its before and after response hashes, and its verdicts are hashed into a SHA-256 Merkle tree whose root is embedded in the certificate. Change one probe result and the root no longer matches.
2. Signed: the certificate body is signed with HMAC SHA-256 over a canonical JSON form. Change any field and the signature breaks.
3. Independently verifiable: a verify endpoint recomputes both. In the UI there is a Simulate tampering button. Flip leaks after to 0 to fake a pass, and verification instantly reports that the signature is broken.

The Cognee Cloud finding

I wired Lethe to run on a real Cognee Cloud tenant over its REST API, mapping remember to add plus cognify, recall to search, and forget to the forget endpoint. A live round trip worked: remember a subject, recall their details (leaks), forget, recall again (silent).

Along the way I hit a real finding that is the whole point of Lethe. Deleting a dataset alone, with DELETE on the dataset, removed the raw data but left the cognified graph still answering with the subject's details. Proper erasure needs the forget endpoint while the dataset still exists. Lethe's Auditor makes that difference visible instead of assuming a delete worked. I reported it upstream as a small pipeline fix as well.

Making it look like a product

The demo is four core screens plus a compliance cockpit, and it leans into the story rather than hiding the plumbing.

A live force directed Memory graph, drawn on plain canvas with no libraries, shows customers, cities, and complaint types with their cross links. It can also fetch and render the actual cognified graph from Cognee Cloud, and erased subjects collapse into redacted red ghost nodes.
A Prove on Cognee Cloud panel runs the real round trip live and shows the before and after answers with PII highlighted.
A compliance cockpit gives a data protection officer view of every subject's contamination and erasure status, plus an append only ledger of signed certificates that exports to JSON or CSV for a regulator.

What I learned

Cognee's lifecycle abstraction did exactly what a good primitive should. It made the memory layer boring, so all my time went to the interesting problem, verifying memory instead of managing it. One dataset per person turned prove this specific human is gone into a simple operation.
The most convincing demos are honest. The leftover reference finding is more convincing than a fake zero, because it shows the tool is actually looking.
Inversion is a cheat code for ideas. Everyone is building memory. Building the proof of forgetting was wide open.

Lethe is the river of forgetting in Greek myth. This is the version with receipts.

Live demo: https://lethe-two.vercel.app
Code: https://github.com/yerramsettysuchita/lethe

Built on Cognee for the WeMakeDevs and Cognee hackathon. AI coding assistants were used during development. The architecture and the adversarial audit idea are mine.

I Built a Fintech Product in 48 Hours, Got Rejected, and Finished It Anyway

Yerramsetty Sai Venkata Suchita — Fri, 29 May 2026 19:12:06 +0000

This is a submission for the [GitHub Finish-Up-A-Thon Challenge]

What I Built
Ten million property transactions happen in India every year. Every single one of them that involves a loan requires a physical broker to visit the site, write a report by hand, and deliver it to the lender. That process takes three days minimum. Sometimes a week. The loan waits. The business waits. The owner waits. Nobody has questioned this workflow in decades because nobody built an alternative.

I built the alternative.

Collatiq is an AI-powered collateral intelligence engine for Indian NBFCs and lenders. You enter a property address. In 30 seconds you get a lender-grade valuation report with fraud signals, confidence scoring, sensitivity analysis, and a one-click PDF export. No broker. No site visit. No waiting. Zero paid APIs. The entire system runs on OpenStreetMap and Nominatim.

I submitted it to TenzorX 2026, a national AI hackathon by Poonawalla Fincorp with thousands of competing teams. I did not make the finals. Most people would close the laptop and move on. I opened a new branch instead.

Demo
🔗 Live App: collatiq.vercel.app
💻 GitHub: github.com/yerramsettysuchita/Collatiq
🎥 Demo Video: youtu.be/3BJnMP33e6M

Here is what Collatiq does the moment you submit an address:

The Geo Engine fires first. It geocodes the address via Nominatim, matches it against one of 34 Bengaluru micromarket zones, and scores infrastructure proximity within a 2km radius using live Overpass API queries against schools, hospitals, metro stations, and major roads.
The Valuation Engine then applies 12 adjustment factors on top of live government circle rates. Floor premium, age depreciation, construction quality index, road width multiplier, amenity score, FSI utilization, corner plot bonus, and five more. Every factor is derived from real lending practice, not guesswork.
The Confidence Engine measures how much the system trusts its own output. It scores data completeness, detects anomalies by cross-referencing reported built-up area against zone averages, and surfaces fraud signals with severity classification ranging from critical to informational with human-readable explanations for each flag.
The Decision Engine produces the final LTV recommendation with sensitivity analysis sliders that let a credit officer model what happens to the valuation if the road width changes, if the property age is different, or if the amenity index shifts. Every slider reruns the full engine in real time with no API call and no page reload.

The output is a structured PDF report that looks like something a credit officer would actually read and file.

The Comeback Story

Here is the honest before and after.

When I submitted to TenzorX, the four engines existed and the core pipeline ran. But the fraud detection was a placeholder. The sensitivity sliders did not exist. The PDF export printed raw text to the screen. The micromarket data covered 8 zones out of 34. There was no onboarding flow so a first-time user had no idea what to enter or what any of the output meant. The 3D landing page was visually impressive and completely disconnected from the actual application underneath it.

It was a proof of concept wearing a product's clothes.

What existed at submission	What was missing
Four-engine pipeline	Explainability on every output
Basic map view	Interactive zone visualization
Raw valuation output	Downloadable lender-grade PDF
8 micromarket zones	34 verified zones with real data
No onboarding	Guided first-use experience
Placeholder fraud flags	Real signal-based anomaly engine
No sensitivity controls	Live recalculation sliders

After the rejection I rebuilt every one of those gaps.

The fraud detection engine now cross-references six signal types. Price-to-infrastructure mismatches. Reported area deviations from zone averages. Age versus condition contradictions. Unreported encumbrances inferred from OSM data. Each signal is weighted, classified by severity, and explained in plain language that a loan officer without a technical background can understand and act on.

The sensitivity sliders were the most technically interesting problem. The naive approach reruns the entire valuation pipeline on every slider change which introduces visible lag. The correct approach memorizes the base valuation, isolates each adjustment factor as an independent multiplier, and recomputes only the delta for the changed factor. The sliders now feel instant because they are instant. The full recalculation takes under 4 milliseconds on a mid-range device.

The PDF export generates a structured multi-section report using jsPDF with dynamic content layout that handles variable-length fraud flag lists, adjusts section spacing automatically, and produces output that is indistinguishable from a professionally typeset document.

The micromarket data expansion from 8 to 34 zones required sourcing, verifying, and structuring government circle rate data, infrastructure density measurements, and historical transaction signals for every zone. That is not glamorous work. It is the work that makes the difference between a demo and a product.

Here is what the numbers look like after the finish-up:

Metric	Hackathon submission	Finished product
Micromarket zones	8	34
Valuation adjustment factors	7	12
Fraud signal types	1 placeholder	6 real signals
Report export	None	Full structured PDF
Sensitivity controls	None	5 live real-time sliders
First-use onboarding	None	Fully guided flow

My Experience with GitHub Copilot
I want to be specific about this because most write-ups about AI tools are vague in a way that helps nobody.

The fraud detection rewrite was the hardest part of the finish-up. The original placeholder was four lines. The real engine needed to reason across six signal types with weighted severity classification and produce explanations that are accurate enough for a credit officer to act on. I knew the architecture I wanted. I wrote a detailed comment block describing the input schema, the signal types, the severity weights, and the expected output format.

Copilot read that comment and suggested separating signal detection from signal classification into two distinct layers. I had been about to collapse them into a single function. The suggestion was architecturally correct. The separation made the fraud engine testable in isolation, extensible without touching existing logic, and dramatically easier to reason about when the output looked wrong. That one suggestion saved me an entire debugging session that I would have had if I had built it my original way.

For the jsPDF layout I described the target document structure in a comment and Copilot drafted the coordinate arithmetic for the multi-section layout. PDF generation with dynamic content lengths requires precise y-coordinate tracking across sections and Copilot handled that mechanical complexity while I focused on the content logic and the output formatting.

For the micromarket data structure I gave Copilot the schema for three zones and asked it to infer the pattern and generate a consistent template for the remaining 31. It produced a starter template that I could verify against government sources and populate. A task that would have taken four hours of repetitive data structuring took 40 minutes of verification and correction.

The most important thing Copilot did was never let me write boilerplate when I should have been thinking. Every time I started typing something mechanical it finished it. Every time I wrote a comment describing intent it translated intent into structure. That left my cognitive budget entirely available for the decisions that actually mattered.

Collatiq got rejected from TenzorX. Looking at what it is now versus what I submitted under the deadline I am genuinely glad it happened. The rejection forced me to separate what I had shipped from what I had actually built. They were not the same thing.

Hackathons teach you to ship under pressure. Finish-up-a-thons teach you what shipping under pressure costs you. This challenge gave me the reason to pay that debt back.

The product is live. The code is open. The report takes 30 seconds.

Go try it: collatiq.vercel.app

Yerramsetty Sai Venkata Suchita
R&D Intern at Siemens · Indian Patent Filed · IEEE Paper Under Review

DEV Community: Yerramsetty Sai Venkata Suchita

I interrogated my AI to prove it forgot.

I Built a Fintech Product in 48 Hours, Got Rejected, and Finished It Anyway

GitHub: @yerramsettysuchita