Scoring and alternative scenarios
Authentication uses a simple per-step scoring model: every question has a point weight, the step has a score threshold, and the step passes when the user's accumulated points meet the threshold. The clever uses come from how you combine weights, threshold, and the step's guideline — that combination is how you design "any two of three", "strong-or-two-weaker", or "all required" flows.
Per-question points
Every question has a weight between 1 and 5 (default: 1). When the user gives an answer that the configured validation method accepts, the question's points are added to the step's running score. A question can be accepted at most once per step.
You set this on each question with the Assign a weight for this question control:
Set how many points this specific question contributes toward the total success score.
Score threshold
On each step's Successful identification (or Successful verification) panel, the Score threshold is the minimum total points the user needs to pass:
The minimum total points from correct answers needed to pass this step.
If the threshold is higher than the sum of all weights on the step, the panel shows a warning — "Threshold exceeds the total available points." — meaning the step would be impossible to pass. Adjust either the weights or the threshold.
Designing alternative scenarios
This is where scoring earns its keep.
The auth LLM does not see point values or thresholds — it only sees the questions and the step guideline you wrote. To make an alternative scenario real, you have to do two things:
- Configure points + threshold so the math allows the alternative.
- Describe the alternative in plain language in the step guideline so the agent knows to offer it.
Without the guideline, the agent will just ask the questions in order and never offer the alternative. Without the math, the agent's offer would be a lie — the user would think they'd passed and the step wouldn't actually advance.
Three worked examples:
Strict identification — "all required"
| Question | Points |
|---|---|
| Full tax ID | 1 |
| Date of birth | 1 |
| Registered phone number | 1 |
Threshold: 3 (all three required).
Step guideline:
Ask the user for their full tax ID, their date of birth, and their registered phone number. All three are required.
The agent will ask all three and only pass when all three are accepted.
Pick any two — "user's choice"
| Question | Points |
|---|---|
| Full tax ID | 1 |
| Date of birth | 1 |
| Registered phone number | 1 |
Threshold: 2.
Step guideline:
Ask the user to confirm any two of the following: their full tax ID, their date of birth, or their registered phone number. The user can choose which two to provide.
The agent will keep accepting answers until any two are correct. The user picks which two.
Strong or two weaker
| Question | Points |
|---|---|
| Full tax ID | 2 |
| Last 4 digits of tax ID | 1 |
| Date of birth | 1 |
Threshold: 2.
| User provides… | Score | Passes? |
|---|---|---|
| Full tax ID alone | 2 | Yes — 2 ≥ 2 |
| Last 4 + DOB | 1 + 1 = 2 | Yes — 2 ≥ 2 |
| Last 4 alone | 1 | No — 1 < 2 |
| DOB alone | 1 | No — 1 < 2 |
Step guideline:
Ask the user for their full tax ID. If they don't have it on hand, accept the last 4 digits of their tax ID together with their date of birth as an alternative.
This is the canonical "strong primary identifier with a fallback path" shape.
Nine times out of ten the issue is the guideline, not the scoring. If you set a threshold of 2 but never described the alternative in the guideline, the agent will just walk through all three questions in order. Adjust the wording in the guideline first.
How a step fails
A step has three independent terminal failure conditions. Any one of them ends the step with failure and routes the conversation to the failure node.
| Condition | Where you set it | Default when enabled |
|---|---|---|
| Max failed attempts | Failure panel → Incorrect responses | 3 |
| Step timeout | Failure panel → Authentication timeout | 5 minutes |
| Failure guideline | Failure panel → Guideline-based | — (free text) |
The failure guideline is the most flexible of the three: it's a free-text description of when the step should be considered failed. The agent reads it, watches the conversation, and exits with failure when it judges the condition is met.
A common pattern is to use the failure guideline as an escalation hook:
The user asks to speak to a human, or explicitly refuses to authenticate.
When detected, the conversation routes immediately to a handover node, instead of forcing the user to fail attempts until they hit the max-attempts limit. See Failure guideline as an exit condition.
What happens after success and failure
Once a step reaches its threshold (success) or fires one of the failure conditions (failure):
- Success on the last enabled step → the conversation continues from the Trigger node on success you configured.
- Success on identification when verification is also enabled → the agent moves to the verification step.
- Failure on any step → the conversation continues from the Trigger node on failure you configured.
The two node selectors appear on the success and failure panels of the last enabled step (verification if it's on, otherwise identification).
Where to next
- Guidelines — how to write the step guideline and the failure guideline.
- Webhooks — validation webhooks and pre-enter webhooks for fetching ground truth.