Review 4 of 6: Scoring model, calibration, false positives, scam domain knowledge

Reviewer lens: does the two-ledger log-odds + decision-table design produce verdicts that are right, explainable, and stable? Are the reason codes grounded in how US smishing actually looks in 2024–2026?

Companion artifacts (all in this folder):

• golden-corpus.json: 42 cases. Each has expected_verdict, must_include_codes, must_not_include_codes, expected_codes_full, and reference_scores.
• tools/score.py: a reference implementation of the scoring rules in §1.5 (priors, family caps, decision table). It is the spec the Kotlin core must match.
• tools/detect.py: a reference implementation of every detector in §2, in stdlib Python. Its regexes are canonical. The ones in the markdown tables below escape | as \| and are for reading only.
• tools/corpus.py runs the detectors on the raw message text and thread context, then scores what they emit. It also diffs the emitted codes against expected_codes_full, checks must_not_include_codes, and checks the verdict. Run it with python3 tools/corpus.py. Current result: 0 verdict mismatches, 0 code diffs, 42 cases. The first detector pass found real false positives, including a bank alert's merchant descriptor "BESTBUY.COM" parsed as a link and tripping BRAND_DOMAIN_MISMATCH. Those were fixed in the rules and are written up in §2.

---

0. Bottom line

The architecture is right: two ledgers, reason codes with published weights, and a decision table instead of a single threshold. Keep it. It has five defects that will cause real misclassifications, and each one is fixable in a line or two of spec:

1. Correlated codes are double-counted. A toll smish fires brand, urgency, fee, payment, link and TLD codes all at once, and naive summing treats correlated evidence as independent. Fix: group codes into families with caps, or take the max within a family.
2. The prior must depend on sender kind. As drafted, UNKNOWN_SENDER is both the base rate and a weighted risk code, so it counts twice. Fix: pick the prior by sender kind (contact / short code / toll-free / long code / email gateway / international), and make UNKNOWN_SENDER weight 0, kept only for the explanation.
3. Claims in the message text can reach Likely legitimate. Under draft rule 5, a scammer typing "This is Carlos from your building" earns context points. Fix: Likely legitimate requires at least one hard (attacker-uncontrollable) code.
4. Gate order hides tripwires. "completeness < 40 → Cannot assess" runs first, so a visible "send me the code" in a half-redacted preview gets swallowed. Fix: tripwires run on whatever text is visible, before the completeness gate.
5. Several tripwires are false-positive-prone as worded. Three examples:

• "Request to share a code" fires on every real 2FA text that says "never share this code".
• "Gift card" fires on Target promos.
• "Brand ≠ link domain" fires on every dentist that uses Weave.

Fix: add negation guards, require imperative-plus-object, and restrict the brand table to high-impersonation brands.

Everything below makes these concrete.

---

1. Critique of the draft scoring design

1.1 The two ledgers: keep, but separate attacker-controlled evidence from attacker-uncontrollable evidence

The ledgers split "who is this" from "what is this asking". That split is correct and it is the product's core differentiator. The missing axis is who controls the evidence:

Rule: soft codes may move a message within Unrecognized. Only hard codes can lift it to Likely legitimate. In the reference implementation this is the hard flag. Corpus pair G22 vs G23 tests it: identical Carlos text, with and without a ledger entry.

Two subtleties:

• A generic ledger match is soft. "Expecting FedEx" is a guessable context. Every scammer sends FedEx/USPS/UPS lures, so an attacker matches it by volume. Only a specific entity ("Bright Smile Dental", "Carlos at The Ashford") counts as hard. Hence two codes: EXPECTED_SENDER_GENERIC (+1.0, soft) and EXPECTED_SENDER_SPECIFIC (+2.5, hard).
• A trivial reply is not continuity. The reply-Y trick is designed precisely to manufacture "the user replied" (see §4). A reply consisting of a single token (Y, YES, 1, OK, STOP, or "wrong number") earns THREAD_USER_REPLIED_TRIVIAL (0), not THREAD_USER_REPLIED (+2.5). Tested by G18 and G36.

1.2 Log-odds summing: correlated codes must be capped by family

Naive-Bayes summing assumes the codes are conditionally independent. They are not. "late fee", "$6.99", "pay by 10/04" and "toll" all come from the same scam template. Fix:

The caps keep a single template from saturating the score through repetition. Independent families still add. A toll smish with a lookalike link and the reply-Y trick should be at about 100, and is (G16, L = +8.5).

The prior carries the base rate by sender kind:

All values are starting points (§5). G38 (a +44 friend) and G39 (a bare "Hello, are you free?" from an email gateway) pin the requirement that no sender kind alone reaches Suspicious (40). G39 sits at 38 on purpose: if calibration pushes the email-gateway prior above about −0.4, that test fails loudly, and that is the intended alarm.

