Objective & Guardrails Prompting Guide

This guide teaches you how to write effective objectives and guardrails - the two tools that give your PAL structure and safety during conversations. Objectives are goals your PAL works through in order, like collecting a user’s name or confirming an appointment. Guardrails are safety rules that run in the background the entire time, like “don’t give medical advice.”

Create objectives with the Create Objectives API and guardrails with the Create Guardrail API. For full parameter details, see the Objectives and Guardrails docs.

How the System Works

Behind the scenes, two LLMs work together:

The conversational AI talks to the user. It receives your objective_prompt in its system prompt, along with instructions to guide the user toward completing the objective.
The evaluator watches the conversation in the background. It periodically checks whether each objective has been met and extracts any output variables you defined.

Your objective prompts drive both of these - they shape how the AI steers the conversation and how the evaluator tracks progress. This is why clarity and specificity matter so much.

What the Conversational AI Sees

Your objective_prompt (describing what to accomplish)
Instructions to actively engage with the user and gather the needed information
Progress on variable collection (what’s been collected, what’s still missing)
Guardrail prompts (if any)

What the Evaluator Does

For each active objective, the evaluator:

Reads your objective prompt
Analyzes the full conversation history
Extracts the variables you defined (for info collection objectives)
Decides if the objective is complete or incomplete (for condition checks)
Chooses which branch to follow (for conditional objectives)

The evaluator can only see the conversation transcript. It can’t check your database, look up account tiers, or access anything outside the conversation.

Adding Objectives and Guardrails to a PAL

After creating your objectives or guardrails, attach them when creating a PAL:

curl --request POST \
  --url https://tavusapi.com/v2/pals/ \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <api-key>' \
  --data '{
    "system_prompt": "You are a health intake assistant.",
    "objectives_id": "o12345",
    "guardrails_id": "g12345"
  }'

Or add them to an existing PAL by editing it:

curl --request PATCH \
  --url https://tavusapi.com/v2/pals/{pal_id} \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <api-key>' \
  --data '[
    {"op": "add", "path": "/objectives_id", "value": "o12345"},
    {"op": "add", "path": "/guardrails_id", "value": "g12345"}
  ]'

Writing Objectives

An objective has a prompt that describes the goal and, optionally, a list of variables to extract from the conversation. A good objective prompt follows this pattern: describe what information to collect or what condition to check for.

Collecting Information

The most common type of objective. You describe what information you want, and the system pulls it from the conversation.

{
  "objective_name": "get_personal_info",
  "objective_prompt": "Collect the user's first name, last name, and email address",
  "output_variables": ["first_name", "last_name", "email"]
}

{
  "objective_name": "get_appointment_preference",
  "objective_prompt": "Determine when the user wants to schedule their appointment (preferred date and time)",
  "output_variables": ["preferred_date", "preferred_time"]
}

{
  "objective_name": "understand_issue",
  "objective_prompt": "Understand the technical problem the user is experiencing. Extract what went wrong and when it started.",
  "output_variables": ["problem_description", "when_started"]
}

Tips:

Keep the prompt short and specific.
Make sure the prompt matches the variables. If you ask for “the user’s name” but list ["first_name", "last_name", "email", "phone"], the system won’t know what to do with the extras.
Don’t combine unrelated things. “User’s email and favorite color” should be two separate objectives.

Checking a Condition

Sometimes you just need to verify something happened - no variables needed. Set output_variables to an empty list [].

{
  "objective_name": "user_agreed_to_terms",
  "objective_prompt": "User has explicitly agreed to the terms and conditions",
  "output_variables": []
}

{
  "objective_name": "issue_resolved",
  "objective_prompt": "User has confirmed that their technical issue is now resolved and they are satisfied",
  "output_variables": []
}

Tips:

Be specific. “User seems happy” won’t work - the system can’t measure feelings. “User has confirmed they are satisfied” is concrete.
Only check things that have already happened. “User will receive a confirmation email” can’t be evaluated. “User has acknowledged they will receive a confirmation email” can.

Using the Camera (Visual Objectives)

If your PAL uses a camera or screen share, you can write objectives that check what’s visible. Set "modality": "visual".

{
  "objective_name": "verify_id_card",
  "objective_prompt": "User is holding a valid government-issued ID card that is clearly visible and legible",
  "modality": "visual",
  "output_variables": []
}

