Dohos Service Level and Support Schedule

TARGET-STATE DRAFT — NOT APPROVED OR EFFECTIVE

This is proposed contract text for future service-level and support obligations between an identified Dohos legal entity and an identified Restaurant. It is not approved, executed, incorporated, or effective and is not evidence of uptime, latency, accuracy, response, restoration, resolution, support hours, staffing, monitoring, maintenance, credits, recovery objectives, or Provider performance. No covered service, measurement system, target, exclusion, remedy, contact, or chronic-failure threshold has been verified. This draft must not be signed, quoted, or used as a service claim until every execution schedule and activation condition is complete.

Proposed schedule

This Service Level and Support Schedule (Schedule) forms part of the Restaurant Services Agreement between the Dohos legal entity identified in an executed Order Form (Dohos) and the Restaurant legal entity identified in that Order Form (Restaurant). It applies only when the Order Form identifies this Schedule by stable title, ID, version, and date and completes all applicable annexes.

1. Purpose and scope

1.1 Covered Service

This Schedule applies only to the exact Production Capabilities, Restaurants, locations, channels, regions, release, and Subscription Term identified in Annex 1 (Covered Service).

No service level applies to:

• a Disabled, demonstration, development, test, preview, beta, experimental, future, suspended, or retired Capability;
• a Restaurant or location not listed in the Order Form;
• an integration, Provider, number, domain, model, payment account, or Program not listed in Annex 1;
• a Diner's or Restaurant's independent device, network, system, premises, personnel, or Provider account; or
• a metric or obligation not expressly completed in this Schedule.

1.2 Service commitments only

This Schedule governs contractual availability, incident support, maintenance, reporting, and service-credit terms for the Covered Service. It does not replace:

• the Security Addendum or Security Incident process;
• the DPA or privacy request/incident duties;
• the AI and Voice Service Schedule or accuracy/safety evaluation;
• the Communications Program Schedule or carrier/consent duties;
• the Payments Schedule or payment/refund/dispute obligations;
• the Implementation Schedule or acceptance criteria; or
• non-waivable legal duties and remedies.

1.3 No Provider pass-through by implication

A Provider's public or contracted service level is not Dohos's end-to-end commitment unless Annex 1 expressly incorporates a measured dependency and the Order Form states the resulting Dohos obligation and remedy.

2. Definitions

Availability means the percentage calculated under Section 4 for the applicable Covered Service and Measurement Period.

Available Minute means a minute during which the Covered Service meets the exact functional availability criteria in Annex 1 for the applicable Restaurant scope.

Downtime means a minute during which the Covered Service fails the applicable availability criteria, excluding only an approved Excluded Minute.

Excluded Minute means a minute meeting a specific exclusion in Section 5 and Annex 1, supported by evidence.

Maintenance Window means an approved period for Scheduled Maintenance stated in Annex 2.

Measurement Period means the calendar month or other exact period stated in Annex 1, with a stated time zone.

Production Incident means an unplanned event that degrades or interrupts the Covered Service or creates an incorrect material service state. A Production Incident may also be a Security Incident, privacy incident, payment incident, communications incident, or safety issue; the stricter applicable process controls.

Response Time means elapsed time from valid support-case receipt or Dohos detection, as defined in Annex 3, until qualified personnel acknowledge ownership and begin triage. An automated receipt alone is not a qualified response unless the execution copy expressly and fairly provides otherwise.

Restoration Time means elapsed time from the defined start event until the affected Covered Service is restored to the stated functional level or an approved safe workaround provides the agreed essential function.

Resolution Time means elapsed time from the defined start event until the underlying issue is corrected and verified according to the closure criteria in Annex 3.

Scheduled Maintenance means planned work within an approved Maintenance Window after required notice and controls.

Service Credit means a contractual credit calculated under the completed Annex 4. It is not cash, a refund, a penalty, or an exclusive remedy except to the extent the execution copy expressly and lawfully states.

Support Hours means the staffed hours, days, holidays, time zone, and channels stated in Annex 2.

