Logging

01Why logging exists here

Logging exists to diagnose a problem after it happens and to reconstruct what actually occurred on a call or an order — not to accumulate data for its own sake. A restaurant asking "what happened to order 214" or Dohos's own team debugging a failed call both depend on a record that's accurate and attributable, not a guess reconstructed from memory.

That reasoning also sets a limit. A record kept because it answers a real operational or safety question is different from a record kept because collecting everything felt safer than deciding what actually matters — Dohos's policy asks for the first and treats the second as its own kind of risk, since a log nobody needs is still something that has to be protected and can still leak.

02What's recorded

Dohos's logging policy calls for capturing security-relevant events in a minimized, protected way: sign-ins and failed sign-in attempts, permission and role changes, configuration changes, data exports, and access to sensitive views — each tied to a specific actor and timestamp, not a shared or anonymous action.

Order activity specifically is designed around an append-only event history — every change, replacement, and exception to an order is preserved as its own record rather than overwritten, because a restaurant's closeout numbers, a disputed charge, and a customer's changed order all genuinely depend on that trail existing. This is a specific, real design decision from the product's own build specification, not a general policy aspiration.

03What's deliberately never logged

Some categories are excluded from logging by design, as a direct extension of the same rule that keeps them out of Dohos's database entirely (see payments and card data):

Full call audio is not logged or stored by default either — recording is a separate, explicitly configured capability described at retention, not something that happens automatically as a side effect of ordinary logging.

04Who can see a log

Access to logs follows the same least-privilege discipline described at access control — a role sees what its job requires, and access to a sensitive log view is itself one of the events this page's own §2 says gets recorded.

A restaurant's own settings changes are designed to carry the same kind of trail on a smaller scale: when a manager changes a policy, an hour, or a fee, the record of who changed it and when is meant to be visible to that restaurant's own authorized staff, not only to Dohos internally. A consequential change shouldn't be a mystery to the team that has to live with it.

05Retention

How long a given category of log is kept follows the same schedule described for the underlying data it relates to, rather than a separate, disconnected logging-specific rule — full detail at retention.

06Detection, not just record-keeping

A log that nobody looks at until something has already gone wrong is only half useful. Dohos's policy calls for alerting on defined scenarios — repeated failed sign-ins, an access pattern that crosses a tenant boundary it shouldn't, a spike in exports from one account — with a named owner and a response procedure behind each alert, rather than a log stream nobody is watching.

07Service and data freshness

A related but distinct idea shows up throughout the product, not only in security logs: the operator console and staff tablet are designed to say plainly when the data on screen might not be current, rather than silently presenting stale information as if it were live. The states that distinction covers:

This isn't a security control in the strict sense, but it comes from the same underlying discipline logging does: a system should say what it actually knows, and say plainly when it doesn't, rather than paper over a gap with a confident-looking screen.

Related documents

• Payments and card data — why a card number is excluded from logs, as an extension of it being excluded from Dohos's systems entirely.
• Access control — who can see a log, and how that access itself gets recorded.
• Retention — how long a log, a transcript, or an order record is actually kept.