Most “technology restaurant” lists tell you what to buy. The real line is whether you can grep last night's phone orders.

The useful test is not the number of vendor logos in the back office. It is whether the channels the restaurant actually runs are stored as observable, diffable, version-controlled artifacts. A POS with a hosted dashboard is not the same as a POS with a public webhook schema. A kitchen display is not the same as a kitchen display that emits a JSON event per ticket. A phone line is not the same as a phone line where every call produces a speaker-diarized caption file checked into source control. A restaurant becomes a technology restaurant when the answer to 'can you pull up what the customer said at 1:14am on Tuesday' is yes, grep it.

It lives at src/components/voice-activity-data.ts in the public pieline-phones repository. It exports a typed VoiceData object with four fields: duration (102.36 seconds), sampleRate (60 samples per second), envelopes (two float arrays, one per speaker, 6,157 values each), and captions (46 speaker-tagged entries with start, end, and text). The file is 76,438 bytes on disk. It is auto-generated by scripts/build-voice-activity-data.py, which posts the stereo WAV to Deepgram's multichannel endpoint, bins the audio into 60Hz RMS envelopes, groups Deepgram's word timestamps into captions on pause and punctuation boundaries, and writes a single TypeScript literal. The hero visualization on aiphoneordering.com imports this file directly.

60Hz means a sample every 16.67 milliseconds. That is roughly the length of a consonant. For 102.36 seconds of audio that gives ceil(102.36 * 60) = 6,142 theoretical samples; the actual file ships 6,157 per channel (the build script pads the last window). Multiplied by two channels (customer on the left, AI on the right), the whole call is 12,314 floating-point numbers. At 16ms resolution you can see a caller's 'uh-huh' that a 10Hz visualizer would flatten into noise, and you can tell whether either speaker started talking while the other was still finishing a word (overlap). This is the resolution needed to audit politeness on a phone call rather than just transcribe it.

Because the two interesting questions about a phone order are asymmetric. 'What did the customer ask for' is a customer-channel question. 'What did the AI promise' is an AI-channel question. Merging them into a single transcript loses the handoff structure. PieLine's recording is stereo by construction: the customer line is channel 0, the AI voice is channel 1. Deepgram's multichannel mode transcribes them independently and emits word timestamps per channel. The build script keeps them apart all the way to the TypeScript file, so the 46-caption array is sorted by time but still tagged with speaker. That is what lets the landing-page visualization render two independent bar graphs that pulse in sync with the actual person talking.

Three things. First, grep. You can search 'strawberries' across a thousand calls and find every caller who added an off-menu modifier, without listening to anything. Second, diff. When you change the menu, you can diff the captions from before and after and see whether callers stop saying 'wait, do you still have X.' Third, regression. You can run an eval suite against the caption file, asserting that the AI said a legal recording disclosure in the first 2 seconds and addressed the caller by name in the last 5. None of that is possible with a flat MP3. All of it is possible with a 76KB typed file.

Analytics dashboards aggregate. They tell you calls-per-hour, peak-minute counts, average handle time. They do not tell you what one customer said. A technology restaurant has both. The dashboards belong to the operator and live behind a login. The per-call artifacts belong to the engineering surface and live in a repo. The caption file in pieline-phones is the engineering surface for one call. A restaurant running at scale would have one such file per call, stored as a blob with a repo-style manifest. A restaurant running a hosted phone line at a conventional answering service has no such file and no surface it could live on. The presence of this file, in any form, is what moves a restaurant across the line.

scripts/build-voice-activity-data.py is 117 lines of Python. It takes a stereo WAV as an argument, posts it to Deepgram nova-3 with multichannel, punctuate, and smart-format enabled, reads the two resulting channels, computes per-channel RMS envelopes at 60Hz with a 0.5 attack / 0.12 release smoother, groups the word timestamps into captions on pause boundaries (>0.55s gap), sentence boundaries (ending punctuation), or a 75-character cap, and writes the result to src/components/voice-activity-data.ts as a single TypeScript literal. The fact that it is 117 lines and uses three dependencies (wave, struct, urllib) is the whole point. The artifact is not a proprietary binary from a vendor. It is a plain-text pipeline a competent engineer could re-implement in an afternoon against a different transcription service. That is what makes the output auditable instead of marketed.

No. It means the vendor the restaurant hires has to ship artifacts the restaurant's engineers (or auditors, or a curious owner) can open. PieLine's onboarding team handles menu scraping, POS mapping, and configuration. The restaurant owner never runs the build script. But the fact that the build script exists, produces a checked-in file, and imports into the production site means the restaurant's phone channel behaves like infrastructure, not like a call center. The operator still spends zero time in the source tree. The difference is that the system is auditable if they ever want to look.

Four axes. Uptime, because it is a floor, not a differentiator. Category breadth, because a vendor that ships one well-observable channel beats a vendor that ships four opaque ones. Price per call, because cost lives on the P&L and this scorecard lives on the engineering review. UI polish, because a polished dashboard over an unauditable backend is the exact failure mode this scorecard is designed to expose. A restaurant buyer should still care about all four, but on a different page.

Ask each vendor three questions. One, where does your recording of a phone call live after the call ends? If the answer is a hosted dashboard with no export, downgrade. Two, do you ship a speaker-diarized transcript with per-turn timestamps and can I get it as a file? If the answer is 'we can export a PDF,' downgrade. Three, is the code that generates that transcript readable anywhere, either open-source, documented, or regenerable from a script I could run myself? If the answer is 'it's proprietary,' downgrade. The vendor that answers yes, yes, yes is the vendor shipping a technology restaurant. The one that answers no, no, no is shipping a phone service.

76,438 bytes of TypeScript plus 1,229,949 bytes of MP3 equals roughly 1.3 megabytes for one 102-second call. The MP3 is the raw audio the caption file is built from. The TypeScript file is the observable form. Together they take about the same space as a photo your phone took last weekend. Scaled up to a busy restaurant doing 500 phone orders a week, one year of calls is around 34 GB. That is a single cheap S3 bucket. The cost of being grep-able is trivial; the cost of not being grep-able shows up the first time a manager is asked what the customer who complained yesterday actually said.