ANGLE MORT: Sentinel

An evidence-first Android companion linking listings, physical products, barcode scans and official recall data — without turning unknowns into safety claims.

Comment

Inspiration

Online transactions often create a dangerous gap between what a person is shown, what they physically receive, and what the available evidence can actually establish.

A marketplace listing can look convincing. A message can create urgency. A product can arrive looking exactly as expected. And an official recall record may still apply only to a specific model, variant, lot, or date range.

The central problem is therefore not simply detecting something suspicious.

It is preserving the boundary between:

  • what was observed;
  • what an official source says;
  • what can actually be linked to the physical item;
  • and what remains unknown.

That led us to a simple principle:

UNKNOWN ≠ SAFE

ANGLE MORT: Sentinel was built around that principle.

The product has evolved from a simple text-risk detector into a consumer evidence companion that can work across several entry points:

  • analyze written content locally;
  • use a listing link to recognize a supported platform or identifier;
  • scan the physical product that actually arrived;
  • compare the scanned identifier with available official recall evidence;
  • show what the evidence establishes — and what it does not.

The goal is not to replace the user's judgment.

The goal is to give the user better evidence before money changes hands or before a product is trusted.

What it does

Analyze written content

Sentinel can analyze text locally for focused risk-signal families such as:

  • PAYMENT
  • URGENCY
  • OFF-PLATFORM

The result is not a probability score and not a verdict.

Sentinel can show:

  • Signals — what patterns were detected;
  • Evidence — the text that triggered them;
  • Unknowns — what cannot be established from the available evidence;
  • Checklist — practical points for the user to verify.

A lack of detected signals is never presented as proof that a transaction is safe.

Use a listing link

Sentinel can accept a listing link and recognize supported platform and identifier information within the limits of the link-processing path.

Importantly, Sentinel does not claim to have read or analyzed the full marketplace page when the underlying path only establishes the address or a bounded identifier.

A recognized platform or identifier is therefore treated as an observation, not as proof of product identity or product safety.

Scan what arrives

The product experience then moves from the digital reference to the physical object.

The user can scan the product barcode with the Android camera.

This is a real device interaction, not a simulated barcode input.

The scanner establishes what was physically read by the device. It does not by itself establish that a particular unit is affected by a recall.

Follow official recall evidence

Sentinel can compare a scanned identifier against a bounded local snapshot of official French RappelConso recall data.

The current recall corpus used by the mobile experience is:

  • a limited local snapshot;
  • France-focused;
  • not a live service;
  • not exhaustive;
  • not global.

It must therefore never be presented as complete US recall coverage.

When a relevant record is found, Sentinel shows the documentary evidence and keeps applicability limits visible.

A GTIN match is not automatically the same thing as an affected physical unit.

Model, variant, lot and other applicability questions remain separate whenever the available evidence does not establish them.

The important case: no match

One of the most important states in Sentinel is not a positive match.

It is:

NO MATCH IN CURRENT CORPUS

This does not mean:

  • no recall exists anywhere;
  • the product is safe;
  • the product is certified;
  • there is nothing else to investigate.

It means only that the available corpus and query did not establish a matching record.

That distinction is deliberate.

When the evidence does not establish a conclusion, the interface preserves the uncertainty instead of inventing reassurance.

Evidence before confidence

Sentinel is designed around a simple separation:

SOURCE SAYS

versus

SENTINEL CAN ESTABLISH

An official source can be authoritative about its own record without proving that every physical unit in front of the user is affected.

Likewise:

  • a listing is not the physical product;
  • a barcode is not the affected unit;
  • a GTIN match is not automatically a lot match;
  • no match is not safe;
  • historical information is not automatically current authority.

The interface is designed to make those boundaries visible.

Privacy by architecture

The safety path is local-first.

The written-content analysis shown in the product does not require the user's private message to be sent to an external AI service for analysis.

The current bounded recall lookup is also available locally from the embedded corpus used by the mobile experience.

This architecture reflects the product philosophy:

the system should not need to upload private conversational content merely to help a person inspect the evidence available on their device.

How we built it

ANGLE MORT: Sentinel is an Android application built around a deterministic processing core.

The Android execution path includes:

Android WebView → JavaScript → Kotlin → embedded Python → structured result → Kotlin → JavaScript → UI

Python is embedded on Android using Chaquopy.

The architecture deliberately separates:

Evidence / safety plane

  • user input;
  • observations;
  • identifiers;
  • evidence;
  • unknowns;
  • applicability limits;
  • next actions.

Commerce plane

Purchases and premium access are kept conceptually separate from the evidence authority.

The commerce layer must never decide whether an item, message or transaction is suspicious, safe, recalled or not recalled.

Challenges we ran into

The hardest challenge was not detecting signals or matching identifiers.

It was preventing the product from overstating what those signals proved.

We repeatedly tested cases where a tempting implementation could have turned:

  • “no signal” into “safe”;
  • a GTIN match into “affected unit”;
  • or a missing record into “no recall.”

That required adversarial testing, real-device validation, and repeated UI changes so that uncertainty remained visible instead of being hidden behind a reassuring result.

Accomplishments that we're proud of

We are especially proud that Sentinel can reach a useful answer without pretending to know more than the evidence supports.

The Android flow was tested on a real Samsung Galaxy S21 FE running Android 16 / API 36.

The physical barcode scanner was tested on the real device.

A real scanned product produced:

  • physical barcode provenance;
  • a valid embedded corpus;
  • a successful query;
  • NO MATCH IN CURRENT CORPUS.

The system explicitly did not interpret that result as safe.

Most importantly, NO MATCH remains an informative state — not a safety verdict.

Testing on a real device

The current product was validated on a real Samsung Galaxy S21 FE running Android 16 / API 36.

The physical barcode scanner was tested on the real device.

A real scanned product produced:

  • physical barcode provenance;
  • a valid embedded corpus;
  • a successful query;
  • NO MATCH IN CURRENT CORPUS.

The system explicitly did not interpret that result as safe.

This was important because the test was designed to demonstrate not only what Sentinel can find, but also how it behaves when the evidence does not establish a conclusion.

What we learned

The hardest part was not making software display an alert.

The harder problem was preventing the interface from saying more than the evidence supports.

We learned that:

No signal detected ≠ safe

and:

No recall match in the available corpus ≠ no recall

and:

Official record ≠ proof that the physical unit is affected

Those distinctions became product behavior, not just documentation.

What we deliberately do not claim

Sentinel does not claim to:

  • certify products;
  • certify transactions;
  • determine that a seller is a scammer;
  • provide complete worldwide recall coverage;
  • provide complete US recall coverage from the current corpus;
  • prove that a physical unit is affected merely because its GTIN matches a record;
  • turn a missing result into a safe result.

The product is deliberately smaller than an oracle.

It is designed to make the available evidence easier to inspect without hiding what remains unknown.

What's next

The next evolution is to expand official-source coverage while preserving the same evidence boundaries.

The long-term product direction is:

MESSAGE → LISTING → PHYSICAL PRODUCT → SCAN → OFFICIAL SOURCE → MATCH / PARTIAL / UNKNOWN → CONTINUITY

The principle remains unchanged:

**Follow the evidence.
Preserve the unknown.
Let the user decide

Built With

Share this project:

Updates

Submission history