AI and Voice Transparency Notice

This is a proposed transparency notice for a future U.S. Dohos service. It is not current, approved, effective, or evidence that any capability is active. It does not provide consent to a call, AI processing, recording, transcription, marketing, biometric processing, or payment. The future Dohos legal entity, Restaurants, Providers, models, phone numbers, jurisdictions, data flows, retention, disclosure scripts, and fallback operations remain unverified. This draft must not be published or used at runtime until every activation condition is satisfied.

01Why this notice exists

Some Restaurants may choose to use a Dohos-powered automated system to help answer calls, understand requests, provide Restaurant-approved information, structure an Order Request, and route the interaction.

This notice explains:

• when a person may be interacting with an AI-assisted voice system
• what the system is intended and not intended to do
• how to correct, stop, or seek another channel
• the target treatment of audio, text, and Personal Data
• important limits involving orders, payments, allergies, emergencies, and decisions
• where to report an error or concern

The activated service must also provide a clear in-context disclosure at the start of the interaction and after a reconnect or transfer when needed. A webpage alone is not sufficient where law or reasonable understanding requires a spoken or channel-specific notice.

02Who you are interacting with

The activated opening disclosure should identify:

• the Restaurant and location on whose behalf the channel is operating
• that the interaction is with an automated or AI-assisted system, not a human
• the system's limited ordering or information purpose
• how to ask for repetition, correction, human assistance, another Restaurant channel, or exit
• any separate recording or communications disclosure that applies

Dohos provides the activated technology. The Restaurant is the target seller of Restaurant Products and controls its menu, ingredients, prices, availability, hours, order acceptance, preparation, fulfillment, substitutions, refunds, and Restaurant-specific customer relationship.

The automated system must not claim to be a Restaurant employee, owner, chef, licensed professional, emergency responder, or human operator. If a human joins, the service should identify whether that person represents the Restaurant or Dohos when the distinction matters.

03What "AI-assisted" means here

An activated voice interaction may use a combination of:

• telephony and communications routing
• automatic speech recognition that converts speech into transient text for processing
• language-model or rules-based processing that interprets and structures the request
• Restaurant-approved menus, policies, hours, availability, and other source data
• text-to-speech that generates an audible response
• deterministic calculations and transaction controls
• human or alternative-channel escalation

These components may be supplied by Dohos and approved Providers. The activated notice will identify Providers where required and will accurately describe their role. This draft does not name a production Provider because account-level contracts, configuration, data use, region, and subprocessor facts were not verified.

AI assistance does not mean the system understands the interaction like a person, has independent authority, or can guarantee a correct result.

04What the system may do

For an approved Restaurant, location, channel, and capability, the system may:

• answer limited questions using current Restaurant-approved information
• help navigate a menu and available options
• capture items, quantities, modifications, fulfillment choices, and requested instructions
• ask clarifying questions
• calculate or present amounts using the approved transaction system
• read back the proposed order and material terms
• obtain the Diner's affirmative confirmation through the approved process
• route the Order Request to the Restaurant for acceptance
• communicate evidence-backed status
• route a supported correction, cancellation, accessibility, privacy, safety, payment, or support issue

Only capabilities actually enabled for that Restaurant, location, channel, and release are available. Code, schema, demonstrations, planned features, marketing statements, or a capability used by another Restaurant do not make a feature active.

05What the system may not do

The system may not independently:

• invent or change a Restaurant's menu, ingredient, allergen, dietary, price, tax, fee, tip, discount, availability, hours, fulfillment, or refund information
• guarantee that food is allergen-free, suitable for a medical condition, prepared without cross-contact, or safe for a particular person
• accept an order on the Restaurant's behalf unless the exact automated acceptance mechanism is approved and clearly disclosed
• claim an order is accepted, prepared, ready, delivered, cancelled, or refunded without the required evidence
• authorize an unreviewed substitution, refund, discount, fee, tip, charge, or transfer
• infer final confirmation from silence, background speech, conversational acknowledgment, or failure to interrupt
• infer a person's identity, age, authority, consent, health, disability, emotion, ethnicity, religion, or other sensitive trait from voice or conversation
• create a Voiceprint or use biometric identity without a separately approved lawful program
• provide medical, legal, tax, financial, nutritional, emergency, or other professional advice
• contact emergency services or serve as an emergency service
• make employment, credit, housing, healthcare, education, insurance, legal-services, or other high-impact decisions
• override an approved human, payment, privacy, accessibility, security, or Restaurant control

If a response would require an unsupported fact or authority, the system should state the limit and use the approved fallback.

06Accuracy and uncertainty

Speech recognition and AI-generated responses can be wrong. Noise, accents, language, device quality, connection quality, overlapping speakers, uncommon names, menu terminology, rapid speech, Provider failures, and stale Restaurant data can affect performance.