Other capitalized terms have the meanings in the governing contract documents.

3. Service specification and measurement boundary

3.1 Functional availability criteria

Annex 1 must define what “available” means for each material Capability through observable functional criteria, such as whether authorized users can:

• authenticate and access the Restaurant Account;
• retrieve and update approved Restaurant Content;
• receive an inbound call or web interaction;
• complete AI-assisted understanding and response within approved limits;
• review and confirm an Order Request;
• route the request to Restaurant;
• record Restaurant acceptance or rejection;
• route an approved payment action to the Payment Provider;
• send a transaction communication; or
• access support, export, privacy, security, cancellation, and other protected routes.

A health endpoint, server response, login page, or Provider dashboard alone is not proof that an end-to-end Capability is available.

3.2 Component versus end-to-end metrics

Annex 1 must distinguish:

• component availability;
• API availability;
• channel reachability;
• transaction success;
• Restaurant integration success;
• Provider success;
• end-to-end user success; and
• safe fallback availability.

Dohos will not use a healthy component to mask failure of the committed end-to-end function.

3.3 Scope dimensions

Measurement will be attributable by applicable:

• Restaurant and location;
• Capability and channel;
• region and Provider;
• release/configuration;
• incident and cause;
• time period/time zone;
• request volume and denominator; and
• maintenance/exclusion category.

3.4 Material correctness

A service that responds but produces a materially wrong, unsafe, unauthorized, cross-tenant, duplicate, or corrupted state may be unavailable for the applicable function.

Examples may include an order sent to the wrong Restaurant, inability to correct/confirm, duplicate charge, false Restaurant acceptance, broken opt-out, or inaccessible material transaction route, depending on the completed criteria.

3.5 Partial degradation

Annex 1 must define how partial failure is measured, including:

• affected percentage or tenant scope;
• loss of a material feature;
• severe latency;
• elevated error rate;
• fallback behavior;
• wrong or unsafe output;
• regional/Provider failure; and
• whether each affected minute counts fully, proportionally, or under another approved method.

No partial-credit method may conceal a complete failure for the affected Restaurant.

4. Availability calculation

4.1 Formula

Unless the completed Annex 1 uses a more specific approved formula:

Availability = ((Total Eligible Minutes − Downtime Minutes) ÷ Total Eligible Minutes) × 100

Total Eligible Minutes means all minutes in the Measurement Period for which the Covered Service is contractually scheduled to operate, less only approved Excluded Minutes.

The execution copy must state rounding, precision, aggregation, time zone, leap/daylight-saving handling, partial minutes, Restaurant weighting, and insufficient-data treatment.

4.2 Target

The Availability target for each Covered Service must be inserted in Annex 1 after measurement and operational validation.

No target percentage is approved or implied in this draft. A missing target is an activation block.

4.3 Source of truth

Availability will be calculated from the approved combination of:

• end-to-end synthetic probes;
• application/service telemetry;
• transaction and state events;
• Provider events;
• channel/carrier/payment evidence;
• Restaurant reports corroborated by available evidence; and
• incident and maintenance records.

The execution copy must identify the authoritative source and reconciliation process. Dohos-controlled telemetry will not be conclusive when it is unavailable, incomplete, contradicted, or incapable of observing the failed user function.

4.4 Monitoring coverage

Dohos will maintain monitoring adequate for the committed metrics and will disclose material blind spots in Annex 1.

Monitoring failure does not automatically convert unobserved time to Available Minutes. The approved insufficient-evidence rule must avoid rewarding under-monitoring.

4.5 Reports

Dohos will provide Restaurant the service-level report stated in Annex 5 with:

• period and Covered Service;
• target and measured result;
• incidents and affected scope;
• Scheduled/Emergency Maintenance;
• exclusions and evidence;
• credits and chronic-failure status;
• material monitoring limitations; and
• corrective actions where appropriate.

5. Exclusions

5.1 General standard

A minute may be excluded only when Dohos proves that the exclusion applies, the excluded cause materially produced the failure, Dohos did not cause or unreasonably contribute to it, and Dohos used reasonable mitigation and communication.