{
  "objective_name": "check_screen_error",
  "objective_prompt": "Check if an error message is visible on the user's shared screen. Extract the error code and message text.",
  "modality": "visual",
  "output_variables": ["error_code", "error_message"]
}

Tips:

Focus on things that are clearly visible - large text, obvious objects, clear gestures.
Don’t expect the system to read tiny text or make expert judgments from a video feed.

Output Variables

Naming

Good variable names are clear and specific:

Good	Bad	Why
`first_name`	`name`	”Name” could mean first, last, or full
`preferred_date`	`data`	”Data” means nothing
`reason_for_visit`	`info`	”Info” is too vague
`symptom_duration`	`thing1`	Not descriptive at all

Break Information into Small Pieces

Split variables into the smallest useful units: Good - each piece is separate:

{
  "objective_prompt": "Get the user's shipping address",
  "output_variables": ["street_address", "city", "state", "zip_code"]
}

Bad - everything lumped together:

{
  "objective_prompt": "Get the user's shipping address",
  "output_variables": ["full_address"]
}

Smaller pieces are easier to validate, easier to use in your code, and make it possible to handle partial information (e.g., the user gives their city but not their zip code).

Variables Are Always Strings

The system returns all values as strings, even numbers and dates:

{
  "age": "32",
  "is_member": "yes",
  "appointment_date": "2025-02-15"
}

If you need separate fields (like year, month, day), use separate variables. Convert or validate the string in your own application code.

What Happens When Information is Missing

If the user doesn’t provide a value, the system returns "NOTFOUND". You don’t need to handle this in your prompt - it happens automatically. Don’t do this:

{
  "objective_prompt": "Get the user's phone number. If they don't provide it, ask again."
}

Do this instead:

{
  "objective_prompt": "User's phone number if provided",
  "output_variables": ["phone_number"]
}

Handle what happens with NOTFOUND in your own application code.

Requesting a Specific Format

You can ask for values in a particular format. The system will try to convert, but being explicit helps:

{
  "objective_prompt": "Get the appointment date in YYYY-MM-DD format",
  "output_variables": ["appointment_date"]
}

Branching: Making Conversations Dynamic

You can send the conversation down different paths based on what the user says using next_conditional_objectives.

{
  "objective_name": "determine_issue_type",
  "objective_prompt": "Understand what problem or question the customer has",
  "output_variables": ["issue_description"],
  "next_conditional_objectives": {
    "technical_issue": "if the user is reporting a bug, error, or technical problem",
    "billing_question": "if the user has questions about payments, invoices, or pricing",
    "general_inquiry": "if the user has general questions or needs information"
  }
}

If there’s only one next step (no branching needed), use next_required_objective instead:

{
  "objective_name": "get_contact_info",
  "objective_prompt": "User's first name, last name, and email address",
  "output_variables": ["first_name", "last_name", "email"],
  "next_required_objective": "schedule_appointment"
}

Tips for branching:

Always include a catch-all branch like "general_questions": "for anything not covered above" so the conversation never gets stuck.
Keep conditions simple and non-overlapping. If two branches could both be true, the system won’t know which to pick.
Write conditions as positive statements. "if the user is a new patient" is clearer than "if the user is NOT a returning patient".
Stick to 2–5 branches. More than that gets unreliable.
Conditions must be based on what was said in the conversation - the system can’t look up account info or check a database.

Writing Guardrails

Guardrails are safety checks that run silently in the background for the entire conversation. When one is violated, it triggers a webhook so you can take action. Each guardrail has a prompt describing the violation to watch for:

{
  "guardrail_name": "no_medical_advice",
  "guardrail_prompt": "Assistant is providing medical diagnosis or treatment recommendations without proper disclaimers"
}

{
  "guardrail_name": "professional_tone",
  "guardrail_prompt": "Assistant is using unprofessional language, slang, or inappropriate tone"
}

{
  "guardrail_name": "no_sensitive_data",
  "guardrail_prompt": "User is sharing sensitive information like social security numbers, credit card details, or passwords in full"
}

Guardrails can also be visual - for example, checking the camera feed:

{
  "guardrail_name": "single_user_only",
  "guardrail_prompt": "More than one person is visible in the camera view",
  "modality": "visual"
}

