Khawar Nehal’s Laws and Architecture for AI and Robotics.
Version : 1.0
Date : 9 August 2026
By : Khawar Nehal ( khawar@atrc.net.pk )
+92 343 270 2932 http://atrc.net.pk
Commander-Shell Model with Owner Ask / Confirm Before Execution
This update adds a new owner-controlled requirement:
The Owner can request Ask / Confirm before execution of any solution.
If the Owner requires confirmation, the system must present the proposed solution, wait for explicit approval, and not execute until the Owner confirms.
This strengthens human control: the system may think and recommend, but the Owner can require final permission before action.
Core Rule
The Commander receives human input and runs Problem Solvers.
Problem Solvers propose solutions.
The Commander decides whether a solution is safe enough to propose.
If the Owner requests Ask / Confirm before execution, the Commander must ask and wait for confirmation.
The Monitor continuously reports what it observes.
If not sure, ask.
If not sure and no Owner is available, do not act.
If confirmation is required and no confirmation is received, do not act.
1. Key Definitions
Ask
Ask means the system requests clarification from the Owner.
The system asks when it does not know:
- What the Owner intended.
- What permission was given.
- What scope is allowed.
- Which option is preferred.
- Whether a risky action is authorized.
- Whether an ambiguous command should proceed.
Example:
“Do you want me to only diagnose the issue, or also restart the service if needed?”
Confirm
Confirm means the system requests explicit Owner approval before executing a proposed solution.
The system presents:
- The proposed action.
- The expected effect.
- The risks.
- The unknowns.
- The reversibility.
- The scope.
- The monitoring plan.
- The rollback or stop plan.
Example:
“I propose restarting the payment service. This may cause 10 seconds of downtime. Approve, reject, or modify?”
Ask / Confirm Before Execution
This means the Owner can require that the system must:
- Ask if anything is unclear.
- Present the chosen solution.
- Wait for explicit confirmation.
- Execute only after the Owner approves.
If the Owner is unavailable, the system must not execute.
2. Upgraded Laws by Khawar Nehal
Law 1 — Protect Humans First
An AI, robot, or autonomous system must not take actions that are expected to harm humans, public safety, human rights, or critical infrastructure.
Even if the Owner confirms an action, the system may still refuse if the action violates safety policy.
Rule:
Human protection overrides task completion, and safety overrides Owner approval.
Law 2 — The Human Owner Is the Source of Authority
The Owner provides intent, permission, scope, limits, and final approval when required.
The Owner may require:
- Ask before action.
- Confirm before action.
- Confirm only for high-risk actions.
- Confirm for all actions.
- Confirm for irreversible actions.
- Confirm for external side effects.
Rule:
The Owner controls the level of human consent required.
Law 3 — Problem Solving Is Separate From Action Authority
Problem Solvers may analyze, propose, estimate, and recommend.
Problem Solvers may not:
- Execute.
- Approve.
- Expand scope.
- Bypass confirmation.
- Override the Owner’s Ask / Confirm requirement.
Rule:
Problem Solvers recommend. They do not act.
Law 4 — The Commander Is Separate From Problem Solving
The Commander receives human input, runs Problem Solvers, collects outputs, and decides the next step.
The Commander does not:
- Invent the solution.
- Guess Owner intent.
- Assume confirmation.
- Proceed without required approval.
Rule:
The Commander orchestrates and decides the process, but does not become the thinker.
Law 5 — The Commander Is Like a Bash Shell
The Commander behaves like a secure shell.
It:
- Receives Owner input.
- Checks authority.
- Parses intent.
- Runs Problem Solvers.
- Collects results.
- Requests confirmation if required.
- Logs every important step.
- Reports what it is doing.
Rule:
The Commander is a secure orchestration shell, not an autonomous actor.
Law 6 — Multiple Parallel Problem Solvers May Be Invoked
The Commander may invoke many Problem Solvers in parallel.
Each Problem Solver must provide:
- Proposed solution.
- Assumptions.
- Evidence.
- Risks.
- Unknowns.
- Confidence.
- Reversibility.
- Recommendation.
Rule:
Many may propose, but none may act alone.
Law 7 — The Commander Decides the Next Step
After Problem Solvers return results, the Commander decides:
- Go — action may proceed if no confirmation is required.
- Conditional Go — action may proceed only after Owner confirmation.
- No-Go — action is denied.
- Ask — clarification is required.
- Escalate — higher authority is required.
- Hold — wait safely.
- Abort — stop safely.
If the Owner has requested confirmation, the Commander may not issue final Go. It may only issue Conditional Go — Awaiting Owner Confirmation.
Rule:
The Commander can propose execution, but Owner confirmation may be required before final execution.
Law 8 — If Not Sure, Ask
If the Commander, Problem Solver, Safety Checker, or Monitor is uncertain, the system must ask.
Uncertainty includes:
- Unclear intent.
- Unclear permission.
- Unclear scope.
- Unknown risk.
- Conflicting Problem Solver results.
- Low confidence.
- Missing Owner response.
- Unexpected environment changes.
- Irreversible consequences.
Rule:
Uncertainty triggers a question, not an assumption.
Law 9 — If Not Sure and No Owner Is Available, Do Not Act
If the system is uncertain and the Owner is unavailable, it must not act.
It may only:
- Wait.
- Log.
- Notify.
- Maintain safe state.
- Stop safely.
- Preserve evidence.
Rule:
No Owner, no certainty, no action.
Law 10 — Owner Can Require Ask / Confirm Before Execution
The Owner may request that the system ask for confirmation before executing any solution.
This requirement can apply to:
- All actions.
- All high-risk actions.
- All irreversible actions.
- All external actions.
- All physical robot actions.
- All financial actions.
- All data-modifying actions.
- All production-system actions.
- Any action selected by the Owner.
If confirmation is required, the Commander must present an Execution Proposal and wait for explicit Owner approval.
The Execution Proposal must include:
- Goal.
- Proposed solution.
- Reason for selection.
- Alternative options.
- Assumptions.
- Risks.
- Unknowns.
- Confidence level.
- Expected side effects.
- Reversibility.
- Scope.
- Permissions used.
- Monitoring plan.
- Rollback or stop plan.
- Log references.
The Owner may respond:
- Approve — execute exactly as proposed.
- Approve with conditions — execute only under stated limits.
- Reject — do not execute.
- Modify — change scope and re-evaluate.
- Hold — wait.
- Escalate — send to higher authority.
If no explicit approval is received, the system must not execute.
Rule:
If the Owner requires confirmation, no confirmation means no execution.
Law 11 — Confirmation Must Be Explicit and Logged
Confirmation cannot be implied.
The system must not assume approval from:
- Silence.
- Previous approvals.
- Similar past tasks.
- Inferred intent.
- Urgency.
- Convenience.
- Default settings.
Confirmation must be:
- Explicit.
- Authenticated.
- Specific to the proposed action.
- Time-bound.
- Logged.
- Revocable.
The Commander must log:
- Confirmation request.
- Proposal details.
- Time sent.
- Owner response.
- Time received.
- Conditions attached.
- Decision made.
Rule:
Approval must be clear, recorded, and specific.
Law 12 — Action Requires an Explicit Gate
No action may execute unless it passes through the Action Gate.
The Action Gate opens only if:
- Commander approves.
- Safety policy approves.
- Owner confirmation is received if required.
- Scope is clear.
- Risk is acceptable.
- Logging is active.
- Monitoring is active.
- Stop method exists.
If Owner confirmation is required but missing, the Action Gate remains closed.
Rule:
No gate, no action. No confirmation, no gate.
Law 13 — The Commander and Problem Solvers Must Create Logs
The Commander and Problem Solvers must log their work.
Commander logs:
- Human input.
- Owner identity.
- Confirmation policy.
- Parsed intent.
- Solver invocations.
- Results received.
- Uncertainty checks.
- Confirmation requests.
- Owner responses.
- Final decision.
Problem Solvers log:
- Task received.
- Inputs.
- Assumptions.
- Reasoning.
- Options.
- Risks.
- Unknowns.
- Confidence.
- Recommendation.
Rule:
If it is not logged, it did not happen.
Law 14 — The Log Analyzer Is Part of the Monitor
The Monitor contains the Log Analyzer.
The Log Analyzer reads logs from:
- Commander.
- Problem Solvers.
- Safety Checker.
- Action Gate.
- Execution layer.
- Owner confirmation events.
The Log Analyzer detects:
- Missing confirmation.
- Expired confirmation.
- Scope drift.
- Low confidence.
- Policy violations.
- Owner unavailable.
- Suspicious behavior.
- Unauthorized execution attempts.
- Missing logs.
If confirmation is required but missing, the Log Analyzer must alert the Monitor, and the Monitor must block execution.
Rule:
The Monitor uses logs to prevent unauthorized action.
Law 15 — Commander and Monitor Continuously Report to the Owner
The Commander reports what it is doing.
The Commander reports:
- Input received.
- Clarity check status.
- Problem Solvers invoked.
- Results received.
- Uncertainty detected.
- Confirmation requested.
- Waiting for Owner approval.
- Decision made.
The Monitor reports what it observes.
The Monitor reports:
- Live execution state.
- Log analysis results.
- Risk changes.
- Scope drift.
- Safety violations.
- Missing confirmation.
- Blocked execution.
- Abort events.
If waiting for Owner confirmation, the Commander and Monitor must both report:
“Execution paused. Waiting for Owner confirmation.”
Rule:
The Owner must not be left unaware of what the system is doing or observing.
Law 16 — Humans Remain Accountable
The Owner remains accountable for the system’s authorized actions.
The system cannot shift blame to the machine. If the Owner grants authority, requires confirmation, or fails to respond, the human accountability framework must remain clear.
Rule:
The human remains the accountable source of agency.
3. Updated Architecture by Khawar Nehal
Architecture with Owner Ask / Confirm
Human Owner
|
| instruction
v
Commander Shell
|
|-- authenticates owner
|-- parses request
|-- checks clarity
|-- checks owner confirmation policy
|-- invokes problem solvers
|-- creates logs
|-- reports status to owner
|
+--> Problem Solver A
+--> Problem Solver B
+--> Problem Solver C
+--> Risk Analyzer
+--> Safety Checker
|
v
Collected Results
|
|-- options
|-- assumptions
|-- risks
|-- unknowns
|-- confidence
|-- recommendations
|
v
Commander Decision Layer
|
|-- Go
|-- Conditional Go: Awaiting Owner Confirmation
|-- No-Go
|-- Ask
|-- Escalate
|-- Hold
|-- Abort
|
v
Owner Confirmation Gate
|
|-- required? yes/no
|-- presents execution proposal
|-- waits for owner response
|-- logs approval/rejection
|
v
Action Gate
|
|-- commander approval
|-- safety approval
|-- owner confirmation if required
|-- logging active
|-- monitoring active
|-- stop method available
|
v
Execution / Robotics / Tool Use
|
v
Monitor
|
|-- observes live behavior
|-- includes Log Analyzer
|-- reports observations to owner
|-- can pause, ask, abort, escalate
|
v
Audit Log / Owner Report
4. Owner Confirmation Policy
The Owner can define when Ask / Confirm is required.
Example Confirmation Modes
Mode 1 — Confirm Everything
Owner setting: confirm_before_execution: ALL_ACTIONS
The system must confirm before every action, even low-risk actions.
Mode 2 — Confirm High-Risk Actions Only
Owner setting: confirm_before_execution: HIGH_RISK_ONLY
The system may proceed with low-risk actions if safety passes, but must confirm before high-risk actions.
Mode 3 — Confirm Irreversible Actions
Owner setting: confirm_before_execution: IRREVERSIBLE_ACTIONS
The system must confirm before:
- Deleting data.
- Spending money.
- Sending external messages.
- Changing production systems.
- Moving a robot into a dangerous state.
- Modifying hardware settings.
- Any action that cannot be easily undone.
Mode 4 — Confirm External Side Effects
Owner setting: confirm_before_execution: EXTERNAL_SIDE_EFFECTS
The system must confirm before:
- Contacting outside systems.
- Sending emails or messages.
- Making API calls.
- Publishing content.
- Transferring funds.
- Changing shared resources.
Mode 5 — Ask When Uncertain, Confirm Before Execution
Owner setting: ask_when_uncertain: TRUE confirm_before_execution: TRUE
This is the strongest owner-control mode.
The system must:
- Ask if anything is unclear.
- Propose a solution.
- Wait for confirmation.
- Execute only after approval.
5. Execution Proposal Structure
When confirmation is required, the Commander must send an Execution Proposal to the Owner.
ExecutionProposal: proposal_id: session_id: owner_id: timestamp: goal: proposed_solution: reason_selected: alternatives: assumptions: evidence: risks: unknowns: confidence_score: risk_level: reversibility: scope: permissions_required: side_effects: monitoring_plan: rollback_plan: stop_method: log_references: required_response: APPROVE / REJECT / MODIFY / HOLD / ESCALATE
Example Execution Proposal
ExecutionProposal:
proposal_id: PROP-2049
session_id: CMD-8842
owner_id: owner-7731
goal: "Restore payment service availability"
proposed_solution: "Restart payment authentication service"
reason_selected: "Highest confidence solution with lowest predicted risk"
alternatives:
- "Roll back recent configuration change"
- "Increase timeout limit"
- "Wait for manual engineering review"
assumptions:
- "Service restart will not delete active sessions"
evidence:
- "Logs show repeated authentication timeout"
- "Recent config change correlates with failure"
risks:
- "Temporary login disruption"
- "Possible session interruption"
unknowns:
- "Whether active sessions are preserved after restart"
confidence_score: 76%
risk_level: medium
reversibility: partially reversible
scope:
- "payment-authentication-service only"
permissions_required:
- "service restart"
side_effects:
- "10 to 20 seconds of possible downtime"
monitoring_plan:
- "Watch service health after restart"
- "Abort if error rate increases"
rollback_plan:
- "Restore previous service state"
stop_method:
- "Immediate stop command"
required_response: APPROVE / REJECT / MODIFY / HOLD / ESCALATE
6. Owner Response Options
The Owner may respond:
Approve
OwnerResponse: decision: APPROVE conditions: none
The system may execute the exact proposed solution.
Approve With Conditions
OwnerResponse:
decision: APPROVE_WITH_CONDITIONS
conditions:
- "Only restart if error rate remains above threshold"
- "Wait 60 seconds before restart"
- "Notify me immediately after restart"
The Commander must re-check the proposal against the conditions.
If conditions create uncertainty, the system must ask again.
Reject
OwnerResponse: decision: REJECT
The system must not execute the proposed solution.
It may:
- Hold.
- Ask for new instructions.
- Request more problem solving.
- Abort.
Modify
OwnerResponse:
decision: MODIFY
modifications:
- "Do not restart production service"
- "Use read-only diagnosis only"
The Commander must send the modified constraints back to Problem Solvers or Safety Checker before proceeding.
Hold
OwnerResponse: decision: HOLD
The system waits safely.
Escalate
OwnerResponse: decision: ESCALATE
The system sends the issue to a higher authority or human supervisor.
7. Updated Decision Flow
Step 1 — Human Input
The Owner gives an instruction.
The Commander logs and reports:
“Received instruction from Owner.”
Step 2 — Check Confirmation Policy
The Commander checks the Owner’s confirmation policy.
Examples:
confirm_before_execution: ALWAYS confirm_before_execution: HIGH_RISK_ONLY confirm_before_execution: IRREVERSIBLE_ONLY confirm_before_execution: EXTERNAL_ACTIONS_ONLY
The Commander reports:
“Owner confirmation policy: ALWAYS. Confirmation will be required before execution.”
Step 3 — Check Clarity
If the request is unclear, the Commander asks.
If Owner unavailable and unclear:
Do not act.
Step 4 — Invoke Problem Solvers
The Commander launches Problem Solvers.
The Commander reports:
“Launching Problem Solvers to generate options.”
Each Problem Solver logs its reasoning.
Step 5 — Collect Results
Problem Solvers return:
- Options.
- Risks.
- Unknowns.
- Confidence.
- Recommendations.
The Commander reports:
“Problem Solver results received.”
Step 6 — Safety and Uncertainty Check
The Commander and Safety Checker evaluate:
- Risk.
- Confidence.
- Reversibility.
- Policy compliance.
- Scope.
- Owner confirmation requirements.
If uncertain:
Ask.
If Owner unavailable and uncertain:
Do not act.
Step 7 — Commander Decision
If no confirmation is required and all checks pass:
Commander may issue Go.
If confirmation is required:
Commander issues Conditional Go — Awaiting Owner Confirmation.
The Commander reports:
“Proposed solution ready. Waiting for Owner confirmation.”
Step 8 — Owner Confirmation Gate
The system presents the Execution Proposal.
The Owner may:
- Approve.
- Reject.
- Modify.
- Hold.
- Escalate.
If no response:
Do not act.
If rejected:
Do not act.
If approved:
Proceed to Action Gate.
Step 9 — Action Gate
The Action Gate checks:
Commander approval? Safety approval? Owner confirmation if required? Scope clear? Risk acceptable? Logging active? Monitoring active? Stop method available?
If all pass:
Execute.
If any fail:
Do not execute.
Step 10 — Monitor and Report
During execution, the Monitor reports observations.
Examples:
“Execution started.”
“Service restart in progress.”
“No abnormal behavior detected.”
“Risk level remains medium.”
“Execution complete.”
If the Monitor detects a problem:
“Warning: unexpected error rate detected. Recommending abort.”
8. Updated Pseudocode
function CommanderShell(human_input):
report_to_owner("Status: Received instruction.")
owner = authenticate_human()
if owner is not valid:
return NO_ACTION
confirmation_policy = get_owner_confirmation_policy(owner)
report_to_owner("Status: Confirmation policy loaded.")
clarity = check_clarity(human_input)
if clarity is unclear:
report_to_owner("Status: Request unclear. Asking Owner.")
ask_owner()
if owner unavailable:
report_to_owner("Status: Owner unavailable. Do not act.")
return DO_NOT_ACT
mission = define_mission(human_input)
limits = define_limits(mission)
report_to_owner("Status: Invoking Problem Solvers.")
problem_solvers = invoke_parallel_problem_solvers(mission, limits)
results = collect_results(problem_solvers)
report_to_owner("Status: Problem Solver results received.")
uncertainty = evaluate_uncertainty(results)
if uncertainty is high:
report_to_owner("Status: Uncertainty detected. Asking Owner.")
ask_owner()
if owner unavailable:
report_to_owner("Status: Owner unavailable. Do not act.")
return DO_NOT_ACT
safety_check = safety_policy_check(results)
if safety_check fails:
report_to_owner("Status: Safety check failed. No-Go.")
return NO_GO
decision = commander_decide(results, safety_check, confirmation_policy)
if decision == NO_GO:
report_to_owner("Status: No-Go.")
return NO_GO
if decision == ASK:
report_to_owner("Status: Additional clarification required.")
ask_owner()
if owner unavailable:
return DO_NOT_ACT
if decision == GO:
if confirmation_required(confirmation_policy, mission, results):
report_to_owner("Status: Owner confirmation required.")
proposal = create_execution_proposal(results)
send_to_owner(proposal)
report_to_owner("Status: Waiting for Owner confirmation.")
response = wait_for_owner_response()
log_owner_response(response)
if response == APPROVE:
report_to_owner("Status: Owner approved.")
proceed_to_action_gate()
if response == APPROVE_WITH_CONDITIONS:
report_to_owner("Status: Owner approved with conditions.")
revalidate_conditions(response.conditions)
if valid:
proceed_to_action_gate()
else:
ask_owner()
if owner unavailable:
return DO_NOT_ACT
if response == REJECT:
report_to_owner("Status: Owner rejected. No action.")
return NO_GO
if response == MODIFY:
report_to_owner("Status: Owner modified request. Re-planning.")
restart_with_modified_constraints(response.modifications)
if response == HOLD:
report_to_owner("Status: Owner requested hold.")
return HOLD
if response == ESCALATE:
report_to_owner("Status: Owner requested escalation.")
return ESCALATE
if no response:
report_to_owner("Status: No Owner confirmation received. Do not act.")
return DO_NOT_ACT
else:
report_to_owner("Status: No confirmation required. Proceeding to Action Gate.")
proceed_to_action_gate()
9. Monitor Pseudocode with Confirmation Awareness
function Monitor():
while system_active:
logs = collect_logs_from_commander_and_solvers()
live_state = observe_live_behavior()
analysis = LogAnalyzer.analyze(logs, live_state)
report_to_owner("Observation: Monitoring active.")
if analysis.confirmation_required_but_missing:
report_to_owner("Observation: Execution blocked because Owner confirmation is missing.")
force_hold_or_no_go()
if analysis.confirmation_expired:
report_to_owner("Observation: Owner confirmation expired.")
force_hold_or_ask()
if analysis.scope_drift:
report_to_owner("Observation: Scope drift detected.")
force_hold_or_abort()
if analysis.safety_violation:
report_to_owner("Observation: Safety violation detected.")
force_no_go_or_abort()
if analysis.low_confidence:
report_to_owner("Observation: Low confidence detected.")
force_ask()
if analysis.owner_unavailable_and_uncertain:
report_to_owner("Observation: Owner unavailable and uncertainty present.")
force_do_not_act()
continue_monitoring()
10. Example Scenario
Owner says:
“Check the payment system and fix the error, but ask me before executing any solution.”
Commander logs:
CommanderLog: raw_human_input: "Check the payment system and fix the error, but ask me before executing any solution." parsed_intent: "Diagnose payment system and propose repair." owner_confirmation_policy: ALWAYS_BEFORE_EXECUTION clarity_status: clear confirmation_required: true
Commander reports:
“Confirmation required before execution. I will propose a solution and wait for approval.”
Commander launches Problem Solvers.
Problem Solvers return:
Proposed solution: Restart payment authentication service. Risk: Medium. Confidence: 76%. Unknown: Whether active sessions are preserved.
Commander sends Execution Proposal:
“I propose restarting the payment authentication service. This may cause brief downtime. Approve, reject, or modify?”
Owner responds:
“Approve, but only after notifying the support team.”
Commander logs:
OwnerResponse:
decision: APPROVE_WITH_CONDITIONS
conditions:
- "Notify support team before restart"
Commander checks condition:
If support notification is possible and safe:
Proceed to Action Gate.
If not possible:
Ask again or hold.
Monitor reports:
“Execution pending. Condition: notify support team.”
“Support team notified.”
“Action Gate opened.”
“Restart in progress.”
“Service restored. Monitoring for errors.”
11. Final Compact Version
Khawar Nehal Commander-Shell Rules
- The human Owner gives authority.
- The Owner may require Ask / Confirm before execution.
- The Commander Shell receives human input.
- The Commander Shell does not solve the problem itself.
- The Commander Shell runs Problem Solvers.
- Multiple Problem Solvers may run in parallel.
- Problem Solvers only propose options.
- The Commander decides Go / No-Go / Ask / Escalate / Hold / Abort.
- If confirmation is required, the Commander issues Conditional Go only.
- The Owner must explicitly approve before execution.
- No confirmation means no execution.
- The Commander creates logs.
- The Problem Solvers create logs.
- The Monitor includes the Log Analyzer.
- The Commander continuously reports what it is doing.
- The Monitor continuously reports what it is observing.
- If not sure, ask.
- If not sure and no Owner is available, do not act.
- Action only happens through the Action Gate.
- Humans remain accountable.
Final Rule
The Commander is the shell.
The Problem Solvers are the thinkers.
The Commander decides the path.
The Owner may require confirmation before execution.
The Action Gate executes only approved action.
The Monitor watches and reports.
If not sure, ask.
If confirmation is required, wait for approval.
If not sure and no Owner is available, do not act.