An exclusion will be limited to the affected scope and duration.

5.2 Potential exclusions

The execution copy may approve narrowly defined exclusions for:

• Scheduled Maintenance within the disclosed budget and notice rules;
• Emergency Maintenance meeting Section 6.4;
• Restaurant-controlled systems, data, credentials, devices, networks, personnel, or unauthorized configuration;
• Diner-controlled devices, carriers, networks, or unsupported use;
• a separately contracted Restaurant Provider outside Dohos's integration control;
• force majeure meeting the Restaurant Services Agreement standard;
• suspension required by law or caused by Restaurant's material breach;
• use outside documented Specifications, capacity, jurisdictions, or activated scope; and
• a test or security exercise Restaurant performs without required authorization.

5.3 Non-excludable Dohos causes

Dohos may not exclude time to the extent caused by:

• Dohos's code, architecture, configuration, access, deployment, capacity, monitoring, or support failure;
• a Provider Dohos selected/configured without the required diligence, redundancy, change, or exit controls;
• an expired certificate, secret, key, domain, registration, model, account, contract, quota, or evidence within Dohos's responsibility;
• Dohos's failure to apply an available required patch or mitigation;
• an unauthorized change or Security Exception within Dohos's control;
• a Scheduled Maintenance event exceeding the approved window or scope;
• a fallback that is unavailable or unsafe contrary to the contract; or
• a cause the Agreement expressly allocates to Dohos.

5.4 Provider failures

A Provider failure is not automatically excluded. Annex 1 must state how each material dependency affects end-to-end availability and which failures are included, excluded, or separately measured.

Dohos remains responsible for reasonable Provider selection, configuration, monitoring, capacity, continuity, and communication within its control.

5.5 Restaurant-caused events

Before excluding a Restaurant-caused event, Dohos will identify the Restaurant-controlled act/omission, affected scope, causal evidence, available warning or guardrail, and mitigation.

Dohos may not rely on Restaurant error where Dohos's interface, instruction, validation, permission, integration, or misleading statement materially contributed.

5.6 Security and privacy events

A Security Incident, attack, fraud event, or legal suspension is not automatically excluded. The execution copy must allocate availability treatment without limiting incident, privacy, payment, communications, or non-waivable remedies.

6. Maintenance

6.1 Scheduled Maintenance

Dohos may perform Scheduled Maintenance only within the approved Maintenance Windows, notice, duration budget, frequency, and affected scope in Annex 2.

Notice will identify expected start/end, affected Capabilities/Restaurants/regions, user impact, reason, fallback, support, and status route.

6.2 Maintenance controls

Dohos will plan, review, test, monitor, and prepare rollback for material maintenance. Work will minimize disruption and avoid known critical Restaurant periods where reasonably practical.

6.3 Overrun

Time outside the approved Maintenance Window or duration budget counts as Downtime unless another specific exclusion applies.

6.4 Emergency Maintenance

Dohos may perform Emergency Maintenance outside a scheduled window when reasonably necessary to address an urgent security, safety, legal, Provider, data-integrity, or continuity risk.

Dohos will provide as much advance notice as practicable, identify scope and fallback, monitor, restore/rollback promptly, and complete a post-change review.

Emergency Maintenance does not automatically become Excluded Minutes; Annex 2 must state the approved treatment and annual/periodic budget if any.

6.5 Restaurant maintenance and changes

Restaurant will coordinate Restaurant-controlled system, integration, menu, network, payment-account, number, or credential maintenance that could affect the Covered Service. Dohos will provide reasonable change guidance and testing for integrated dependencies as stated in the Implementation Schedule.

7. Support access and channels

7.1 Support channels

Annex 2 must identify monitored channels for:

• general support;
• Priority 1/urgent incidents;
• security incidents and vulnerabilities;
• privacy/DPA/rights matters;
• payment/refund/dispute issues;
• communications consent/STOP/HELP/complaints;
• AI/voice safety and incorrect-output issues;
• accessibility barriers;
• Restaurant Content/order/fulfillment routing; and
• contract/billing notices.