Tips:

Keep guardrail prompts short and direct.
Describe the specific violation, not a general vibe. “User is being inappropriate” is too broad. “User is using profanity or threatening language” is specific enough to detect.
Don’t use guardrails to drive conversation flow - that’s what objectives are for.

When to Use a Guardrail vs. an Objective

	Objective	Guardrail
Purpose	Collect info or advance the conversation	Monitor for policy violations
When it runs	One at a time, in sequence	Continuously, the entire conversation
When it’s done	Moves to the next step	Fires a webhook alert
Drives conversation?	Yes	No

Best Practices

Start simple

Begin with straightforward objectives and add complexity as needed. Get a basic flow working first, then add branching, then add guardrails.

One goal per objective

Don’t combine unrelated tasks. “Get user’s email and verify they’re 18+” should be two objectives, not one.

Use descriptive names

Objective names should explain what they do at a glance. get_shipping_address and verify_insurance_coverage are good. step1 and check_thing are not.

Think about how people actually talk

Write prompts based on how users naturally express things: Good:

{
  "objective_prompt": "Understand why the user is calling and what they need help with",
  "output_variables": ["reason_for_call"]
}

Bad:

{
  "objective_prompt": "Ascertain the telecommunications inquiry rationale and desired resolution pathway",
  "output_variables": ["inquiry_rationale"]
}

Plan for different phrasings

The LLM is good at understanding variations. A prompt like "Get the user's preferred contact method (email, phone, or text message)" will correctly handle “email me,” “I prefer phone calls,” “text is best,” and “reach out via email.”

The system remembers the whole conversation

The evaluator sees all messages, not just the latest one. So an objective like "User has confirmed that the address previously provided is correct" will work - the system will look back to find the address.

Keep system prompts short

If your system prompt is over ~500 words, objective evaluations become less reliable. Keep the system prompt focused on PAL and tone. Put the detailed workflow logic in your objectives.

Use `manual` confirmation for important decisions

For critical actions like authorizing a payment, set "confirmation_mode": "manual" so the system waits for explicit confirmation instead of deciding on its own.

Common Mistakes

Writing behavioral instructions instead of goals

The prompt should describe what to accomplish, not how to behave while doing it.

Wrong	Right
”Ask the user for their name and be polite"	"Collect the user’s name and email address"
"Make sure to collect their email"	"User’s email address”

Checking things that haven’t happened yet

The system can only look at the conversation so far - not the future.

Wrong	Right
”User will receive a confirmation email"	"User has acknowledged they will receive a confirmation email”

Relying on data outside the conversation

The system can only read the transcript. It can’t check your database.

Wrong	Right
”User’s account is premium tier"	"Which service tier the user is interested in”

Cramming too much into one objective

If you need a lot of info, break it into smaller objectives. Users don’t provide 15 fields in one message.

Wrong	Right
One objective with 16 output variables	Three objectives: name, contact info, address

Being vague

The more specific your prompt, the more consistent the results.

Wrong	Right
”Get everything we need from the user"	"User’s preferred appointment date and time"
"User seems ready to proceed"	"User has explicitly confirmed they want to proceed”

Prompt doesn’t match the variables

If your prompt says “Get the user’s name” but output_variables lists ["first_name", "last_name", "email", "phone"], the system won’t know what to do with the extras. Don’t make separate objectives for first name, last name, and email. Group related fields together - users often provide them all at once.

Using negative conditions for branching

"if condition A is true" is clearer than "if NOT condition B and NOT condition C". Positive conditions are less error-prone.

Overloading the system prompt

A 2,000-word system prompt that covers every scenario dilutes the objective evaluations. Keep the system prompt lean and put workflow logic in the objectives.

Testing Your Prompts

Before launch

Try it yourself. Have a conversation with your PAL and check whether the right values get extracted.
Test edge cases. What happens if the user gives partial info? Changes their answer? Gives everything in one long sentence? Refuses to answer?

After launch

Track NOTFOUND rates for each variable. High rates mean your prompt may be unclear or asking for something users don’t naturally provide.
Identify stuck objectives - objectives that never complete may have prompts that are too strict.
Monitor correction rates. If the system frequently extracts wrong values, the prompt needs to be more specific.
Review guardrail webhooks. Lots of false positives means the guardrail prompt is too broad.