The service should:

• ask a clarifying question when material information is uncertain
• avoid guessing
• repeat or spell material information on request
• identify a source or Restaurant dependency where useful
• stop an unsafe or unsupported action
• provide a correction opportunity
• route to the approved fallback when confidence or system state is inadequate

A fluent or natural voice does not make a response correct. Review the final order information carefully.

07Order review and confirmation

Before an Order Request is submitted, the activated system must clearly present or read back:

• the Restaurant and location
• items, quantities, options, and material instructions
• pickup, delivery, or other fulfillment method and relevant destination
• current prices, discounts, taxes, mandatory fees, delivery charges, tip, and total
• material availability, timing, cancellation, refund, and substitution information
• the effect of the final confirmation action

You must have a practical way to correct the information. The system must obtain the approved affirmative confirmation for the exact reviewed version.

An Order Request is not an Accepted Order merely because the system captured, summarized, displayed, transmitted, or acknowledged it. The Restaurant's approved acceptance event controls. The service should communicate whether the Restaurant accepted, rejected, or has not yet acted on the request. Full detail on the acceptance mechanism is in the Website and Diner Terms, Section 10.

08Allergies, dietary needs, and food safety

Tell the Restaurant directly about a serious allergy, dietary, medical, or food-safety concern using an approved channel. Do not rely solely on an AI response or a general menu label.

The automated system may relay Restaurant-approved information and preserve an instruction, but it does not inspect ingredients, suppliers, preparation areas, substitutions, packaging, or cross-contact. The Restaurant controls those facts and decides whether it can accommodate a request.

The system must not:

• turn a preference into an allergy statement or an allergy into a preference
• omit or silently rewrite a material instruction
• promise accommodation
• infer ingredient safety from an item name
• proceed after an unresolved material contradiction without the approved escalation

Review the exact allergy or dietary instruction during confirmation. If the Restaurant has not provided the information needed for your decision, use another channel or do not place the order through the automated system.

09Human help and alternative channels

The activated channel must explain the available fallback. Depending on the Restaurant and time, that may be:

• transfer to an identified Restaurant representative
• callback or message from the Restaurant
• transfer to an identified Dohos support person for a Dohos issue
• a Restaurant web or in-person channel
• an accessible alternative method
• ending the automated interaction without submitting an order

Human assistance may not always be immediately available. The system must not falsely promise that a human is available, that a transfer succeeded, or that the Restaurant received a request.

Asking for a human, repetition, correction, accessibility assistance, privacy help, or another channel must not be treated as marketing consent, final confirmation, or a waiver of rights.

10Capability-state transparency

The activated notice should state the status of each material capability for the relevant Restaurant and release. The target baseline is:

This table is a target design, generated from and corrected against verified configuration and runtime tests where evidence exists — as it does for the transcript row above. Any row without that evidence remains a target, not a current-state claim, and must be corrected again if live behavior diverges.

11Audio, transient text, and data use

Under the target baseline, speech is processed in real time to produce transient text and a response. Dohos does not retain raw call audio after the transient delivery purpose ends unless a Restaurant has separately enabled and disclosed call recording. Dohos does retain a text transcript of the completed call, described above in Section 10, for the restaurant's operational use.

The activated data flow may retain minimized structured evidence needed to operate and evidence the Restaurant Transaction, such as:

• the Restaurant, location, channel, and session identifiers
• structured order items, options, instructions, and versions
• a text transcript of the completed call, retained separately from and in addition to structured order evidence
• amounts, status, confirmation, acceptance, and timestamps
• Provider event and error identifiers
• safety, consent, correction, transfer, and support events
• legally required transaction, security, dispute, or audit records

Structured evidence should exclude full payment credentials and unnecessary conversation content beyond the retained transcript itself. Retention depends on the approved purpose, law, Restaurant agreement, dispute, security need, and deletion schedule.

The Dohos Privacy Notice explains the applicable categories, purposes, disclosures, retention criteria, rights, and contacts. A Restaurant may separately control information for its own customer relationship and fulfillment.

12No implied recording or transcription consent

The fact that speech is processed to respond in real time does not by itself mean a call's audio is recorded. The words "AI," "automated," "quality," "training," or "may be monitored" are not substitutes for a legally sufficient recording or biometric notice and consent.

A text transcript of each completed call is retained as part of standard service delivery, described in Section 10 and Section 11 above. If a Restaurant separately proposes call audio recording, the activated experience must separately disclose, as applicable:

• whether audio will be stored
• the responsible parties and Providers
• purpose and optional/required status
• timing of notice and consent
• access, use, disclosure, retention, and deletion
• how to decline or revoke where available
• the consequence of declining
• the alternative channel