No email, telephone number, portal, or hours are approved in this draft.

7.2 Authentication and authority

Dohos may verify the requester and authority proportionate to the requested action. Support will not disclose data, change payment/communications settings, export/delete data, or grant access solely because a person knows an email, number, order ID, or Restaurant name.

Emergency security protection may occur before full verification where necessary, but restoration or disclosure requires the approved process.

7.3 Accessible support

Support channels, legal notices, incident updates, and remedies will be available through approved accessible methods. A Restaurant will not lose a right solely because an authorized person cannot use a particular channel.

7.4 Support data

The Parties will minimize support data. Restaurant will not submit Payment Credentials, secrets, unnecessary Personal Data/Sensitive Data, raw recordings, or another person's data without authority.

Dohos will protect support access, attachments, logs, screen sharing, impersonation, exports, retention, and Provider use under the Security Addendum and DPA.

7.5 Language and location

The execution copy must state supported support languages, time zones, holidays, and geographic limitations without claiming universal coverage.

8. Incident priority and classification

8.1 Completed matrix required

Annex 3 must define priority using user/Restaurant scope, critical function, data/security/safety/payment impact, workaround, duration, recurrence, and legal/Provider urgency.

No priority or target is implied by a label alone.

8.2 Target priority structure

The execution copy may adapt this structure:

Security, privacy, payment, communications, allergy/safety, or accessibility severity may require a higher process regardless of availability priority.

8.3 Initial and revised priority

Either Party may propose a priority. Dohos will promptly assess it and explain a material downgrade. Priority may change as evidence develops, with reason, time, approver, affected targets, and communications preserved.

Downgrading a ticket does not erase missed targets that occurred while the higher priority properly applied.

8.4 Related cases

Dohos may link duplicate reports to a master incident while preserving each Restaurant's affected scope, receipt time, communications, evidence, credit, and remedies.

9. Response, restoration, resolution, and updates

9.1 Targets

Annex 3 must state for each priority and Support Hours model:

• valid receipt/detection start event;
• Response Time target;
• initial assessment target;
• update cadence;
• workaround target if any;
• Restoration Time target if any;
• Resolution Time target if any;
• escalation threshold;
• closure criteria; and
• clock pause rules.

No target duration is approved in this draft.

9.2 Response content

A qualified response will identify case/incident ID, owner, understood impact, priority, next step, needed safe evidence, expected update, and available fallback.

An automated acknowledgment may confirm receipt but does not satisfy a qualified Response Time unless Annex 3 expressly says so for a lower-priority case.

9.3 Restoration versus resolution

A workaround or restoration must be safe, lawful, accessible, and materially usable. It may not bypass confirmation, tenant isolation, payment security, consent/suppression, privacy, or other required controls.

Restoration does not close root-cause remediation. Resolution requires correction, validation, monitoring, documentation, and affected-case updates under the completed closure criteria.

9.4 Clock pauses

The support clock may pause only when Restaurant action or information is genuinely necessary and Dohos has clearly requested it. The pause is limited to the blocked activity and ends when information is received or Dohos can reasonably proceed another way.

Dohos will not use repeated or irrelevant information requests to stop the clock.

9.5 Updates

For material incidents, updates will state current impact, affected scope, changes, mitigation, fallback, next actions, known limitations, and next update time.

Dohos will correct material inaccuracies and will not claim resolution before end-to-end verification.

10. Restaurant support responsibilities

Restaurant will:

• use authorized support contacts and channels;
• identify Restaurant/location, affected Capability, time, impact, and available case/order IDs;
• provide safe reproduction steps and relevant evidence;
• preserve and not manipulate material logs/records within its control;
• maintain current escalation contacts;
• cooperate with reasonable testing and mitigation;
• operate Restaurant-controlled fallback, user, device, network, integration, payment-account, and Restaurant Content responsibilities; and
• avoid sending Payment Credentials, secrets, or unnecessary sensitive data.

