Imagine this
A machine can understand a request and still need to check before acting. It should know who can say yes and who can stop it. A rule example does not prove a real machine is always safe.
THE FIELD GUIDE / 027 · CONTROL AND VERIFICATION
Understood.
But should it act?
A machine hears “start”. The words are clear, but a cover is open. Understanding a request and deciding to carry it out are different tasks.
A very simple version
For curious readers: how it could help and what the evidence says
How it could help people
When a machine is about to do something important, a person may need to say yes. Everyone should have a clear way to stop it. The full rules still need careful testing.
Evidence and limits
The software demonstration does not test voice accuracy or a physical device; safe deployment needs every rule and failure checked.
Read-aloud starter; not yet tested with children. The fuller science, data, figures and sources follow below.
Different questions need different checks
“What did you mean?” asks about interpretation. “Are you allowed?” asks about authority. “Is this request still current?” asks about freshness. “Are the required conditions satisfied now?” asks about the machine's state. “Did you intend this action?” asks about confirmation.
One answer cannot substitute for the others. A familiar voice or a plausible time of day does not prove authority. Repeating a recording does not create independent authentication. A confirmation should refer to the exact pending action, rather than approve whatever request arrives next. NIST guidance on authentication intent and replay resistance
Who can overrule whom?
An operator’s request and a controller’s permission are separate decisions. In one proposed arrangement, crew changes are allowed only if the computer does not reject them on risk grounds. That assigns the computer a veto; it is not an unrestricted crew override. The proposal still needs a defined risk rule, behavior when information is missing and a way to resolve disagreement. The demonstration below tests its own declared rule, not this unimplemented system.
ASSIGNED INPUTS · A DECLARED RULE
Which check changes the decision?
These switches supply assumed answers. They do not recognise speech, authenticate a person, read a physical sensor or operate equipment. The virtual action is advancing a part by one position.
Rule output
First reason
“Permit” means only that the declared rule passes for these assumed inputs. It does not mean “certified safe”. Several failures can coexist; the first reason follows the stated order: meaning, authority, freshness, interlock, then confirmation. Requiring confirmation is a choice in this toy policy, not a recommendation for every command.
A confirmation can go out of date
Suppose the virtual machine asks for confirmation. Before execution, someone opens its cover. The earlier state check is no longer enough. Execution must check current conditions rather than reuse the old answer.
A late “yes” also needs context. Which request did it approve? Has that request expired or been cancelled? Has it already executed? Showing the interpreted action, its status and the reason for refusal helps a person recover from a mistake.
VIRTUAL PART · MANUALLY ADVANCED CLOCK
Change the conditions before execution
This second demonstration always requires confirmation. Recognition and authority are assumed to pass; the first demonstration explores those checks separately. Each new request receives a unique local number and an invented five-second lifetime. The clock advances only when you press a time button.
Simulation clock
Current request
Request state
Time until expiry
Confirmation bound to
Virtual part movement
Saved confirmation request number: .
No pending request. Nothing has moved.
Try three short sequences
- Create a request, confirm it, then try execution twice. The part advances once.
- Create and confirm another request, open the cover, then try execution. Closing the cover again does not restore confirmation; you must confirm again before the original expiry.
- Create and confirm a request, then create a new one. Replay the saved confirmation: it refers to the previous number and cannot approve the new request.
At exactly five seconds after creation, the request expires. Cancellation, expiry and completed execution cannot be undone by another “yes”. The replay button represents recorded consent, not a new intentional confirmation; replay is refused even when its number still matches. A new request supersedes the old one without carrying its confirmation. Failed attempts do not extend the lifetime.
Recent events in this demonstration
Both interlocks are switches you control, not physical sensors. Opening either clears a confirmation under this chosen policy. The executor checks the current request and interlocks again. This single-page model does not secure messages or guarantee exactly-once action across a network.
Voice is an interface, not a capability
Speech can help when hands or eyes are occupied. But noise, background conversation, an omitted word or a lost negation can change a command. The system should make the interpreted action clear and let the person cancel or correct it. NASA research on voice-controlled interfaces
| Intended phrase | Possible wrong interpretation | What needs checking |
|---|---|---|
| “Do not start.” | “Start.” | Whether negation survived interpretation |
| “Start the display.” | “Start the machine.” | Which specific object and action were selected |
| A recording repeats an old command. | A new legitimate instruction | Authority, freshness and binding to the current request |
A spoken direction does not provide lift, balance, braking or a safe operating envelope. Those require separate engineering and evidence. No voice-recognition accuracy or flying device is demonstrated here.
What this can improve
Today: industrial interfaces, household automation and accessibility tools can make the pending action and its conditions easier to understand. Separating the checks helps identify whether a failure came from interpretation, permission, timing or the machine's state.
A future direction: test confirmation wording and feedback with people performing realistic tasks, while separately testing state changes and missing information. More prompts can increase workload, become habitual or delay urgent tasks. Measure whether people understand and recover from errors, rather than assuming every extra confirmation helps. NASA crew-interface guidance
Real equipment needs responses suited to its physics. Removing power or freezing commands is not universally the safest action. This page models decisions only; it neither implements emergency handling nor certifies a machine.
EXHAUSTIVE LOGIC STUDY · NOT A PERFORMANCE TRIAL
Test every row of the rule
| Outcome | Combinations out of 64 | Meaning in this rule |
|---|---|---|
| Deny | 60 | At least one prerequisite is false |
| Wait | 1 | All prerequisites pass, but required confirmation is absent |
| Permit | 3 | All prerequisites pass and confirmation is either present or not required |
Declared policy
Permit = known AND authorized AND fresh AND interlock AND (NOT confirmation_required OR confirmed). If a prerequisite fails, deny. If only a required confirmation is absent, wait. Otherwise permit.
Six Boolean inputs produce 2⁶ = 64 combinations: 60 deny, 1 wait and 3 permit. The three permitted rows differ only in whether confirmation is required and present. These counts describe a chosen truth table, not probabilities, accident rates or recognition performance. The rows are not sampled from a population.
State demonstration
Every execution checks the current request number, fixed action, live status, matching confirmation, expiry and current interlocks. A request is valid only while simulation time is strictly less than its creation time plus 5,000 milliseconds. Execution consumes it before changing the virtual position. Opening an interlock clears confirmation; closing it does not restore consent or renew the lifetime.
The exhaustive table checks the Boolean rule, not the entire state machine. Separate transition checks cover expiry, cancellation, stale confirmations, repeat execution and changing interlocks. Neither check proves that a real sensor or identity system supplies correct inputs.