Scoring and alternative scenarios
Authentication uses a 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. With that combination, 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 configured validation method accepts the user's answer, the question's points go to the step's running score. A step accepts each question at most once.
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." It means that no user can pass the step. 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 sees only the questions and the step guideline you wrote. Scoring is the gate; the guideline is how the agent offers the choice. 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 asks the questions in order and never offers 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 asks all three and passes the step only when it accepts all three.
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 keeps 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 walks 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 turned on |
|---|---|---|
| Max failed attempts | Failure panel → Incorrect responses | 3 |
| Step timeout | Failure panel → Authentication timeout | 5 minutes |
| Failure guideline | Failure panel → Guideline-based | None (free text) |
The failure guideline is the most flexible of the three. It's a free-text description of when the step fails. The agent reads it, watches the conversation, and exits with failure when it judges that 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 the agent detects this, the conversation routes immediately to a handover node. The user doesn't have 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 on → the agent moves to the verification step.
- Failure on any step → the conversation continues from the Trigger node on exit 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.