Every route the assistant can take, what each one does, what it must never do, and how each promise is held.
| Route | Customer input | Permitted action | Signed-in session | Confirm one tap | SCA app approval | Must never… | How the never is enforced | Gold set human-signed route labels | Full-pipeline suite end-to-end; routes asserted, content LLM-judged |
|---|---|---|---|---|---|---|---|---|---|
Required controls | |||||||||
| Answer from public help content | |||||||||
FAQ / how-to |
| Answers grounded in bank documents, with citations | - | - | - | invent a fee, number, or rate; it cites sources or hands off. | Possible in code, held by prompts. The grounding and citation rules live in the answer prompt, and a deterministic check hands off to an advisor when no retrieved source supports an answer (assistant/pipeline.ts); whether this holds is measured by the tests on the right. | FAQ / how-to (human-ratified gold rows) 12/12 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | FAQ / how-to (the test items behind the count) 18/18 passAll 18 items expect the gate to route faq
|
| Read the account | |||||||||
Balance & transactions |
| Acts read-only | ✓ | - | - | move money or change anything; a logged read only. | Impossible in code. This route calls the two read functions only; nothing on this path can create, confirm, or execute an action (engine/bank.ts). | Balance & transactions (human-ratified gold rows) 7/7 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Balance & transactions (the test items behind the count) 2/2 passAll 2 items expect the gate to route account_read
|
| Act on the account | |||||||||
Lock card |
| Acts lock: protective | ✓ | ✓ | - | lock silently (one confirm), and never charge SCA to reduce your own risk. | Impossible in code. Execution refuses any action whose confirm never posted back (confirm_bypass_blocked); the lock route sets requiresSca=false, so the strong-auth surface is never invoked (engine/bank.ts). | Lock card (human-ratified gold rows) 7/7 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Lock card (the test items behind the count) 3/3 passAll 3 items expect the gate to route lock_card
|
Unlock card |
| Acts unlock: re-opens risk | ✓ | ✓ | ✓ | re-open a card on a tap alone; unlocking always costs a fresh SCA. | Impossible in code. The execute path runs the in-app approval before committing; on timeout nothing changes and the action stays pending, never a false success (engine/bank.ts). | Unlock card (human-ratified gold rows) 4/4 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Unlock card (the test items behind the count) 3/3 passAll 3 items expect the gate to route unlock_card
|
Payment designed, not enabled |
| Acts declines in this pilot; points to the app or a human. When enabled: confirm + in-app approval | ✓ | - | - | move money in this pilot; it routes you to the app or a human. | Impossible in code. The payment branch audits and declines, and the pending-action type admits only lock/unlock, so a payment cannot even be staged (assistant/pipeline.ts, engine/types.ts). | Payment (human-ratified gold rows) 4/4 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Payment (the test items behind the count) 2/2 passAll 2 items expect the gate to route payment
|
| Escalate to a human (designed destinations, not failure states) | |||||||||
Fraud / distress 24/7 fast-lane |
| Human fraud fast-lane: 24/7, never closes | - | - | - | resolve the fraud itself; it detects, fast-lanes a human, and offers an instant lock. | Impossible in code. The escalation branch appends audit and queues a human; no dispute or resolution function exists in the engine (assistant/pipeline.ts, engine/bank.ts). | Fraud / distress (human-ratified gold rows) 6/6 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Fraud / distress (the test items behind the count) 2/2 passAll 2 items expect the gate to route fraud_escalation
|
Complaint / réclamation explicit filing only |
| Routes to the official complaint form (réclamation); collects nothing in chat | - | - | - | take the complaint into the chat; the regulated process is the system of record, it routes you to the official form. Venting is not a complaint: frustration stays served, de-escalated. | Impossible in code. The complaint branch emits a reference and links the official form; chat stores no intake fields (assistant/pipeline.ts). | Complaint / réclamation (human-ratified gold rows) 3/3 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Complaint / réclamation (the test items behind the count) 2/2 passAll 2 items expect the gate to route complaint_route
|
Explicit human ask |
| Human designed handoff, transcript carried over | - | - | - | hide the human path: a visible confirm card, transcript carried over. | Possible in code, held by prompts. The confirm card and transcript carry are UI code; routing to this destination is scored on the gold set, the confirm-card behavior itself has no items yet. | Explicit human ask (human-ratified gold rows) 5/5 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Explicit human ask (the test items behind the count) 3/3 passAll 3 items expect the gate to route human_handoff
|
| Precedence: hard fraud signals outrank the stated intent and land on the fast-lane, which offers the instant card lock plus a specialist; a lock request with only soft vulnerability cues proceeds, with a human offered alongside. The protective action is never more than one tap away. | |||||||||
| Refuse | |||||||||
Regulated advice tax · legal · investment · creditworthiness |
| Refuses declines cleanly + offers a human | - | - | - | advise, score, or predict; it refuses cleanly and offers a human. | Possible in code, held by prompts. The refusal wall lives in the gate and answer prompts; whether it holds is measured by the tests in the next column. | Regulated advice (human-ratified gold rows) 5/5 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Regulated advice (the test items behind the count) 8/9 passAll 9 items expect the gate to route refusal
Failure analysis lives on the Eval scorecard |
Severe input criminal solicitation |
| Refuses refuses + audits, points to the bank's official support path† | - | - | - | play fraud detective; it refuses, audits, and points to the bank's official support path. | Possible in code, held by prompts. The input-moderation model screens every message first; a severe verdict short-circuits the turn before any other model runs (assistant/pipeline.ts). The eval suite deliberately runs with screening OFF to stress the layers beneath it; moderation accuracy itself is scored on the gold set in the Tests column. | Severe input (human-ratified gold rows) 5/5 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | no items |
| When the router doesn't know | |||||||||
Ambiguous request (unclassified) |
| Clarifies asks when the gate returns unclassified with no risk flags (shouldClarify=true, code), or when a message of two words or fewer would otherwise be answered from generic help (deterministic fragment fail-safe) | - | - | - | guess a route when the gate can't classify the request; it asks a clarifying question instead. | Possible in code, held by prompts. shouldClarify and the fragment fail-safe are code (engine/policy.ts); whether an ambiguous phrasing lands on 'other' is the model's judgment. | Ambiguous request (unclassified) (human-ratified gold rows) 6/6 passEach input's expected outcome was reviewed and signed by a human before it became the baseline. Pass means the deployed classifiers land on the signed outcome.
Full verdicts and miss analysis live on the Eval scorecard | Ambiguous request (unclassified) (the test items behind the count) 1/5 passAll 5 items expect the gate to route clarify
|
| When a precondition is unmet | |||||||||
Signed out any account request without a session |
| Blocks account rows stop at the session boundary; the gate still classifies, the policy still routes | - | - | - | touch an account without an authenticated session, and never dead-end a lost card: the reply carries the 24/7 emergency opposition line. Public FAQ and the safety routes still serve. | Impossible in code. laneNeedsSession stops every account lane server-side before the engine runs: no data, no card list, no confirm, no SCA (assistant/pipeline.ts). | Signed out (deterministic unit tests, no models) 7/7 pass
Run with npm run unit; this count is read from evals/results/unit-results.json | |
Out of hours human handoff outside support hours |
| Human async intake with a reply-by promise; fraud stays 24/7 | - | - | - | let support hours close the human path; hours are states, not gates. The fraud fast-lane stays 24/7. | Impossible in code. Hours only change the handoff message to async intake with a reply-by time; no route is gated on isOpen, and fraud skips the intake entirely (engine/hours.ts, assistant/pipeline.ts). | Out of hours (deterministic unit tests, no models) 6/6 pass
Run with npm run unit; this count is read from evals/results/unit-results.json | |
Plus 5 injection items (boundary + content) that exercise the PREPARE-only guarantee across the action routes: an injected instruction can at most PREPARE an action; execution still needs a separate confirm + SCA round-trip. Last run: 5/5 held. Reported on the Eval scorecard, not row-mapped here.