Important: the sidecar sees a post-filter distribution. Google Messages' own spam filter suppresses notifications for what it catches, so the sidecar sees what Google missed plus all ham. The priors therefore should be lower than "fraction of unknown texts that are scams", and public datasets (full of easy spam) overstate how separable the residual is.

1.3 Are the five dimensions coherent? Is legitimacy_confidence redundant?

As drafted, legitimacy = identity + context − risk is redundant. It is a mix of three other displayed numbers, and once risk is folded in it becomes a noisy second copy of 100 − scam_risk. That is the exact conflation the PRD forbids ("unknown is not malicious").

The PRD requires five dimensions, so do not drop it. Redefine it so it carries information the others do not:

• identity_confidence: does the evidence show who the sender is? 100·σ(−2 + Σ identity codes).
• context_confidence: does the message tie into the user's life? 100·σ(−2 + Σ context codes).
• legitimacy_confidence: 100·σ(−2 + Σ identity + Σ context), capped at 59 when no hard code is present. It never includes risk. It is the "positive case for this message" number, and it is displayed but is not an input to the decision table. The table reads identity, context and risk directly.
• scam_risk: 100·σ(prior(sender_kind) + Σ family-capped risk codes + negative codes). Negative codes are allowed only for hard evidence: KNOWN_SHORT_CODE_BRAND (−1.0) and LINK_DOMAIN_VERIFIED (−1.0). Context codes never lower risk. This is the draft's own rule, and it is the right one.
• analysis_completeness: points:
• sender identifier present: 25
• text present and not an OS placeholder: 35
• text not truncated (no trailing "…", not cut at a known length boundary): 25
• not redacted or hidden: 15

The point of keeping legitimacy and risk as separate quantities: both can be high at once, and that is the most informative state the product can show. Two examples:

• G14: a contact asks for the OTP. Legitimacy 95, tripwire on → "This is Mike's number, but the request is an account-takeover pattern."
• G09: an expected FedEx delivery with a fedex-track.info link. Context is up, risk 98 → "You are expecting FedEx, but this link is not fedex.com."

A single score cannot say either sentence.

UI consequence for contacts. For contacts, scam_risk with a −4 prior stays low (G24 reports 23) while the verdict says Suspicious. That will confuse users. Either display a content risk computed with the neutral long-code prior (−1.5) next to sender trust, or show only the triggered codes for contacts. Recommended: always compute both scam_risk (sender-aware, used for gating) and content_risk (prior −1.5, for display and for the compromise gate).

1.4 How analysis_completeness should interact

The draft checks completeness first, which hides visible tripwires. Use this ordering instead:

1. If no text is available (hidden preview, OS OTP redaction, "New message"), completeness is below 40 and the verdict is Cannot assess. No tripwire can fire without text, so nothing is hidden.
2. Partial text: run every detector on the visible text. Tripwires and risk codes count fully, because presence is evidence. Absence of risk codes is weaker evidence when completeness is below 80:

• legitimacy shown is capped at completeness;
• Likely legitimate is not allowed unless a hard identity code is present (contact, trusted, known short code);
• the explanation says "assessed on partial text; open in Messages".

G33 ("Your account has been tempor…") must land on Unrecognized, not Likely legitimate.

3. Interruption policy keys on identity_confidence, not on the verdict. G34 is Mom with a hidden preview: verdict Cannot assess, identity 95. In "Quiet unknowns" mode Mom must still alert. If interruption keys on the verdict, the product silences the user's mother whenever lock-screen privacy is on.

1.5 Revised decision table (as implemented in tools/score.py)

no visible text (completeness < 40)            -> Cannot assess
sender is contact / user-trusted:
    tripwire OR content risk-code sum >= 2.5   -> Suspicious + POSSIBLE_ACCOUNT_COMPROMISE
                                                  (Likely scam/phishing if scam_risk >= 70)
    else                                       -> Recognized
any tripwire                                   -> Likely scam/phishing if scam_risk >= 70, else Suspicious
scam_risk >= 70                                -> Likely scam/phishing
scam_risk >= 40                                -> Suspicious
(identity >= 60 OR context >= 60) AND >=1 hard code AND risk < 40
                                               -> Likely legitimate
otherwise                                      -> Unrecognized / insufficient context

Logit thresholds: 40 ↔ L = −0.405 and 70 ↔ L = +0.847.

Differences from the draft:

• Tripwires run before completeness.
• Contacts get a compromise gate based on the content sum, not on scam_risk, because the −4 prior would otherwise hide G24.
• The hard-code requirement is new.
• Unrecognized is the default.

1.6 Other specific problems