Restaurant need not prove root cause before reporting and is not responsible for evidence only Dohos or a Provider controls.

11. Dohos support responsibilities

Dohos will:

• staff the approved channels and Support Hours;
• authenticate appropriately and protect support data;
• triage, own, escalate, investigate, and communicate cases;
• distinguish Dohos, Restaurant, Provider, Diner, payment, communications, privacy, security, and fulfillment ownership;
• preserve evidence and release/configuration context;
• provide safe mitigation/fallback where available;
• coordinate material Providers;
• correct Dohos-controlled defects and misleading status;
• verify restoration/resolution from the affected end-to-end perspective; and
• track root cause and corrective actions for material/recurrent incidents.

Dohos will not close a case solely because a Provider ticket is open or a component dashboard is healthy.

12. AI and voice service levels

12.1 Separate metrics

Voice reachability, speech recognition, response latency, AI accuracy, source grounding, order correction/confirmation, transfer/fallback, and Restaurant acceptance are distinct metrics.

Availability does not imply accuracy or safety. Accuracy does not imply availability.

12.2 No universal accuracy promise

No AI/speech accuracy, hallucination, completion, automation, containment, latency, language, or human-equivalence target applies unless Annex 1 defines:

• metric and denominator;
• dataset/population/Restaurant/menu/language/channel;
• model/prompt/source/Provider/release versions;
• exclusions and human intervention;
• measurement period and statistical limits;
• safety/error weighting;
• target and remedy; and
• reevaluation/change gate.

12.3 Safety priority

An unsafe or unsupported response, allergen error, wrong Restaurant/order, ambiguous confirmation, cross-tenant disclosure, or unauthorized action may be a Priority 1 or other designated incident regardless of aggregate uptime.

12.4 Provider/model changes

A model, Provider, region, speech, prompt/tool, source, or safety change must pass the AI/Voice Schedule evaluation and may alter service-level measurement only through the contract change process.

13. Communications service levels

Carrier acceptance, Provider acceptance, sent status, delivery, handset receipt, read status, recipient identity, and recipient action are distinct.

No delivery guarantee applies unless the execution copy defines the exact metric and evidence. Carrier filtering, reassignment, device/network conditions, and recipient opt-out may affect delivery, but Dohos remains responsible for Program configuration, registration, suppression, retries, content, and Provider oversight within its control.

A failed message does not automatically cancel or modify an Accepted Order, payment, privacy request, or other duty. The activated fallback controls.

STOP/HELP, unlawful communications, wrong-recipient disclosure, and suppression failures follow the Communications Schedule and may require urgent priority independent of availability.

14. Payment service levels

Payment page reachability, Provider authorization, Restaurant acceptance, capture, settlement, payout, reversal, refund initiation, bank posting, dispute, and reconciliation are distinct.

No bank posting, refund receipt, payout, or dispute outcome target applies unless the Payments Schedule defines the party, state, measurement, Provider dependency, evidence, and remedy.

A duplicate/unauthorized charge, credential exposure, wrong amount, false merchant/status, or reconciliation failure follows the Payments and Security Schedules and may require urgent priority regardless of aggregate availability.

Service Credits do not replace correction/refund of an unauthorized or incorrect charge.

15. Privacy, security, accessibility, and legal incidents

Privacy Request deadlines, Security Incident notice, breach notification, communications revocation, payment dispute, accessibility accommodation, and legal/regulator duties are not ordinary support targets and are not extended by this Schedule unless law permits and the governing document expressly says so.

Dohos will route each issue to the controlling process while maintaining one coordinated customer case where appropriate.

Service Credits are not the exclusive remedy for a privacy/security/payment/communications/accessibility/legal breach unless the final contract expressly and lawfully provides.

16. Provider and dependency management

16.1 Dependency map

Annex 1 must identify each material Provider/integration dependency, its function, account/product/region, service level, support/escalation, monitoring, data, continuity, and contractual limitations.

16.2 Provider incidents