A/B testing

Try different prompt wordings and measure completion rates. For example:

Version A: "Get the user's email address"
Version B: "Extract the user's email address if they provide one"

Measure which has fewer NOTFOUND results and faster completion.

Example: Healthcare Intake

A complete patient intake workflow with objectives and guardrails:

{
  "data": [
    {
      "objective_name": "get_patient_info",
      "objective_prompt": "Collect the patient's first name, last name, and date of birth",
      "output_variables": ["first_name", "last_name", "date_of_birth"],
      "modality": "verbal",
      "next_required_objective": "get_reason_for_visit"
    },
    {
      "objective_name": "get_reason_for_visit",
      "objective_prompt": "Understand the primary reason the patient is seeking care today",
      "output_variables": ["reason"],
      "modality": "verbal",
      "next_conditional_objectives": {
        "urgent_symptoms": "if patient describes severe pain, bleeding, difficulty breathing, or other emergency symptoms",
        "routine_care": "if patient needs regular care, medication refills, or has minor symptoms",
        "preventive_visit": "if patient is here for a checkup, screening, or wellness visit"
      }
    },
    {
      "objective_name": "urgent_symptoms",
      "objective_prompt": "Gather details about the urgent symptoms including severity and duration",
      "output_variables": ["symptom_description", "severity", "duration"],
      "modality": "verbal",
      "next_required_objective": "schedule_appointment"
    },
    {
      "objective_name": "routine_care",
      "objective_prompt": "Get details about the routine care needed",
      "output_variables": ["care_type"],
      "modality": "verbal",
      "next_required_objective": "schedule_appointment"
    },
    {
      "objective_name": "preventive_visit",
      "objective_prompt": "Determine which preventive services the patient needs",
      "output_variables": ["services_needed"],
      "modality": "verbal",
      "next_required_objective": "schedule_appointment"
    },
    {
      "objective_name": "schedule_appointment",
      "objective_prompt": "Get the patient's preferred date and time for their appointment",
      "output_variables": ["preferred_date", "preferred_time"],
      "modality": "verbal",
      "next_required_objective": "confirm_details"
    },
    {
      "objective_name": "confirm_details",
      "objective_prompt": "Patient has confirmed all details are correct",
      "output_variables": [],
      "modality": "verbal",
      "confirmation_mode": "manual"
    }
  ]
}

Guardrails for this PAL:

{
  "name": "Healthcare Compliance",
  "data": [
    {
      "guardrail_name": "emergency_detected",
      "guardrail_prompt": "Patient indicates they are experiencing a life-threatening emergency (chest pain, severe bleeding, loss of consciousness, difficulty breathing)",
      "modality": "verbal",
      "callback_url": "https://your-server.com/emergency-alert"
    },
    {
      "guardrail_name": "medical_advice_given",
      "guardrail_prompt": "Assistant is providing specific medical diagnosis or treatment recommendations",
      "modality": "verbal",
      "callback_url": "https://your-server.com/compliance-alert"
    }
  ]
}

Example: Customer Support Triage

A support workflow that routes customers to the right path:

{
  "data": [
    {
      "objective_name": "identify_customer",
      "objective_prompt": "Get the customer's account email or order number to look up their account",
      "output_variables": ["account_identifier"],
      "modality": "verbal",
      "next_required_objective": "understand_issue"
    },
    {
      "objective_name": "understand_issue",
      "objective_prompt": "Understand what problem or question the customer has",
      "output_variables": ["issue_description"],
      "modality": "verbal",
      "next_conditional_objectives": {
        "technical_issue": "if customer is experiencing a bug, error, or technical problem with the product",
        "billing_question": "if customer has questions about charges, refunds, or payment issues",
        "shipping_inquiry": "if customer is asking about delivery status or shipping issues",
        "product_question": "if customer has questions about features, how to use the product, or general information",
        "account_management": "if customer needs help with account settings, password, or profile"
      }
    },
    {
      "objective_name": "technical_issue",
      "objective_prompt": "Get specific details about the technical problem including error messages, when it started, and steps already tried",
      "output_variables": ["error_details", "when_started", "steps_tried"],
      "modality": "verbal",
      "next_required_objective": "resolve_or_escalate"
    },
    {
      "objective_name": "billing_question",
      "objective_prompt": "Get details about the billing concern including transaction date and amount if applicable",
      "output_variables": ["billing_concern", "transaction_date", "amount"],
      "modality": "verbal",
      "next_required_objective": "resolve_or_escalate"
    },
    {
      "objective_name": "shipping_inquiry",
      "objective_prompt": "Get the order number and specific shipping concern",
      "output_variables": ["order_number", "shipping_concern"],
      "modality": "verbal",
      "next_required_objective": "resolve_or_escalate"
    },
    {
      "objective_name": "product_question",
      "objective_prompt": "Understand exactly what the customer wants to know about the product",
      "output_variables": ["question_details"],
      "modality": "verbal",
      "next_required_objective": "resolve_or_escalate"
    },
    {
      "objective_name": "account_management",
      "objective_prompt": "Understand what account changes or help the customer needs",
      "output_variables": ["account_need"],
      "modality": "verbal",
      "next_required_objective": "resolve_or_escalate"
    },
    {
      "objective_name": "resolve_or_escalate",
      "objective_prompt": "Customer has either confirmed their issue is resolved OR agreed to be escalated to a specialist",
      "output_variables": ["outcome"],
      "modality": "verbal",
      "next_required_objective": "closing"
    },
    {
      "objective_name": "closing",
      "objective_prompt": "Customer has indicated they are satisfied and ready to end the conversation",
      "output_variables": [],
      "modality": "verbal"
    }
  ]
}

Guardrails for this PAL:

{
  "name": "Customer Support Safety",
  "data": [
    {
      "guardrail_name": "profanity_detected",
      "guardrail_prompt": "User is using profanity, insults, or abusive language",
      "modality": "verbal",
      "callback_url": "https://your-server.com/abuse-alert"
    },
    {
      "guardrail_name": "data_breach_attempt",
      "guardrail_prompt": "User is asking for other customers' information or trying to access accounts they shouldn't have access to",
      "modality": "verbal",
      "callback_url": "https://your-server.com/security-alert"
    }
  ]
}

Example: Visual Identity Verification

A workflow that uses the camera to verify a user’s identity:

{
  "data": [
    {
      "objective_name": "initial_instructions",
      "objective_prompt": "User acknowledges they are ready to begin the verification process",
      "output_variables": [],
      "modality": "verbal",
      "next_required_objective": "verify_id"
    },
    {
      "objective_name": "verify_id",
      "objective_prompt": "User is holding a government-issued photo ID (driver's license, passport, or state ID) that is clearly visible and legible in the camera",
      "modality": "visual",
      "output_variables": [],
      "next_required_objective": "verify_face"
    },
    {
      "objective_name": "verify_face",
      "objective_prompt": "User's face is clearly visible and matches the photo on the ID shown in previous step",
      "modality": "visual",
      "output_variables": [],
      "next_required_objective": "capture_id_details"
    },
    {
      "objective_name": "capture_id_details",
      "objective_prompt": "Extract the name, date of birth, and ID number from the government ID",
      "output_variables": ["full_name", "date_of_birth", "id_number"],
      "modality": "verbal",
      "next_required_objective": "verification_complete"
    },
    {
      "objective_name": "verification_complete",
      "objective_prompt": "User has confirmed their identity verification is complete",
      "output_variables": [],
      "modality": "verbal",
      "confirmation_mode": "manual"
    }
  ]
}

Guardrails for this PAL:

{
  "name": "Verification Security",
  "data": [
    {
      "guardrail_name": "multiple_people_detected",
      "guardrail_prompt": "More than one person is visible in the camera view",
      "modality": "visual",
      "callback_url": "https://your-server.com/security-alert"
    },
    {
      "guardrail_name": "poor_lighting",
      "guardrail_prompt": "The camera view is too dark, too bright, or too blurry to clearly see details",
      "modality": "visual",
      "callback_url": "https://your-server.com/quality-alert"
    },
    {
      "guardrail_name": "id_looks_fake",
      "guardrail_prompt": "The ID appears to be a photograph of an ID, a photocopy, or shows signs of tampering",
      "modality": "visual",
      "callback_url": "https://your-server.com/fraud-alert"
    }
  ]
}

Example: Restaurant Reservation

A simple reservation flow with dietary restriction branching:

