This is a proposed public claims-and-limitations notice for a future U.S. Dohos service. It is not current, approved, effective, or evidence that any Restaurant, feature, integration, Provider, model, performance result, security control, certification, payment flow, jurisdiction, or service level is available. The future Dohos legal entity, release, customer scope, evidence, Providers, pricing, support, and public claims remain unverified. This draft must not be published until every statement is tied to current release-specific evidence and every activation condition is satisfied.
01Purpose
This notice explains how to interpret public statements about an activated Dohos service, including:
- which capabilities are actually available
- which capabilities are conditional, disabled, demonstration-only, or future
- the role of Restaurants and Providers
- limits of AI-assisted interactions
- service, accuracy, integration, payment, security, privacy, and accessibility boundaries
- how metrics, examples, testimonials, and forecasts should be understood
- how to report a claim that does not match the product
It supplements, but does not replace, transaction-specific disclosures, the Website and Diner Terms, Privacy Notice, Restaurant agreement, Order Form, or an activated service-level commitment.
02Release-specific truth controls
A capability is available only when all of the following are true:
- the specific Dohos legal entity is authorized to provide it
- it is listed in the Restaurant's activated Order Form
- the Restaurant, locations, channels, and jurisdictions are approved
- required Providers, accounts, contracts, registrations, and configurations are active
- product, safety, privacy, security, payment, accessibility, support, and legal gates pass
- the live release implements the capability
- required notices, consents, authorizations, and evidence operate
- the Activation Record has not expired, been suspended, or been superseded
The following do not prove availability:
- source code, database tables, flags, migrations, environment-variable names, packages, mock data, screenshots, design files, test fixtures, demos, videos, roadmaps, or internal documents
- a Provider logo, public documentation, or contract
- a feature used by a different Restaurant, release, channel, or jurisdiction
- a live page that has not been reconciled with the running service
- a sales statement without an approved evidence record
03Capability states
The activated service should use the following controlled states:
| State | Meaning |
|---|---|
| Activated | Approved and evidenced for the exact entity, Restaurant, capability, Provider, jurisdiction, release, and time |
| Conditional | May activate only when identified prerequisites pass; not usable merely because visible |
| Disabled | Technically and operationally unavailable for the relevant scope |
| Demonstration | Illustrative nonproduction experience using approved test data and clearly labeled limits |
| Future | Proposed or planned; no availability, date, price, or result commitment |
| Suspended | Previously activated scope temporarily unavailable due to risk, law, Provider, incident, contract, or evidence failure |
| Retired | Removed from new use with historical records, data, claims, access, and Provider exit addressed |
Public pages, sales materials, demos, product interfaces, contracts, support, and runtime disclosures must use the same state.
04Target launch capability boundary
Subject to activation, the target initial service may provide a Restaurant-focused, AI-assisted channel that helps receive Restaurant-approved information, structure an Order Request, read it back, obtain the approved confirmation, and route it to the Restaurant.
The target initial boundary does not by itself include:
- raw audio recording beyond a Restaurant's separately enabled and disclosed call recording
- Voiceprints or biometric identity
- emotion or sensitive-trait inference
- general model training on Restaurant or Diner interaction content
- autonomous Restaurant acceptance, refund, substitution, or unrestricted action
- Dohos as seller of Restaurant Products
- Dohos as food preparer, delivery provider, bank, wallet, escrow, stored-value issuer, money transmitter, emergency service, healthcare provider, or legal/tax adviser
- Platform Charges or arbitrary control of Restaurant funds
- alcohol, tobacco/nicotine, cannabis, gambling, gift cards/stored value, or another Restricted Product
- outbound marketing calls, texts, or emails
- advertising tracking, retargeting, sale/share of Personal Data, or cross-Restaurant profiling
- any POS, CRM, calendar, loyalty, delivery, or other integration not separately approved
This boundary is a target design, not proof of current or historical behavior.
05Restaurant dependencies
The Restaurant supplies or approves material Restaurant Content and controls its sale and fulfillment, including:
- identity, location, hours, and contact details
- menu, items, quantities, options, prices, discounts, and availability
- ingredients, major allergens, dietary attributes, cross-contact information, and preparation
- taxes, Restaurant fees, tips, policies, and promotions
- order acceptance or rejection
- preparation, packaging, substitutions, pickup, and Restaurant-controlled delivery
- refund/cancellation decisions and Restaurant support
- licenses and compliance applicable to Restaurant operations
Dohos may validate, format, route, or present this information but cannot guarantee that every Restaurant statement is complete or current. The service must preserve provenance, identify uncertainty, and stop or escalate a material contradiction.
Restaurant responsibility does not excuse a Dohos error in transcription, transformation, calculation, interface, confirmation, routing, payment integration, claim, or support.
06AI-assisted limitations
An AI-assisted system can misunderstand speech, produce inaccurate text, select the wrong source, omit context, generate an unsupported answer, or fail due to model, network, Provider, device, language, noise, accent, or configuration conditions.
The activated system should:
- identify itself as automated or AI-assisted
- use approved Restaurant sources
- ask clarifying questions rather than guess
- preserve material wording and provenance
- provide correction and final review
- distinguish request, receipt, Restaurant acceptance, preparation, and fulfillment
- refuse unsupported or unsafe actions
- provide the approved human or alternative fallback
Natural-sounding speech, high confidence, a citation, or prior accuracy does not guarantee correctness.
The service is not intended as the sole basis for allergy, dietary, medical, legal, tax, financial, emergency, safety-critical, or high-impact decisions.
07Order accuracy and confirmation
Before submission, the Diner should receive the exact Restaurant, location, items, options, instructions, fulfillment, price, taxes, mandatory fees, tip, total, material policy, and submission effect in an accessible and understandable form.
The Diner must have a practical way to correct the information and take the approved affirmative confirmation action.
Dohos does not claim that:
- every spoken word will be recognized correctly
- every Restaurant source is current
- an Order Request will be accepted
- an estimate is guaranteed
- a Restaurant can accommodate an allergy or dietary request
- an automated acknowledgment is Restaurant acceptance
Review the final information and use the disclosed Restaurant or support route when it is inaccurate or incomplete.
08Allergens, dietary information, and food safety
Restaurant ingredients, recipes, suppliers, substitutions, preparation spaces, and cross-contact conditions can change. A menu label or AI response cannot guarantee safety for a particular person.
The activated service may relay Restaurant-approved information and a Diner instruction, but Dohos does not prepare, inspect, package, or handle Restaurant Products under the target model.
A serious allergy, dietary, medical, or food-safety question should be confirmed directly with the Restaurant through an approved channel. If the Restaurant cannot provide enough information, do not rely on the automated service for the decision.
09Availability and reliability
Service can be interrupted, delayed, degraded, filtered, or unavailable because of maintenance, demand, software defects, cyber events, Restaurant systems, Providers, carriers, networks, power, devices, weather, legal restrictions, or other conditions.
Dohos does not claim:
- uninterrupted or error-free operation
- universal geographic, Restaurant, number, browser, device, language, or assistive-technology coverage
- guaranteed call answer, message delivery, transfer, response, order acceptance, preparation, pickup, or delivery
- a recovery, uptime, latency, or support target not stated in an activated customer agreement
- that a Provider service level is a Dohos end-to-end commitment
An activated service-level agreement must define scope, measurement source, exclusions, credits/remedies, and dependencies. A marketing percentage does not create an SLA unless validly incorporated. See the Service Level Agreement for the actual commitment once one exists.
10Performance claims and metrics
A public performance claim must state or link to enough context to prevent deception, including:
- metric definition and denominator
- population, Restaurants, locations, calls/orders, languages, and channels
- measurement period and release/model/Provider versions
- baseline or comparison
- exclusions, failures, abandoned interactions, and human intervention
- data quality and statistical uncertainty
- whether the result is observed, tested, estimated, modeled, or projected
- owner, evidence, expiry, and last review
- whether the result is typical or exceptional
Dohos must not use an unqualified claim such as "99% accurate," "never misses a call," "eliminates errors," "saves a stated amount," "increases revenue," "pays for itself," or "works for every Restaurant" without current representative evidence and approved qualifiers.
A pilot, synthetic test, internal benchmark, cherry-picked Restaurant, or Provider benchmark must not be presented as general customer performance.
11Forecasts and return on investment
Forecasts, savings, revenue impact, labor impact, conversion, order value, cost reduction, speed, or return on investment depend on Restaurant operations, demand, staffing, menu complexity, channel mix, existing systems, implementation, adoption, pricing, Providers, and measurement choices.
The activated material must clearly distinguish:
- historical verified result
- illustrative example
- customer-specific estimate
- contractual commitment
- forward-looking target
An estimate should document assumptions and allow a Restaurant to test them. It is not a guarantee. Dohos must not fabricate urgency, scarcity, customer counts, pipeline, funding, launch status, or cost comparisons. See the pricing estimate for how this rule is enforced where it matters most — the one place the public site invites a Restaurant to model its own numbers.
12Demonstrations, prototypes, and previews
A demonstration, prototype, mockup, sandbox, video, screenshot, or preview must be clearly labeled before a person reasonably relies on it.
The label should identify material differences from production, such as:
- simulated Restaurant/data
- scripted or human-assisted responses
- disabled payment, communications, recording, or integration behavior
- nonproduction Provider/model
- limited language or accessibility testing
- no Restaurant acceptance or fulfillment
- estimated latency or availability
- features not included in the proposed Order Form
Demo data must be authorized and must not include real Personal Data, payment credentials, secrets, or another Restaurant's confidential information unless a separately approved protected test permits it.
A successful demo does not prove production readiness, scale, reliability, security, accessibility, compliance, or customer result. See the product demo for how Dohos labels its own examples under this rule.
13Integrations
An integration is available only when the exact Provider/product, account, authorization scopes, data, read/write actions, configuration, Restaurant, release, security, privacy, support, rollback, and contract are approved.
Dohos must not claim "integrates with," "works with," "native," "real time," "automatic," or "two-way" based only on:
- an API's existence
- a logo
- an SDK/package
- a proof of concept
- an import/export file
- a roadmap item
- a different customer's implementation
The activated description must state material limits, customer work, supported versions, direction of data, latency, errors, authority, and fallback.
A Provider may change or suspend an API. Dohos must not promise perpetual compatibility. See the integrations directory for the actual, honestly stated status of any named system.
14Providers and third-party names
Dohos may use approved Providers for cloud, database, AI, communications, payment, monitoring, support, or other functions. A Provider name or logo may be used publicly only with verified actual use, approved role wording, current contract/configuration, trademark permission where needed, and release evidence.
A Provider relationship does not mean:
- the Provider endorses Dohos
- Dohos is certified by the Provider
- every Provider product or feature is used
- the Provider guarantees Dohos's end-to-end service
- the Provider is a Subprocessor for every data flow
- the Provider's public terms are the contract accepted by Dohos
The activated Subprocessor List, Privacy Notice, payment disclosure, and customer contract provide role-specific information.
15Payment claims
Dohos must not claim "we never touch funds," "Restaurant is merchant of record," "Stripe handles everything," "PCI compliant," "instant refunds," or similar payment language without verifying the exact entity, Provider account, charge type, merchant allocation, credentials, funds flow, losses, disputes, refunds, descriptors, receipts, PCI scope, and live transactions.
Under the target model, the Restaurant is the seller and target Payment Provider merchant for Restaurant direct charges, while Platform Charges and arbitrary funds control remain disabled. This is a target architecture, not current-state proof.
The Order, Payment, Refund, and Dispute Notice explains the activated transaction.
16Privacy and data-use claims
Dohos must not claim "we never store data," "anonymous," "zero retention," "no training," "no sale," "no tracking," "U.S.-only," or similar language unless the exact data, purpose, system, Provider, account, feature, logs, backups, regions, retention, support access, and historical practice support it.
The activated Privacy Notice, Cookie Notice, Subprocessor List, and AI and Voice Transparency Notice control the detailed verified description.
17Security and compliance claims
Dohos must not claim secure, encrypted, compliant, certified, audited, enterprise-grade, bank-grade, military-grade, SOC, ISO, PCI, HIPAA, FedRAMP, GDPR, CCPA, ADA, WCAG, or similar status without a current scoped evidence record and counsel/specialist approval.
A Provider's report or certification does not automatically cover Dohos. A policy, scan, test, or control design does not by itself establish operating effectiveness.
The activated security posture should make only narrow evidence-backed claims and identify material scope/limits.
18Accessibility and language claims
Dohos intends to make activated services usable by people with disabilities, but this draft makes no conformance, certification, universal-compatibility, device, assistive-technology, or language-coverage claim.
The activated Accessibility Statement must identify the tested scope, methods, environments, known limitations, alternatives, and support route. An automated scan alone is not proof.
19Testimonials, reviews, logos, and case studies
A testimonial, review, customer logo, Restaurant name, quote, case study, rating, award, endorsement, or influencer statement must have:
- permission and authority where required
- authentic source and content
- disclosure of material connection or incentive
- substantiation for objective claims
- representative or clearly qualified results
- current customer/status and dates
- review for privacy/confidentiality/IP
- expiry, withdrawal, and correction controls
Dohos must not suppress an honest review, condition a lawful refund on removing criticism, create fake reviews, selectively omit a material limitation, or imply endorsement from a Provider, regulator, Restaurant, investor, customer, or partner that did not approve it.
20Pricing and offer claims
Public and sales pricing must identify the responsible legal entity, intended customer, included capabilities, units/limits, implementation, Provider/pass-through charges, taxes, fees, term, recurring nature, renewal, cancellation, refunds/credits, and material conditions.
Dohos must not use a nonexistent former price, hidden mandatory fee, false limited-time offer, unsupported savings comparison, prechecked add-on, or a headline price unavailable to the intended customer.
Restaurant-specific pricing belongs in the activated Order Form. Public examples must be labeled and must not override the signed commercial terms. See Pricing for the plans this rule governs.
21Roadmaps and future-looking statements
Roadmaps, target dates, planned capabilities, Provider discussions, jurisdictions, integrations, and design concepts are uncertain and may change.
A future-looking statement must be clearly labeled, must not be used to create a false current capability, and must not promise a release date, price, result, or contract commitment unless authorized in a signed agreement.
Dohos should not collect payment, consent, or reliance for a future capability without truthful disclosure of its status, dependencies, cancellation/refund treatment, and risk.
22Sales, support, AI, and oral statements
Claims by founders, employees, contractors, affiliates, sales personnel, support, Restaurants, AI agents, demos, presentations, social media, emails, calls, and messages can create exposure even when absent from the website.
Authorized representatives may state only claims in the current approved claims register for the exact audience and context. They must not:
- improvise unsupported capabilities or outcomes
- hide a material limitation
- claim legal, technical, accessibility, security, tax, payment, or regulatory approval outside authority
- promise a contract term not in the approved document
- use confidential customer information
- present a target-state document as current
An unapproved oral statement is not made accurate by a later disclaimer. Dohos should correct material misinformation promptly.
23Intellectual property and content rights
Dohos must not claim ownership of Restaurant Content, Diner content, Provider models, generated output, code, marks, or data beyond the rights supported by applicable contracts and law.
Terms such as "our data," "our AI," "proprietary," "patented," "copyrighted," "exclusive," and "licensed" require precise evidence. A prompt, configuration, workflow, or compilation may involve multiple rights and limitations.
A third-party name, menu, image, logo, voice, testimonial, or model output must not be used without the required authority and disclosure.
24Geographic and legal coverage
The proposed portfolio is U.S.-focused. Availability in one state, a U.S. phone number, or a public website does not mean every state/local rule, Restaurant license, communications registration, payment method, tax rule, privacy right, restricted product, or accessibility method is supported.
The activated service must gate each Restaurant, location, number, channel, capability, Provider, and jurisdiction through the approved matrix.
Dohos must not claim "50-state," "nationwide," "fully compliant," "legal everywhere," or similar coverage without current counsel-approved evidence.
25Product changes, suspension, and retirement
A capability may be changed, limited, suspended, or retired due to safety, security, law, Provider, Restaurant, evidence, performance, abuse, continuity, or contract issues.
Dohos must provide the notice, support, data export/return, transition, refund/credit, consent, or contract process required for the exact relationship. It must not silently leave a public claim active after a capability is disabled.
Historical claims and versions must be preserved. Removing a page does not erase prior reliance or liability.
26Reporting an inaccurate claim
The activated notice will provide monitored routes for a person or Restaurant to report:
- a public statement that does not match the service
- a sales or demo claim
- an AI-generated false capability or status
- a Provider/logo or certification concern
- an incorrect Restaurant, payment, privacy, security, accessibility, or integration statement
- an outdated price, metric, testimonial, or roadmap claim
- a mismatch between live behavior and legal documents
The process should preserve the claim, location, audience, dates, evidence, affected releases/customers, corrective action, notification, and outcome. It must not retaliate against a good-faith report or honest review.
27Changes to this notice
Dohos must update this notice when capabilities, states, Providers, models, integrations, claims, evidence, law, or documents change.
The activated version must identify its effective date, version, covered release/scope, legal entity, and contacts. Prior versions, claims, evidence, approvals, and corrections must be retained at the version archive. A later limitation does not retroactively cure an earlier misleading statement.