Dohos will open and manage Provider escalation, preserve Provider event/status evidence, validate scope independently where possible, and communicate end-to-end impact rather than merely link a Provider status page.

16.3 Status-page limitations

A Provider or Dohos public status page is informational and may be delayed or incomplete. The approved measurement evidence controls contract calculations.

16.4 Dependency changes

A material Provider, account, product, model, region, quota, support, service-level, subprocessor, or continuity change requires impact review. If it reduces a contractual commitment, Dohos must obtain the required amendment or maintain equivalent protection/performance.

17. Status communications

Dohos will maintain the customer incident/status communication methods in Annex 2, which may include authenticated Account notices, email/SMS to authorized contacts, a status page, or direct escalation.

Status communications must distinguish:

• investigating;
• identified;
• monitoring;
• restored;
• resolved;
• scheduled maintenance;
• security/privacy-sensitive limited disclosure; and
• historical correction.

Dohos will not disclose another Restaurant's confidential/security information, speculate without label, or state “all systems operational” when a known covered function remains materially impaired.

18. Root-cause analysis and problem management

For the priorities, durations, recurrence, or risks stated in Annex 3, Dohos will provide a root-cause or post-incident report containing, as appropriate:

• summary and scope;
• timeline;
• detection and escalation;
• technical/operational root and contributing causes;
• impact to Restaurants, Diners, data, orders, payments, communications, and Providers;
• containment, restoration, and verification;
• monitoring or process gaps;
• corrective/preventive actions, owners, and deadlines;
• residual risk and exceptions; and
• material corrections to prior communications.

The report may protect privileged, security-sensitive, Provider-restricted, and other-customer information while still providing useful facts.

19. Service Credits

19.1 Completed formula required

Annex 4 must state:

• eligible Fees and service scope;
• target bands and credit percentages or formula;
• maximum credit per Measurement Period;
• claim versus automatic application;
• claim deadline/method and required information;
• calculation and rounding;
• exclusion/incident dispute process;
• credit posting and expiration;
• multiple services/incidents aggregation;
• chronic-failure interaction; and
• tax/accounting treatment.

No credit amount, percentage, claim period, or cap is approved in this draft.

19.2 Eligibility

Restaurant is eligible only for the affected Covered Service and period, but Dohos will not require evidence that only Dohos's monitoring can provide.

If credits require a claim, the process must be accessible and reasonable. Failure to claim does not waive non-credit remedies or non-waivable rights.

19.3 Application

Credits will be applied to future Dohos Fees or handled as stated in Annex 4. They will not be deducted from Restaurant Transaction funds, tips, taxes, refunds, or Provider payouts.

19.4 Exclusive remedy

A Service Credit is an exclusive remedy for a particular availability miss only if the execution copy conspicuously and lawfully says so and identifies exceptions. It does not by default cover breach of security/privacy, payment errors, unlawful communications, fraud, willful misconduct, confidentiality/IP, data loss, or chronic failure.

20. Chronic or material failure

Annex 4 must define chronic failure based on objective combinations such as:

• repeated availability misses;
• consecutive misses;
• aggregate Downtime;
• repeated Priority 1 incidents;
• recurrence of the same root cause;
• persistent unsafe or materially inaccurate behavior;
• missed support/restoration commitments; or
• failure to complete corrective actions.

The approved remedy may include enhanced credit, remediation plan, executive review, suspension, reduction of scope, termination of affected service, and refund of prepaid unused Fees.

No chronic-failure threshold or remedy is implied by this draft.

21. Service-level disputes

Restaurant may dispute a metric, exclusion, priority, closure, credit, or report through the process in Annex 5.

Dohos will preserve and provide reasonable evidence, explain calculations and exclusions, and have a qualified reviewer not solely responsible for the disputed initial decision where appropriate.

The dispute process will not delay urgent security/privacy/payment/communications actions or bar contractual/legal remedies.

22. Changes to targets or methods

Dohos may improve monitoring without amendment if the method remains at least as accurate/protective and does not reduce a commitment.

