CaseLens Review evidence Made-up information

About this project

Why I built CaseLens

I built CaseLens to explore how a reviewer handles missing or conflicting evidence.

A result is easier to read when the screen also explains what information produced it. I wanted to make that connection visible, especially when a report arrives late and changes the result.

Try the demo

One case, before and after

A rule checks a set of conditions. This example checks whether the device is unrecognized, the locations differ, and there are at least five attempts. The complete copy meets all three conditions, so its result is Matched. These results describe the example rule; they don't approve or reject a payment.

The copy you review starts with its device report missing. A snapshot is a saved copy of the evidence at one step. Here's what happens as you review that copy and add the missing report.

Complete copyAll three conditions matchMatched
  1. 01

    The device report is missing

    Device MissingLocations differ YesAttempts 5
    Indeterminate

    That means the available evidence cannot tell us whether the rule matches.

  2. 02

    You save a review

    "The device report is missing. Request the original observation."
    Attached to the missing-report copy

    The note keeps the evidence and indeterminate result you saw when you wrote it.

  3. 03

    The report arrives

    Device UnrecognizedLocations differ YesAttempts 5
    Matched

    CaseLens saves a new copy with the report. All three conditions now match.

The earlier review stays linkedYour note Missing-report copy Indeterminate result
The late report changes the new copy. Open the earlier review and you'll still see the missing evidence that explains its result.

The connection to Canonical

Canonical Labs works on fraud investigations and rules engineering. Its Shield product adds device, network and session observations to payment data. That made evidence review a useful subject for this project: how should the screen explain a result when some of those observations are missing or disagree?

Stripe Radar already documents missing-value conditions such as is_missing(...) and rule testing against historical payments. CaseLens explores a particular review interaction. I built it independently using public product information and synthetic cases; it has no connection to Canonical's systems.

What I chose to build

The screen puts the complete evidence beside the version you're reviewing. Each condition explains its result and points back to its source observations. You can change the evidence and return to an earlier snapshot.

I kept the demo to twelve synthetic cases and three example conditions so you can follow the reasoning. The conditions illustrate evidence handling; they aren't a tested fraud policy. The tradeoff is deliberate: this project lets you inspect a small review workflow in detail, but it doesn't measure fraud detection accuracy.

For developers

A separate TypeScript evaluator applies the same rules to the same evidence every time. It uses the snapshot's saved evaluation time, so an old example won't change just because you open it tomorrow. SQLite stores the snapshots and review notes.

The interface uses Svelte. The evaluator runs separately from the screen so its evidence rules can be tested directly.