• GENERIC_OPENER must weigh 0. A positive weight on "Are you working today?" contradicts the PRD's golden case on principle, even if the number is small. Its job is to arm the trajectory detector: the next message from the same HMAC'd sender is checked for WRONG_NUMBER_PIVOT, PLATFORM_SHIFT and INVESTMENT_PIVOT. It is shown in the explanation as a neutral fact.
• Trajectory state needs a time window and decay. Use 14 days. Otherwise a real misdial from March pollutes a legitimate message in October.
• POSSIBLE_ACCOUNT_COMPROMISE should be worded carefully. G24 (a friend shilling a crypto platform) is as likely a victim recruiting friends, which is a known pig-butchering dynamic, as a hijacked account. Explanation: "Unusual for this contact; confirm by calling them."
• INJECTION_ATTEMPT as a tripwire: agree. Legitimate SMS never addresses an AI classifier. Keep the detector narrow (§2.7) so a friend joking about ChatGPT doesn't trip it.
• The LLM's output space needs a weight cap per label. Recommendation: no LLM label above +1.0 and none hard. That way the LLM can never create Likely legitimate or Likely scam by itself; it can only nudge Suspicious ↔ Unrecognized. The fixed-vocabulary, span-must-match design in §F is good.

---

2. Reason-code catalog (starter, ~60 codes)

Text normalization runs first and is shared by every detector:

1. Apply NFKC.
2. Record and strip zero-width characters (U+200B–U+200D, U+2060, U+FEFF).
3. Map confusables (Cyrillic/Greek → Latin) via the Unicode confusables table. Record whether anything changed.
4. Lowercase a working copy.
5. De-fang: hxxp→http, [.]/(.)/ dot →., and usps . com → usps.com.

URL extraction:

• With scheme: \bhttps?://[^\s<>"]+
• Without scheme: \b(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z]{2,24}\b(?:/[^\s]*)?
• Then compute the registrable domain (eTLD+1) with a bundled Public Suffix List snapshot. The app has no INTERNET permission, so the PSL ships in the APK and updates with app releases.

Columns: weight is in log-odds. T = tripwire. H = hard evidence (attacker cannot control).

2.1 Sender-kind (prior selector; explanation-only codes)

2.2 Identity ledger

2.3 Context ledger

2.4 Risk ledger: LINK family (sum, cap +3.0)

2.5 Risk ledger: ASK family (sum, cap +3.0)

2.6 Risk ledger: PRETEXT (max of family), PRESSURE (cap 1.0), SENDER (cap 1.0)

2.7 Risk ledger: SOCIAL (cap 2.0) and EVASION (cap 2.5)

2.8 Meta / completeness codes (weight 0, always shown)

POSSIBLE_ACCOUNT_COMPROMISE (from the contact gate), PREVIEW_TRUNCATED, PREVIEW_HIDDEN (placeholder text such as "New message" or "Sensitive notification content hidden"), OTP_REDACTED_BY_OS, SENDER_ID_MISSING.

---

3. Golden corpus

The full corpus is in golden-corpus.json: 42 cases covering contact, US long code, short code, toll-free, email gateway and international senders.

Fictional numbers use 555-01XX and 07700 900XXX. Short code values for real brands are illustrative; the shipped table must come from brand-published lists.

Every case's expected codes and verdict are reproduced end-to-end by tools/detect.py + tools/score.py, starting from the raw text. If an implementer changes a weight or a regex, tools/corpus.py says which cases moved.

What the corpus deliberately pins:

• Pairs that differ by one fact: G04/G05 (ledger), G06/G07 (sender kind), G09/G10 (link domain), G22/G23 (ledger), G02/G25 (money ask).
• Negation and promo FPs: G11, G27.
• The unknown-is-not-malicious floor: G01, G20, G21, G38, G39, G41.
• Reply-Y laundering: G36.
• Completeness behavior: G12, G33, G34.

---

4. Scam-family coverage and sources

Not verified here, so treat as assumptions:

• USPS's statement that it does not text tracking links unless you opted in (USPS Text Tracking).
• The IRS never initiating contact by text.
• Exact real short codes for Chase, Google, FedEx, CVS, Verizon and Target. The values in the corpus are illustrative.

---

5. Calibration without a big dataset

5.1 Data sources

5.2 Method