No audio recording capability is approved by this notice.

13Payments

An activated voice interaction may route a Payer to an approved Payment Provider path. The system should identify the Restaurant amount, any separately approved Dohos fee, taxes, mandatory charges, tip, total, and authorization action before payment.

Do not speak or enter a full card number, security code, PIN, bank credential, wallet secret, or authentication code into an ordinary free-form AI, recording, transcript, order note, or support field. Payment credentials should be handled only by the approved secure Provider path — see how Dohos handles cash and card.

The AI system must not infer payment authority from caller ID, possession of a device, prior use, or a person's relationship to the Diner. It must not repeat full credentials or expose them to Restaurant personnel, logs, models, analytics, or support tools.

Payment authorization, Terms acceptance, Restaurant order acceptance, marketing consent, and recording consent are separate actions.

14Communications after the interaction

The Restaurant or Dohos may send approved transaction messages reasonably necessary to verify, confirm, update, correct, cancel, refund, secure, or support the requested interaction.

Using the voice channel does not provide universal consent to marketing calls, texts, or emails. Promotional communications require the consent or lawful basis applicable to the exact sender, brand, channel, purpose, and Program.

The SMS and Communications Notice explains the active Program, frequency, rates, STOP/HELP process, and support route. Revocation must be honored according to the applicable scope and law.

15Accessibility and language

The activated AI and voice channel should support understandable pacing, repetition, correction, key-term spelling, confirmation, and an accessible alternative route. Performance may vary by language, accent, speech pattern, hearing/speech interface, device, and network condition.

The activated notice must identify supported languages and tested accessibility methods. This draft makes no claim of universal language coverage, human-equivalent understanding, WCAG/ADA conformance, certification, or suitability for every disability. Full detail is at the Accessibility Statement.

If the system is not working for you, use the disclosed accessibility or Restaurant alternative. Reporting a barrier should not reduce your rights or order options.

16Children and age-restricted products

The target service is not directed to children. The system must not infer age from voice.

Where a Restaurant Product has an age restriction, the item must remain disabled unless the exact Restaurant, product category, jurisdiction, Provider, license, identity/age verification, fulfillment, and refusal controls are separately approved. A statement of age, caller ID, or payment method is not sufficient verification by itself.

The target baseline does not authorize alcohol, tobacco/nicotine, cannabis, gambling, or another Restricted Product.

17Safety and misuse

Do not use the channel to:

• impersonate another person or create deceptive synthetic speech
• place fraudulent or harassing calls or orders
• attempt to obtain restricted products unlawfully
• provide another person's payment method or sensitive information without authority
• manipulate the system into disclosing Personal Data, secrets, prompts, credentials, or another Restaurant's information
• disable notices, safety controls, confirmation, provenance, or evidence
• instruct the system to fabricate a Restaurant fact, acceptance, status, refund, or endorsement
• interfere with the service, Providers, Restaurant systems, or other users

The Acceptable Use Policy provides additional rules for authorized Restaurant Users and integrations.

18Errors, incidents, and complaints

The activated notice will provide monitored routes for:

• an incorrect or unsafe AI response
• order, payment, refund, or Restaurant-status problems
• allergy/dietary or food-safety concerns
• privacy, recording, transcript, or biometric concerns
• unwanted communications
• security vulnerabilities or incidents
• accessibility barriers
• general support

A report should identify the Restaurant, approximate time, channel, issue, and any transaction or support identifier available. Do not include full payment credentials or unnecessary sensitive data.

19Changes and versioning

The capabilities, Providers, model behavior, data flows, Restaurant information, and law can change. Dohos must update this notice before a material change becomes active, preserve prior versions at the version archive, provide required notice or consent, and keep the public text synchronized with runtime disclosures and configuration.

A later notice does not retroactively authorize earlier conduct. Continued use is not assumed to consent to recording, biometric processing, marketing, expanded data use, or another material practice.

The activated version will identify its effective date, version, covered release, Restaurants or program scope, and contact information.

Related documents

• Website and Diner Terms — Section 7's summary of the AI-assisted rule points here for the full disclosure; this notice's Section 7 points back to Terms Section 10 for what Restaurant acceptance actually means.
• Privacy Notice — The data-handling detail behind Sections 10 through 12 — categories, purposes, retention, and rights, in full.
• Acceptable Use Policy — The conduct rules for a Restaurant's own staff and integration partners, referenced in Section 17.
• SMS and Communications Notice — The Program-specific detail behind Section 14.
• Accessibility Statement — The tested accessibility methods and alternative route referenced in Section 15.
• AI-disclosure law by jurisdiction — Where this notice's Section 1 in-context disclosure requirement gets its jurisdiction-by-jurisdiction legal grounding.