01What gets protected first
The plan orders its priorities by harm, not by which system happens to be most visible. Life-safety and emergency messaging come first, ahead of everything else. Keeping an already-placed order intact, handing a call to a person when needed, and protecting payment secrets and opt-out lists come second. Identity, tenant separation, and security monitoring are third. A restaurant's or diner's ability to see accurate status, and to cancel or get refunded, is fourth. Recovering historical data, analytics, and administrative tools that don't block a live shift comes last.
- Life-safety and emergency messaging
- Active-order integrity, human handoff, and payment-secret protection
- Identity, tenant separation, and security monitoring
- Restaurant and diner status, cancellation, and refund paths
- Historical, analytical, and administrative recovery
02What a disruption is allowed to change, and what it isn't
A fallback response has hard limits regardless of how severe the disruption is. It can reduce what the system does, but the plan doesn't permit it to silently change who the seller is, what a caller consented to, what price or menu version an order is based on, or how long data is kept. A degraded mode that quietly repurposes itself into a different arrangement — a different merchant of record, a different consent basis — is treated as a failure of the plan, not a workaround.
Payment handling carries its own hard rule during a disruption: card numbers, expiry dates, and security codes are never accepted through a phone call, a chat message, a log file, or an improvised backup form, disruption or not. If the normal secure card path is unavailable, the response is to pause payment collection or route the caller to the restaurant directly — never to fall back on Dohos holding funds on the restaurant's behalf as a workaround.
03AI and voice behavior when something's degraded
If the speech, telephony, or AI components are degraded rather than fully down, the plan requires the caller be told about the limitation rather than left to guess, and it forbids the system from taking an autonomous action it can't be confident about. Any order already in progress is preserved safely rather than dropped, a human or restaurant alternative is offered, and preventing a duplicate or invented order is treated as a design requirement, not something hoped to not happen. Switching to a different AI model or provider mid-disruption isn't allowed to happen as an unreviewed, on-the-fly substitution — a change like that goes through the same data, contract, and evaluation gate a routine change would.
04Recovering data after an infrastructure failure
Restoring service after an infrastructure failure isn't just a matter of retrieving a backup — the plan requires a restored system to come back on trusted footing: exposed secrets get rotated rather than reused, tenant boundaries and any prior deletion requests are checked before the restored data is treated as live again, and downstream systems get reconciled rather than assumed consistent. A file that restores successfully isn't by itself proof the service actually recovered; the plan calls for testing full-service recovery, not just confirming a backup can be read back.
The backup and restore mechanics themselves — where copies live, how they're protected — are described at infrastructure; this page covers what has to be true about a restoration before Dohos treats it as complete, which is a continuity question rather than an infrastructure one.
05Exiting a critical provider
Losing, or deliberately leaving, a critical provider is treated as an anticipated event with its own checklist, not an emergency to improvise. For each critical dependency, the plan requires knowing who owns the relationship internally, how to escalate, where to check status, how to export data in a genuinely usable form rather than a technically-possible one, how concentrated the risk is if that one provider fails, and a tested — not merely contractual — path to move off it.
- Authority to initiate the exit, and required notice
- A freeze-and-cutover point, so nothing changes mid-export
- A complete export with the data's original structure and origin intact, not a lossy summary
- Verification that counts and integrity match on the new side
- Transfer of phone numbers, sender registrations, payment accounts, domains, and encryption keys — none of which Dohos assumes it automatically owns just because a provider created it
- Deletion or return of data left with the old provider, with confirmation
06Staying honest during a disruption
Status updates during an active disruption are required to state what's affected, what's known, a safe alternative if one exists, and when the information was current — and specifically forbidden from guessing at a cause or a fix time that hasn't actually been established. Current status is where this gets published as it's understood, not held back until a complete explanation is ready.
07Testing the plan
The plan sets its own minimum testing cadence: at least once a year, and again after any material change to the systems it covers. The scenarios it calls for are specific rather than generic — a complete loss of cloud or identity infrastructure, a critical provider failing outright, a corrupted backup, a telephony or AI outage happening while orders are actively in progress, and a full provider exit — and it measures actual recovery time and data loss against those scenarios, not just whether a room full of people can talk through what they'd do.