Damage Control AI

A confident wrong answer is worse than an honest "I don't know." Damage Control AI checks images and voices for AI, proves your own work is untouched, and tells you when it can't be sure.

Comment

Damage Control AI

Four possible patent ideas, implemented.

A forensics tool for people who need to know what's real.

Inspiration

Look anywhere online right now and you cannot be sure what you are looking at.

A photograph of a place that has never existed. A video of a person saying words they never said. A voice note from someone you love, asking for money, in their voice, with their pauses and their laugh — generated from thirty seconds of a story they posted last week.

It is not one medium. It is all of them at once, and it happened faster than anyone's instincts adapted. The old advice — look at the hands, look at the ears, listen for the flatness — stopped working about two years ago. A screenshot can end someone's reputation in a group chat before anyone thinks to ask whether it is real. A marketplace listing, a dating profile, a news image, an invoice: any of them can now be manufactured by someone with a free tool and ten minutes.

What is actually being lost is originality itself — the ordinary, unremarkable assumption that a thing you made is a thing you made, and a thing you are looking at came from somewhere real. That assumption underwrote a lot more than we realised.

We started building Damage Control AI because there was nowhere for an ordinary person to take a suspicious file. There are excellent forensic tools for newsrooms and law enforcement. There was almost nothing for the person holding the phone at 11pm, deciding whether to send the money.

And when we watched what people actually do — paste it into a chatbot and ask "is this fake?" — we found the deeper problem. You get a fluent, confident sentence. Sometimes it is right. It sounds exactly the same when it is wrong.

That became the thesis:

A confident wrong answer is worse than an honest "I don't know."

What it does

Damage Control AI is a forensics tool you bring files to. Not a monitoring service — you upload, it analyses, it tells you what it found.

  • AI Fraud Scan — upload an image, get a read on whether it shows signs of AI generation or manipulation.
  • AI Audio Scan — check whether a voice clip sounds AI-generated. Note the distinction: we check whether audio was generated, never whose voice it is. No voiceprints. No biometric data.
  • Authenticity Check — read C2PA Content Credentials where they exist and surface a file's origin and edit history.
  • Proof-of-Original — register your own file and get a tamper-evident, timestamped cryptographic record that it existed, unaltered, at that moment.
  • AI Identity Map — a manual case file. You record the sightings. We don't crawl for them.

The thing that ties it together: DC AI has three answers where most tools have two. Signs detected. Credentials found. Can't tell — and here's why. That third state is the product.

The clearest example is a file with no Content Credentials. Most platforms strip C2PA manifests on upload, so absence tells you almost nothing — they could have been removed in transit, or never written at all. From the file alone there is no honest way to distinguish those two cases. So we don't. We say that, in those words.

We are equally explicit about what we did not build: no internet crawling, no account monitoring, no facial recognition, no voice recognition, no biometric data collected or stored. Nothing is analysed until you upload it yourself, and deleting your account permanently erases your files and results.

How we built it

What we originally set out to build

The first scope was not a scanner. It was a full personal identity-defence platform, designed across four pillars.

Face Vault — a zero-knowledge biometric wallet. Enrol your likeness once. Convert the face to a vector embedding, discard the raw image immediately, store only an opaque reference. Suspect content then gets matched vector-to-vector — never against a raw biometric — so the system could tell you someone is using your face without ever holding a photograph of you. Cross-person composites flagged as multi-person manipulation.

Voice Vault — real-time voice clone detection. The audio equivalent: a consented voice reference, a live detection path with a visible latency timer, and a consent record for every enrolled sample.

Viral Propagation Graph. When a fake is confirmed, trace it. Model content, URLs and accounts as graph nodes with repost and time edges, reconstruct the spread, surface the earliest known instance.

Generational Watermark Lineage. Every protected asset gets a watermark and a cryptographic chain node. Re-watermark a derivative and it becomes a child committed to its parent's hash — a verifiable family tree of a file across every generation of edit and repost.

We built the data models. We wrote the vendor adapters. We specified the hash construction down to the byte separator. Then two walls — one legal, one technical — reshaped the whole thing.

The architecture we ended up with

Node.js and Postgres, with row-level security on every owned table, org-scoped from the first migration.

A single lineageHash.js module owns canonicalisation, hash computation and chain verification, so the write path and the verify path can never diverge. That is one module by deliberate design, not by accident — two implementations of a canonical serialisation are two implementations that will eventually disagree.

Detection providers sit behind vendor adapters, so no single provider is load-bearing and any of them can be swapped without touching the domain logic. Cross-org isolation tests were written before the features they protect.

The chain itself lives in a dedicated lineage_chain_nodes table with every invariant enforced as NOT NULL, append-only via a database trigger, and no API anywhere that can create or modify a parent link after the fact. The link is computed inside the same transaction that creates the node — never asserted afterwards. That absence is a security property.

Challenges we ran into

The legal wall

Biometric identifiers — face embeddings, voiceprints — are among the most heavily regulated categories of personal data that exist.

Under GDPR they are special-category data, with a materially higher bar for lawful processing. Illinois' Biometric Information Privacy Act carries a private right of action, meaning individuals can sue directly, and it has produced some of the largest privacy settlements on record. Texas and Washington run their own regimes. India's DPDP Act and the frameworks in the Philippines, Australia and New Zealand each add their own requirements.

