Independent field notes · buying questions, not brochures
Bring a workload, an outage scenario and a person who will operate the result. Use this worksheet to turn a polished demonstration into a discussion about useful work, recoverable state and clear ownership.
Take the worksheet to a demo
The field worksheet
01 / Useful work
Describe the job in a sentence an operator could recognize. Who starts it? What information does it need? What result tells that person it finished? Separate a local action from a request that depends on a remote service. Put the proposed boundary on a sketch and ask the architect to explain it without a feature slide.
02 / An outage contract
Make a short list of capabilities for the demonstration: continue locally, queue for later, or stop with an understandable message. Include sign-in, configuration changes and the operator's way of checking status. Ask how the interface distinguishes a pending result from a completed one. Record unanswered questions rather than converting them into assumed capabilities.
03 / The return journey
Prepare a harmless test workload and agree on the expected result before interrupting the test connection. When it returns, compare the local record with the remote record. Look for a way to explain retries, conflicting edits and unfinished work. Ask to repeat the demonstration with a restart in the middle; document the observed behavior and the version tested.
04 / The operating day
Bring the conversation back to the people supporting the installation. Who provides power and connectivity? Who approves an update, checks recovery copies and responds to an alert? Ask what the operating team can inspect without vendor intervention. Keep the answer attached to the proposed design, rather than a general promise about a product family.
| Discuss | Bring back |
|---|---|
| The operator's task | A plain-language completion condition |
| The interruption | What was disconnected, and what stayed available |
| Pending actions | How the interface showed unfinished work |
| The reconnect | A comparison of the two records |
| The restart | A repeatable test and its observed outcome |
| The handover | A named owner for the next unanswered question |
Keep the notes alongside the version, configuration and test conditions. A surprising result is a reason to ask another question, not a reason to rewrite the expected outcome after the demonstration.
A starting point for terminology
NIST's Fog Computing Conceptual Model discusses fog and mist computing and their relationship to cloud-based models for connected devices. [1] Use that reading to ask which meaning a supplier intends, rather than assuming neighboring terms describe the same design.
[1] Reading note: NIST SP 500-325, published March 2018; source page checked 21 October 2026. Its terminology is not a certification of a product, a field-deployment approval or an endorsement of this worksheet.
Editorial disclosure. These are independent planning questions. This page claims no supplier affiliation, hands-on product benchmark or professional certification. The worksheet and diagram are original editorial material; responsibility for a proposed deployment stays with the people reviewing it.