01What gets extra scrutiny
Not every change needs the same review. Dohos's policy calls for closer review specifically when a change touches:
- personal or sensitive data — how it's collected, shared, retained, or deleted
- the AI model, its prompts, or the tools it's allowed to call
- call recording, transcript storage, or anything that could identify a caller by voice
- how a payment credential, charge, refund, or dispute is handled
- identity, tenant access boundaries, or anything that touches a security control
- a legal notice, a consent flow, or a public claim about what the product does
A change outside that list still goes through ordinary review. A change inside it is where Dohos's process asks for more — a named reviewer independent of whoever wrote the change, and evidence that the change was actually tested against the case it's meant to handle, not just against a happy path.
02Design review, before code
For a change in the higher-scrutiny category, Dohos's policy asks the question before implementation starts, not after: what could go wrong, who could misuse this, what happens if it fails partway through, and whether there's a less risky way to get the same result. A reviewer on a high-risk change is expected to be able to reject it or send it back narrower in scope — review that can only approve isn't really review.
This matters most for anything touching the deterministic backend that owns menu prices, availability, and order totals — the part of the system explicitly designed so the AI model interprets language but never invents a price, a fee, or an acceptance decision on its own. A design review for a change in that area is checking that the boundary between "the model can suggest wording" and "only the backend decides business facts" hasn't quietly blurred.
03How a change reaches production
The pilot is being built in deliberate, ordered stages rather than all at once — catalog and menu data first, then the order and pricing core tested without voice involved, then the operational API and staff-screen contract, then voice integration itself, then the harder edge cases: non-order calls, upsell, recovery, and the assistance layer, and only after all of that, the live card-payment path and the physical printer. Each stage is meant to be proven before the next one builds on it, rather than shipping the whole system at once and finding out what's broken in production.
Within a stage, a change to source code is reviewed by someone other than its author before it merges, follows a protected path into the shared codebase, and is expected to keep development, test, and production data separate — production restaurant data is not meant to end up in a test environment or a development tool without a specific, approved reason.
04Testing before release
Dohos's design-by-policy calls for testing both what a feature should do and what it should refuse to do: an unauthorized request for another restaurant's data, an unverified confirmation, a spoken card number that should never be persisted, a duplicate or retried request that should not create a second charge or a second order. A green build and a passing test suite are treated as a starting point for release, not as proof of security on their own.
Changes to call-handling and ordering logic specifically are meant to be staged and checked against representative scenarios before reaching a live restaurant — the deterministic backend that owns menu identity, pricing, and order state is tested independently of the voice layer that sits in front of it, so a change to how the system talks does not silently change what it charges or what it promises.
05Dependencies and supply chain
Third-party libraries and packages are meant to be tracked and updated on a regular basis rather than left to drift indefinitely, and a materially vulnerable dependency is not meant to reach production without a documented, time-bound exception. Secrets — API keys, database credentials, provider tokens — belong in a dedicated secrets-management system, never committed to source, written into a ticket, or exposed in a log.
06Rollback
A release that misbehaves is meant to be reverted, not patched forward under pressure while a restaurant's dinner rush is actively depending on the system working. An emergency change made outside the normal review path is still expected to be logged, narrowly scoped to the actual problem, and reviewed after the fact rather than left unexamined because it was urgent.