DC AI is live in five countries. A biometric vault would have needed, in every one of them: a defensible lawful basis, jurisdiction-specific consent flows, published retention and destruction schedules, deletion guarantees we could technically prove, and — critically — counsel sign-off before a single face was enrolled.

We could not get that approval inside our window. Not because the design was wrong; the zero-knowledge architecture existed specifically to minimise exposure. But "we discard the raw image" is a claim you must be able to prove to a regulator, and proving it properly is a compliance programme, not a sprint.

So we made the call and removed biometrics entirely — deleting working design work on two of our four pillars. It was the hardest decision of the project.

The technical walls

The legal wall was the one that made headlines internally. The technical ones were harder to look at.

Our "cryptographic" chain wasn't cryptographic. The original lineage design stored an original hash and a watermarked hash side by side and called the pair a cryptographic link. It wasn't. There was no commitment. Anyone with database access — an attacker, a buggy migration, a careless admin — could rewrite a parent pointer and every verification would still pass. The word "cryptographic" was doing no work at all. We found it in our own spec and rewrote the whole thing.

A commitment does not fit inside a watermark. A watermark payload that survives lossy transport is small, and the robust deep-learning methods sit at the bottom of that range. A SHA-256 commitment is 256 bits by itself, before any node identifier or metadata:

$$ \text{payload}_{\text{robust}} \in [32,\ 256]\ \text{bits} \qquad \text{vs} \qquad |\,\text{SHA-256}\,| = 256\ \text{bits} $$

There is no way to fit a full chain link into the artifact. So the chain lives in our records and the watermark carries only an opaque identifier that resolves into it — and we say so in the UI, because the alternative is implying the artifact proves itself. It doesn't.

Watermark decoders are probabilistic, and hash chains are brittle. Decoders don't guarantee perfect recovery even with no attack applied; the widely-used libraries say so outright. But a hash chain fails completely on a single flipped bit. A chain that must survive a lossy channel needs error correction, fuzzy matching, or a fundamentally different commitment scheme. We have not solved that.

Gap detection is unsolved. Someone screenshots generation 2 and reposts it as what is effectively generation 5. We cannot currently detect the missing generations, or order what remains.

Patient-zero attribution wasn't accurate enough to be honest. Automated first-source inference on a propagation graph lands nowhere near defensible for a takedown or a filing. A user-verified node with a URL and a timestamp is. We cut the automated version and kept the verified one.

Two silent chain-killers we nearly shipped. Postgres timestamptz and JavaScript's Date.toISOString() disagree on precision by default, and UUID casing is not guaranteed consistent between layers. Either would have produced hashes that verified on write and failed on read — corrupting every chain ever written, invisibly.

We also over-engineered the storage. The propagation graph was specced on Neo4j. At roughly 50 nodes per investigation, that is not a graph-database problem — it is a WITH RECURSIVE query. A second datastore was pure deadline risk for zero benefit. We moved it to Postgres.

Time - got to know about the challange on 29th June 2026

Idea scoping started - 29th June 2026 Development Started - 6th July 2026 Development Completed - 11th August 2026 Marketed for 6 days

Accomplishments that we're proud of

Four ideas we believe have patent potential

To be precise about what these are: these are four ideas we believe have patent potential. None of them is a granted patent. Nothing here has been examined, allowed, or issued by any patent office. They are novel methods we designed and, in three of four cases, built — and they are what we would take to a patent attorney to assess.

We state this plainly because a project whose thesis is don't claim more than you can support cannot overclaim its own IP.

# Idea Status Why
P001 Generational Watermark Lineage ✅ Implemented Shipped in full
P002 Zero-Knowledge Biometric Vault ❌ Designed, not shipped Blocked on biometric law
P003 Viral Propagation Graph ⚠️ Reduced Automated attribution removed as indefensible
P004 Real-Time Voice Clone Detection ⚠️ Reduced Detection shipped; consented vault blocked

What we learned

"Cryptographic" is a word that has to earn its place. Finding our own fake commitment — before a judge did — was the most valuable hour of the entire build. We now have a rule: if you cannot answer "what happens if I edit that row?" with a specific failure mode, the word comes out of the copy.

Ask the compliance question on day one. The legal answer that killed two pillars was available in week one. We asked in week six. Every hour of biometric design work after that point was spent on something that was never going to ship in this timeline.

A brittle guarantee across a lossy channel is a research problem, not a sprint task. Watermark payload budgets, bit-error tolerance and gap detection are not implementation details we skipped — they are open problems. Naming them precisely turned out to be more persuasive than pretending they were solved.

Match the datastore to the actual scale, not to the impressive-sounding architecture. Neo4j was a decision about how the system would sound, not how it would behave at 50 nodes.

Canonical serialisation is the most dangerous code in a cryptographic system. Not the hash function — the bytes you feed it. The failure mode is silent and total.

Scoping down is a design act, not a retreat. The version we shipped is more coherent than the version we planned, because removing biometrics removed every temptation to drift into being a monitoring product. Constraints we resented in June became the positioning we lead with now.

Saying "we can't tell" is harder than building the thing that can't tell. It is genuinely difficult to write uncertainty into a product when every competitor's screen says something confident, and when confidence demos better. We wrote a claims-guardrail document — no accuracy percentages, no court-admissibility claims, no implying Proof-of-Original establishes authorship or ownership — and we have killed our own copy against it more than once.

Built With

Share this project:

Updates