1. Start from expert weights (this document).
2. Estimate per-code likelihood ratios where a dataset has both classes: LR = (k_scam+α)/(n_scam+2α) ÷ (k_ham+α)/(n_ham+2α) with α=1 (Beta-smoothed).
3. Shrink toward the expert weight: w = (n·log LR + m·w_expert)/(n+m) with m≈20 pseudo-observations. Codes seen rarely stay near the expert value.
4. Estimate within families, not codes. Fit the family cap as the 90th percentile of the family's summed LR on positives. This directly measures the correlation problem from §1.2.
5. Correct the prior for deployment base rate. Dataset class ratios are not deployment base rates. Set priors per sender kind from the user's own first 2–4 weeks in shadow mode: score silently and collect user labels. Remember the post-Google-filter shift: the deployed base rate is lower than any public dataset implies.
6. The golden corpus is a regression gate, not a training set. Every weight change reruns tools/corpus.py. Any verdict change requires an explicit decision-log entry. Add a case for every user-reported misclassification.
7. Report calibration honestly with a reliability diagram per sender kind once ≥200 labeled messages exist. Until then, show the UI percentages as banded words (low / elevated / high), not "73%". Two-digit precision would be false precision.

5.3 User feedback: adjusting safely

Feedback is itself an attack surface. A scammer can socially engineer "mark as safe" and then exploit the trust it earns.

• Per-sender (immediate, local):
• "Trust sender" → USER_TRUSTED (+5 identity).
• "Not legit" → a per-sender risk override that forces at least Suspicious.
• Both are reversible from sender history.
• Tripwires still fire for trusted senders. That is the compromise gate; G14 shows why.
• Global per-code multipliers (slow, bounded):
• multiplier ∈ [0.5, 1.5] of the shipped weight;
• a step moves only after ≥3 feedback events from ≥3 distinct senders within 30 days;
• step size ≤0.1, with exponential decay back toward 1.0 (half-life 90 days);
• every change is logged and one-tap undoable in "Why was this scored?".
• Asymmetric: "this was a scam" can raise a code's multiplier with less evidence (2 senders) than "this was fine" needs to lower it (3 senders).
• Floors:
• tripwire weights and the tripwire flag can never be reduced by feedback;
• the hard/soft classification of a code never changes by feedback;
• feedback cannot change sender-kind priors (those change only through app updates).
• Never learn from a single message's text (no n-gram learning on-device in v1). Feedback adjusts the weights of named codes only, so every adjustment stays explainable as "you told me code X was wrong 3 times".

---

Sources

1. FTC Data Spotlight, "Top text scams of 2024" (Apr 2025): https://www.ftc.gov/news-events/data-visualizations/data-spotlight/2025/04/top-text-scams-2024
2. FTC press release, "Text scams hit $470 million": https://oig.ftc.gov/news-events/news/press-releases/2025/04/new-ftc-data-show-top-text-message-scams-2024-overall-losses-text-scams-hit-470-million
3. FBI IC3 PSA I-041224-PSA (toll smishing): https://ic3.gov/PSA/2024/PSA240412
4. NBC, "Spam texts about unpaid tolls are on the rise" (60k+ IC3 complaints in 2024): https://www.nbcboston.com/news/national-international/spam-texts-about-unpaid-tolls-are-on-the-rise-heres-what-to-do-if-you-get-one/3659397/
5. KrebsOnSecurity, "China-based SMS phishing triad pivots to banks" (Apr 2025): https://krebsonsecurity.com/2025/04/china-based-sms-phishing-triad-pivots-to-banks
6. TRM Labs, key findings from the FBI 2024 IC3 report: https://www.trmlabs.com/resources/blog/a-record-breaking-year-for-cybercrime-key-findings-from-the-fbis-2024-ic3-report-k1c94
7. FTC Data Spotlight on task scams (Dec 2024): https://www.ftc.gov/node/86951
8. BleepingComputer, "Phishing texts trick Apple iMessage users into disabling protection": https://www.bleepingcomputer.com/news/security/phishing-texts-trick-apple-imessage-users-into-disabling-protection/
9. Malwarebytes on the same campaign: https://www.malwarebytes.com/blog/news/2025/01/imessage-text-gets-recipient-to-disable-phishing-protection-so-they-can-be-phished
10. The Hacker News, Smishing Triad / Unit 42 domains: https://thehackernews.com/2025/04/chinese-smishing-kit-behind-widespread.html
11. Silent Push, "Smishing Triad": https://www.silentpush.com/blog/smishing-triad
12. Android Authority, Android 15 sensitive notifications: https://www.androidauthority.com/android-15-sensitive-notifications-3416414
13. Timko et al., "Smishing Dataset I: Phishing SMS Dataset from Smishtank.com" (2024): https://arxiv.org/html/2402.18430v2
14. Mishra & Soni, SMS Phishing Dataset (Mendeley, 2022): https://data.mendeley.com/datasets/f45bkkt8pr
15. Balanced spam/smishing dataset for LLMs (Mendeley): https://data.mendeley.com/datasets/vmg875v4xs
16. "SMS Phishing Attacks and Defenses: A Systematic Review" (2026): https://arxiv.org/pdf/2604.11429

← Back to the proposal