Safe Signal

Inspiration

A convincing voice should not be enough to earn your trust.

Call filtering helps before a phone rings. We wanted to explore what protection could look like after someone answers when a caller creates urgency, demands secrecy, or asks for a verification code.

Safe Signal focuses on what the caller asks you to do, not whether their voice sounds human.

Our idea: when a suspicious call gets through, give the person answering a clear reason to pause.

What it does

Safe Signal is a web prototype of a carrier-side, in-call warning experience, not an app that can intercept cellular calls.

Interactive call demo: Answer a synthetic bank, tech-support, or delivery call. Hear the audio and watch the prepared transcript appear during playback.
Explainable risk signals: A rules baseline flags patterns such as verification-code requests, secrecy, gift-card payments, remote-access software, and arrest threats. Evidence cards show the phrases behind each warning.
A clear interruption: At the high-risk threshold, the demo displays “Scam Likely. Hang up.” During synthetic playback, it lowers the caller recording’s volume.
Optional microphone mode: With explicit consent, browser speech recognition can transcribe a spoken sample and send the recognized text to our backend for rule scoring.
Try your own message: Type a sample instead of relying only on our prepared scenarios. This text is checked by the rules baseline, not sent to NVIDIA.
Family-safety guidance: The warning offers a family code-word prompt and a trusted-contact alert preview. These are simulations; no message is sent.
Separate consent for investigation and sharing: Optional cloud investigation and responder escalation require separate permission. Escalation shares only the synthetic scenario title and risk labels not the transcript or phone number.

The recorded-call warning also shows an estimated timing relative to a code request. This is a playback estimate, not proof that we consistently detect scams before someone acts.

How we built it

Frontend: React, JavaScript, Vite, and CSS power the phone interface, transcript reveal, risk meter, warning controls, and consent flows.

Audio: We authored synthetic scenarios and created caller clips with ElevenLabs. The interface identifies playback provenance and supports browser text-to-speech as a fallback. Recorded scenarios use prepared transcripts; their playback is not live speech-to-text.

Live transcription: The optional microphone mode uses the browser’s SpeechRecognition API. The browser’s speech provider may process microphone audio; our app receives recognized text for scoring rather than uploading raw microphone audio to our backend.

Backend: Python and FastAPI expose scoring, investigation, and escalation endpoints. SQLAlchemy supports local SQLite storage or a configured PostgreSQL/Tiger Data connection.

Optional AI investigation: We implemented a bounded NVIDIA Nemotron tool-calling workflow with allowlisted lookup tools. Lookup results are synthetic fixtures, not live reputation intelligence. A labeled rules-only fallback keeps the demo usable without hosted model access.

Testing: We added regression coverage for 20 scam-style messages, benign warnings, mixed messages, consent boundaries, and input limits. Backend tests and the frontend production build pass.

Challenges we ran into

Building beyond a mockup: We explored the visual design in Lovable, then implemented the working React interface and connected it to audio and backend endpoints.
Learning the development workflow: For one teammate, this was their first experience with VS Code, terminals, virtual environments, and Git.
Keeping collaboration moving: A teammate’s GitHub account suspension interrupted pushes. ZIP files and Git patches helped us continue exchanging work.
Avoiding false positives: “We will never ask for your code” should not be treated like a demand for that code. Adding context checks exposed how brittle simple phrase matching can be.
Staying honest: We removed claims about detecting AI voices and distinguished simulated behavior from real integrations.

Accomplishments that we're proud of

We connected the call interface, audio playback, visible evidence, and warning actions into one coherent demonstration.

We also moved beyond fixed scenarios by adding custom-message scoring and an optional microphone workflow. Consent is explicit, and the interface explains what information goes where.

Most importantly, we built a demo that shows both the idea’s potential and its current limitations.

What we learned

An understandable warning needs more than a red meter: people need evidence and a practical next step.

We learned how React and FastAPI communicate, how to coordinate changes through Git, and how much work separates a visual prototype from a connected application.

We also learned that passing hand-written examples is not the same as validating a detector. A natural-sounding voice can be malicious, and a synthetic voice can be legitimate.

What's next for Safe Signal

Evaluate detection on separate, held-out scam and legitimate examples, reporting precision, recall, and false-positive rates.
Improve contextual language analysis beyond phrase rules.
Test live microphone recognition across supported browsers and verify the hosted Nemotron and Tiger Data integrations.
Replace synthetic lookup fixtures with trustworthy evidence sources.
Add individual responder accounts, scoped permissions, and independently verifiable audit records.
Explore supported carrier or VoIP integrations for real in-call protection.

Today, Safe Signal does not analyze voice authenticity, provide a validated fraud probability, control cellular calls, or send real trusted-contact alerts. Live speech recognition and hosted integrations still require end-to-end verification.