The curious desk-dweller.
Someone who wants to understand a change without deciphering a dashboard full of readings.
Product / one idea, all the way around
Start with
what if.
Before the sensors, services, and satisfying green lights: an idea worth making. Give it a purpose. Define its promises. Build something you can question.
Desk Sentinel / A product idea explored in a browser prototype
The vision / Desk Sentinel
A little desk companion.
Fewer mysteries.
What if a connected object could explain what it observes at your desk, show its evidence, and tell you when it does not know?
A number needs context.
A warmer reading or a detected object leaves questions. Disconnected readings can look current; confident answers can hide missing evidence.
Know what to trust.
See what was observed, understand which rule applies, and inspect the evidence behind an explanation.
An object that earns confidence.
A physical device could combine sensors, vision, and a knowledge service. Making that real would require hardware validation, privacy choices, and testing with people.
Small enough to inspect.
Sliders stand in for sensors. Scene detections are authored examples. Six notes and response templates produce explanations. No live hardware, camera, cloud backend, or language model runs here.
Non-goals for this slice: identifying people, diagnosing the cause of a change, serving as a safety alarm, or answering questions outside the field notes.
What good looks like / system definition
Make the promise
testable.
A useful definition lets a builder and a tester agree on what should happen before either presses Run.
Name what comes in.
Temperature, light, motion, connection state, scene, detection threshold, and a question of up to 240 characters.
Name what comes back.
A status and an explanation with source citations, an explicit refusal, or a clear error.
Say which moment counts.
Capture readings when the question is submitted. Keep that snapshot fixed. Mark offline values as last known.
Define the awkward bits.
Reject malformed requests. If source retrieval fails, stop before the answer service. Do not fill the gap with a guess.
Give “done” an example.
Write down the input and expected result, including boundary values and failures. Keep the expectation independent of the answer.
Choose limits on purpose.
Six notes and deterministic templates make this prototype repeatable and inspectable. Their narrow coverage is part of the contract.
| A little vague | Specific enough to test |
|---|---|
| “Warn when it gets hot.” | With an online device and other readings at their defaults, 31°C does not raise the heat alert. 32°C does. |
| “Make answers trustworthy.” | A supported temperature answer includes the Temperature source and its exact quoted evidence. Remove that citation: the QA check must fail. |
| “Answer only what we know.” | “What is the temperature sensor accuracy?” must get a refusal. Familiar words and related notes cannot establish an undocumented measurement. |
| “Trust the input.” | A malformed snapshot fails at the gateway. Missing readings must not become default values labeled current. |
| “Work when disconnected.” | Keep previous readings available, but label them last known. An offline answer must not present them as fresh observations. |
| “Handle errors gracefully.” | When retrieval fails, report that failure. The service trace must stop before answer assembly. |
These contracts have working checks in the QA playground. They are examples of acceptance criteria, not proof that a real-world device is ready to ship.
Inspect the checksIteration / the useful part of getting it wrong
A red light.
A better next question.
The answer lost its receipt.
The broken build sounds reasonable. QA finds that its required citation is missing.
Revisit the promise.
Is the definition wrong, or the code? Here, evidence is still required, so restore the citation. Change a contract only for a clear product reason.
Repeat the same check.
Run it again after the fix. Keep the expectation intact. Then ask which important behavior the current checks still miss.
Then test the idea with a person: can a visitor distinguish a current observation, a last-known reading, and a question the system cannot answer? Watch where they hesitate. Use that evidence to change the explanation, the interaction, or the original product promise.
NEXT / CREATIONGive the idea something to do.