A material change to Covered Service, metric, formula, target, exclusion, source of truth, Support Hours, priority, response/restoration, maintenance, credit, chronic-failure, Provider dependency, or remedy requires the approved contract change process.

Dohos will preserve prior versions and calculate each period under the applicable accepted version. A new method cannot retroactively improve a prior result.

23. Reporting and review

At the cadence in Annex 5, the Parties will review:

• availability and incidents;
• support volume, priorities, aging, and reopenings;
• maintenance and changes;
• Provider/dependency performance;
• AI/voice, payment, communications, privacy, security, and accessibility issues;
• credits and chronic-failure status;
• root causes and corrective actions;
• monitoring gaps and disputes; and
• upcoming releases, capacity, Restaurant events, and risk.

Metrics must not expose other customers or be used for unsupported public claims.

24. Suspension, termination, and transition

Suspension and termination follow the Restaurant Services Agreement. During a material outage or unsafe condition, Dohos will preserve approved fallback, support, evidence, privacy/security, data export, payment/refund, and Restaurant transition routes as practicable and required.

At termination, Dohos will provide final service-level reports and credits, preserve outstanding disputes/incident evidence, transfer/close support cases, and correct public/customer status.

Service-level obligations survive only as necessary for accrued reports, credits, disputes, incidents, corrective duties, and retained data; they do not create indefinite service.

25. Liability, hierarchy, and interpretation

Liability, indemnity, insurance, damages exclusions/caps, and non-waivable remedies are governed by the final Restaurant Services Agreement and Order Form.

This Schedule controls service-level/support subjects. The Security Addendum, DPA, AI/Voice, Communications, Payments, and Implementation Schedules control their specialized subjects. A credit clause does not reduce those duties unless the final agreement expressly and lawfully provides.

Mandatory law controls. A public status page, help article, sales claim, or Provider SLA does not amend this Schedule.

Annex 1 — Covered Service and availability profile

This Annex is intentionally unpopulated because no service scope, measurement system, or target is verified. The execution copy must replace each instruction with approved facts.

A. Covered Service rows

For each service-level commitment, the execution copy must state:

B. Target service dimensions

The execution copy must separately decide whether commitments apply to:

• Restaurant Account access;
• menu/Restaurant Content retrieval/update;
• inbound voice answer and session continuity;
• web interaction;
• speech recognition and response latency;
• AI source/accuracy/safety metrics;
• order review/confirmation/routing;
• Restaurant acceptance workflow;
• transaction SMS/email;
• payment-provider redirection/authorization flow;
• support/status channels;
• data export/privacy/accessibility routes; and
• Provider or integration functions.

No unchecked dimension is implied.

Annex 2 — Support, maintenance, and communication profile

The execution copy must state:

A. Support operations

B. Maintenance

C. Status communications

State authenticated/public status routes, subscription, audience, incident update cadence, historical archive, corrections, accessibility, security limitations, and owner.

Annex 3 — Incident priority and target matrix

The execution copy must provide one row per priority:

No target is created by leaving an entry absent.

Annex 4 — Service Credits and chronic failure

A. Credit formula

The execution copy must provide a table with availability/target band, affected Fee base, credit percentage/formula, cap, automatic/claim process, claim period, evidence, posting, and tax/accounting treatment.

B. Chronic failure

The execution copy must state objective thresholds, measurement periods, affected scope, remediation-plan timing, enhanced credits, suspension/termination right, prepaid Fee refund, transition, and relationship to other remedies.

C. Exceptions to exclusivity

If credits are an exclusive remedy for a defined SLA miss, list all exceptions and preserve non-waivable rights. Silence creates no exclusivity.

Annex 5 — Reports, evidence, and dispute process

The execution copy must state:

• monthly/quarterly or other report cadence;
• report fields, source, delivery, access, retention, and correction;
• raw/summary evidence available;
• metric/exclusion/priority/credit dispute intake and deadline;
• reviewer and escalation;
• resolution target;
• regulator/audit access;
• confidentiality and other-customer protections;
• final report after termination; and
• evidence version/expiry.