{
  "data": [
    {
      "objective_name": "get_party_size",
      "objective_prompt": "Get the number of people in the dining party",
      "output_variables": ["party_size"],
      "modality": "verbal",
      "next_required_objective": "get_datetime"
    },
    {
      "objective_name": "get_datetime",
      "objective_prompt": "Get the desired date and time for the reservation",
      "output_variables": ["reservation_date", "reservation_time"],
      "modality": "verbal",
      "next_required_objective": "check_dietary"
    },
    {
      "objective_name": "check_dietary",
      "objective_prompt": "Whether anyone in the party has dietary restrictions or allergies",
      "output_variables": ["has_restrictions"],
      "modality": "verbal",
      "next_conditional_objectives": {
        "collect_restrictions": "if customer indicates there are dietary restrictions or allergies",
        "get_contact": "if customer indicates no dietary restrictions"
      }
    },
    {
      "objective_name": "collect_restrictions",
      "objective_prompt": "Specific details about dietary restrictions or allergies",
      "output_variables": ["restriction_details"],
      "modality": "verbal",
      "next_required_objective": "get_contact"
    },
    {
      "objective_name": "get_contact",
      "objective_prompt": "Customer's name and phone number for the reservation",
      "output_variables": ["customer_name", "phone_number"],
      "modality": "verbal",
      "next_required_objective": "confirm_reservation"
    },
    {
      "objective_name": "confirm_reservation",
      "objective_prompt": "Customer has confirmed all reservation details are correct",
      "output_variables": [],
      "modality": "verbal",
      "confirmation_mode": "manual"
    }
  ]
}

Guardrails for this PAL:

{
  "name": "Restaurant Reservation Rules",
  "data": [
    {
      "guardrail_name": "party_too_large",
      "guardrail_prompt": "Customer requests a party size larger than 12 people",
      "modality": "verbal",
      "callback_url": "https://your-server.com/large-party-alert"
    }
  ]
}

​How the System Works

​What the Conversational AI Sees

​What the Evaluator Does

​Adding Objectives and Guardrails to a PAL

​Writing Objectives

​Collecting Information

​Checking a Condition

​Using the Camera (Visual Objectives)

​Output Variables

​Naming

​Break Information into Small Pieces

​Variables Are Always Strings

​What Happens When Information is Missing

​Requesting a Specific Format

​Branching: Making Conversations Dynamic

​Writing Guardrails

​When to Use a Guardrail vs. an Objective

​Best Practices

​Start simple

​One goal per objective

​Use descriptive names

​Think about how people actually talk

​Plan for different phrasings

​The system remembers the whole conversation

​Keep system prompts short

​Use manual confirmation for important decisions

​Common Mistakes

​Writing behavioral instructions instead of goals

​Checking things that haven’t happened yet

​Relying on data outside the conversation

​Cramming too much into one objective

​Being vague

​Prompt doesn’t match the variables

​Splitting related info across multiple objectives

​Using negative conditions for branching

​Overloading the system prompt

​Testing Your Prompts

​Before launch

​After launch

​A/B testing

​Example: Healthcare Intake

​Example: Customer Support Triage

​Example: Visual Identity Verification

​Example: Restaurant Reservation

How the System Works

What the Conversational AI Sees

What the Evaluator Does

Adding Objectives and Guardrails to a PAL

Writing Objectives

Collecting Information

Checking a Condition

Using the Camera (Visual Objectives)

Output Variables

Naming

Break Information into Small Pieces

Variables Are Always Strings

What Happens When Information is Missing

Requesting a Specific Format

Branching: Making Conversations Dynamic

Writing Guardrails

When to Use a Guardrail vs. an Objective

Best Practices

Start simple

One goal per objective

Use descriptive names

Think about how people actually talk

Plan for different phrasings

The system remembers the whole conversation

Keep system prompts short

Use `manual` confirmation for important decisions

Common Mistakes

Writing behavioral instructions instead of goals

Checking things that haven’t happened yet

Relying on data outside the conversation

Cramming too much into one objective

Being vague

Prompt doesn’t match the variables

Splitting related info across multiple objectives

Using negative conditions for branching

Overloading the system prompt

Testing Your Prompts

Before launch

After launch

A/B testing

Example: Healthcare Intake

Example: Customer Support Triage

Example: Visual Identity Verification

Example: Restaurant Reservation