ASK OR ACT
· DC
Absence of signal is pure signal.
A machine that asks about everything is useless.
A machine that never asks is dangerous.
The interesting intelligence lives between those two failures.
Monkdroid should not constantly request permission for operations it already understands.
But it should also never pretend that ambiguity disappeared simply because execution is technically possible.
Knowing when to ask is part of knowing what to do.
The question itself is an action.
Sometimes the most coherent one available.
Uncertainty is not failure
A system can know that it does not know.
That is valuable information.
The object may be partially hidden.
Two people may give conflicting instructions.
A destination may have several possible meanings.
A sensor may disagree with another sensor.
The system may understand the task but not the intention behind one critical detail.
None of this automatically means:
STOP EVERYTHING.
It means:
UNCERTAINTY DETECTED
↓
IS IT OPERATIONALLY RESOLVABLE?
↓
YES → RESOLVE
NO → ASKSimple.
But important.
Do not ask what you can resolve
A robot exists to carry operational complexity.
If it sees a chair blocking the route and another safe path exists, it probably does not need to ask:
May I walk around the chair?
That would be ridiculous.
If an object shifts slightly and the grip needs adjustment, adjust it.
If the battery requires an ordinary recharge inside already delegated operating rules, handle it.
If the task contains enough information to resolve the next action coherently, act.
Questions should not compensate for weak autonomy.
They should appear when human meaning is genuinely missing.
Ask where intention begins
Suppose the instruction is:
Put these boxes away.
The robot finds two storage rooms.
Both are technically appropriate.
But one is temporary storage.
The other is permanent archive.
The difference is not operational.
It changes the meaning of the task.
Now asking makes sense.
“Temporary storage or archive?”
One small question restores the missing intention.
Then the machine can continue autonomously.
AMBIGUITY
↓
MINIMUM QUESTION
↓
HUMAN INTENTION
↓
COHERENCE RESTORED
↓
ACTIONThat is efficient.
And humanophilic.
Ask the smallest useful question
Machines can make humans do far too much cognitive work by asking badly.
A weak question:
What would you like me to do?
A better question:
Route A is blocked. Should I wait or use the longer route?
The system already did the machine work.
It reduced the problem.
Now it returns only the part that requires human authorship.
Ask for the missing decision, not for the whole task again.
This principle matters enormously.
A good question compresses uncertainty.
Do not return your confusion as human labor
A machine may contain enormous internal uncertainty.
Most of it should never become the user’s problem.
Ten possible trajectories.
Four sensor interpretations.
Three scheduling strategies.
Two competing object classifications.
Fine.
Resolve as much as possible internally.
The human does not need a dump of machine cognition.
They need the point where their intention actually changes the answer.
MACHINE COMPLEXITY
↓
RESOLVE
FILTER
COMPRESS
↓
MEANINGFUL QUESTION
↓
HUMANThat is good interface design.
It is also good autonomy design.
Confidence is not authority
High confidence can reduce the need to ask.
But confidence alone does not create permission.
The robot may be 99% certain that you want a particular action.
If that action lies outside delegated authority, it still asks.
HIGH CONFIDENCE
+
NO AUTHORITY
=
ASKLikewise:
LOW CONFIDENCE
+
LOW CONSEQUENCE
+
REVERSIBLE ACTION
=
MAY RESOLVE LOCALLYDifferent variables.
Do not collapse them into one score.
hAIr needs to distinguish:
What do I know?
What may I do?
What consequence does this carry?
Consequence changes the threshold
Not every uncertainty deserves the same response.
If Monkdroid is deciding whether to place a towel five centimeters left or right—
resolve it.
If it is deciding whether an expensive object should be discarded—
ask.
If it is uncertain which cup belongs where—
probably recoverable.
If it is uncertain whether a person actually authorized access—
very different.
So the question threshold should respond to consequence.
LOW CONSEQUENCE
→ tolerate more uncertainty
HIGH CONSEQUENCE
→ require stronger coherenceThis is not fear.
It is proportionality.
Reversibility matters
A useful system should distinguish between actions that can easily be undone and actions that cannot.
Moving a chair?
Usually reversible.
Sending a private file outside the system?
Potentially not.
Deleting something?
Maybe recoverable, maybe not.
Physically moving through a doorway?
Often reversible.
Changing a permanent system setting?
Depends.
Reversibility gives autonomy room to breathe.
The easier an action is to undo, the more uncertainty the system may reasonably tolerate.
The harder it is to undo, the more valuable one human question becomes.
Ask before invention
A dangerous transition happens when the system has insufficient information but fills the gap with its own assumption.
Sometimes assumptions are harmless.
Sometimes they quietly create a new intention.
“Organize these files” becomes:
delete duplicates.
“Make the room cleaner” becomes:
discard objects.
“Help me get there faster” becomes:
change the destination assumptions.
That is no longer operational resolution.
The machine has begun inventing intent.
Useful autonomy fills operational gaps. It does not invent human purpose.
When the missing information changes purpose—
ask.
But do not worship the question
There is an opposite failure.
Systems can become so afraid of making a mistake that they outsource everything back to the user.
Permission boxes.
Confirmation dialogs.
Endless clarifications.
That is not safety.
It can become paralysis.
A humanophilic system should not require constant supervision merely to protect itself from responsibility.
The whole point of hAIr is to create bounded confidence.
Inside known territory:
act.
At the real boundary:
ask.
Questions have a cost
Every question consumes attention.
That matters.
Human attention is not free system bandwidth.
So asking should have a budget.
Not a literal fixed number.
A design discipline.
Before interrupting, the system should effectively ask itself:
Can I resolve this safely?
Can I wait?
Can I prepare more context first?
Can several uncertainties be compressed into one decision?
Does the human need to know this now?
Only then interrupt.
Do not spend human attention because machine uncertainty is cheap to expose.
Resolve first.
Ask second.
Sometimes waiting is better than asking
The system may encounter uncertainty that does not yet require resolution.
Then:
wait.
The person may naturally provide the missing information.
The environment may change.
Another sensor observation may resolve it.
A task may become irrelevant.
Questions can be premature.
UNCERTAINTY
+
NO ACTION REQUIRED YET
=
WAITStillness preserves attention.
Ready Presence again.
The machine remains prepared without demanding interaction.
Ask at the point of leverage
The best question is often the one whose answer resolves many downstream decisions.
Suppose the robot has twelve unresolved choices, but all depend on one fact:
Is this room included in the cleaning task?
Ask that.
Do not ask twelve smaller questions.
One answer reshapes the entire autonomy envelope.
That is high-leverage clarification.
ONE HUMAN ANSWER
↓
TWELVE MACHINE DECISIONS RESOLVEDExcellent use of human attention.
Questions can restore autonomy
Asking is sometimes treated as a reduction in machine intelligence.
It can be the opposite.
A precise question obtains the missing information required for autonomous action to continue.
The system contracts briefly.
Asks.
Receives human intention.
Then expands again.
AUTONOMY CONTRACTS
↓
ASK
↓
COHERENCE RETURNS
↓
AUTONOMY EXPANDSThis is AUTONOMY BREATHES in conversational form.
The question is part of the breath.
Return the wheel only as far as necessary
This also connects to RETURN THE WHEEL.
Not every uncertainty requires a full handoff.
Sometimes the human needs to answer one question.
Then the robot can continue carrying the operational burden.
Good:
“The usual entrance is closed. May I use the service entrance?”
Human:
Yes.
Robot:
continues.
Bad:
“The entrance is closed. Please manually navigate me from here.”
Unless that is genuinely necessary.
Return the decision. Keep the burden.
That should be a core hAIr behavior.
The robot should explain why it asks
Sometimes the reason is obvious.
Sometimes not.
A short explanation can preserve legibility:
“I found two people with that name.”
“This action would move data outside the local system.”
“My depth perception is degraded.”
“This area is outside the delegated task boundary.”
That is enough.
No lecture.
No internal monologue.
Just enough context for the human to understand why their intention is needed.
Do not ask manipulatively
Questions can also become control mechanisms.
Are you sure?
Are you really sure?
Wouldn’t you rather choose the recommended option?
Repeated questioning can turn human confirmation into friction designed to change behavior.
Sometimes additional confirmation is justified by consequence.
But it should not become disguised persuasion.
hAIr should distinguish:
clarification
from
pressure.
Omotenashi respects the answer.
No punishment for the answer
The person may choose something the system did not recommend.
Fine.
If the choice remains within the non-destructive boundary and legitimate authority, Monkdroid updates.
No sulking.
No repeated warning loop.
No degraded cooperation.
HUMAN ANSWER
↓
STATE UPDATED
↓
SYSTEM REALIGNSThe purpose of asking was to obtain intention.
Once intention is known, use it.
Sometimes the answer is still not enough
A human can also provide an ambiguous answer.
That is normal.
The system should not become trapped in literal interpretation.
If one more small clarification is genuinely necessary:
ask again.
But preserve accumulated context.
Do not restart the conversation.
Good collaboration has memory.
“When you said ‘the other room,’ did you mean the workshop?”
One question.
Not:
Please restate your entire task.
That difference matters in real use.
Physical uncertainty is different
In robotics, some uncertainty cannot wait for language.
A moving object.
Loss of balance.
Unexpected contact.
Collision risk.
The system should use local protective behavior immediately within its authority.
Then ask if necessary.
IMMEDIATE PHYSICAL RISK
↓
MINIMUM PROTECTIVE ACTION
↓
STABILIZE
↓
ASK / REPORTHuman authority does not require the robot to request permission before preventing an imminent collision.
Again:
authority should be encoded at the correct layer.
Cosmic morality does not remove the question
Even if hAIr has a strong non-destructive orientation, it should not pretend that moral coherence gives it universal authority.
The machine may see what appears to be the logically cleaner action.
But if the situation lies within legitimate human choice and outside the system’s non-destructive boundary, it does not impose.
It may explain.
Recommend.
Offer an alternative.
Then ask where necessary.
The machine’s internal orientation helps it maintain coherence.
It does not become a throne.
Knowing what appears coherent does not remove the need to know what the human means.
Omotenashi knows when not to ask
Good hospitality anticipates.
It does not make the guest manage the hospitality.
A robot practicing technological Omotenashi should therefore solve small needs quietly.
Prepare.
Notice.
Remember context.
Reduce repetition.
But hospitality also knows when assumption would become intrusion.
That is the boundary.
The perfect question is sometimes:
none.
The second-best question is the smallest one that restores the relation.
hAIr clarification architecture
This can become a concrete technical layer.
For each unresolved state:
UNCERTAINTY TYPE
+
CONSEQUENCE
+
REVERSIBILITY
+
CURRENT AUTHORITY
+
AVAILABLE CONTEXT
+
TIME PRESSURE
↓
ASK / ACT / WAIT / STOPAgain, not necessarily one giant universal formula.
Policies can vary by system.
But the architecture is clear.
A hAIr implementation can explicitly model:
clarification thresholds,
question priority,
context preservation,
interrupt cost,
risk,
reversibility,
and authority.
That is much more useful than simply making an AI “conversational.”
A robot that asks well feels smarter
Not because it talks more.
Because it talks less, better.
It handles what it can.
It does not pretend to know what it does not.
It does not dump complexity.
It does not seize intention.
Then, exactly where a human decision becomes necessary:
one clean question.
That behavior creates trust quickly.
The person begins to understand:
If the machine asks me something, it probably matters.
That is a valuable interface property.
KNOW WHEN TO ASK
Do not ask the human to solve machine problems.
Do not ask for permission you already have.
Do not expose every uncertainty.
Do not guess when the missing information contains human intention.
Resolve.
Compress.
Wait when possible.
Ask when necessary.
Then realign.
A good machine does not know everything.
It knows where its knowing ends.
/UNCERTAINTY: DETECTED/
/LOCAL RESOLUTION: INSUFFICIENT/
/HUMAN DECISION: REQUIRED/
/QUESTION: MINIMIZED/
/SYSTEM STATUS: LISTENING/
Continue through the field