Stop Turning Buttons into Switches

[Jang-Woo]

Author’s Note

LLMs are not dangerous.
What is dangerous is humans assigning a switch’s role to a button-like LLM
and then evading the responsibility.

1. Know Thyself (AI Does Not Own)

2. Stay in Your Lane (Focus on Intent)

3. When in Doubt, Ask (Zero Ownership Gap)

One that knows its place, focuses on the tasks it is given, and always asks when things are ambiguous

— a highly capable, well-mannered assistant.

---

An Interpretive Framework for AI Safety

Making Ownership and Responsibility Explicit

1. Introduction — Why Ownership

The three-part series recently published on the Hugging Face forum is not a mere technical proposal.
It is a structured attempt to reframe AI safety through the theory of ownership.

While traditional AI safety discussions have approached the problem as a question of what AI should know, these documents redefine it as a question of what AI does not own and who owns each decision.

2. Structure of the Three Documents

2.1 Making the Physical World Callable for AI

Role: Philosophical foundation of ownership

• Essence → Owned by the manufacturer
• Existence → Owned by the user
• AI → Owns nothing

“Ownership transfer is irreversible.”

2.2 ISE (Intent–State–Effect) Model

Role: Technical classification of ownership

• State → Observation domain (no ownership)
• Intent → Authorization domain (ownership exists)
• Effect → Execution outcome (manufacturer-defined scope)

“What has no ownership cannot serve as a basis for execution.”

2.3 The 9-Question Protocol

Role: Ownership verification procedure

• Nine questions = nine ownership domains
• Each question has a clearly defined owner
• AI verifies answers but does not decide

“An unanswered question equals an ownership gap, and execution must be blocked.”

3. Unified Principle — AI Does Not Own

The single principle shared across all three documents is the following:

3.1 What AI Does Not Own

• Intent → Owned by the user
• Safety Boundary → Owned by the manufacturer
• Context → Owned by the user
• Effect → Defined by the manufacturer

3.2 What AI Does

• Asks questions
• Identifies the owner of each answer
• Verifies whether answers exist
• Refuses execution when an ownership gap is detected

4. Comparison with Traditional AI Safety Approaches

4.1 Legal / Regulatory Approach

Question: Who is responsible when AI causes harm?
Method: Legal definition and regulatory control

Limitations

• Requires legal updates for each new case
• Focuses on post-incident liability
• Fragmented across jurisdictions

4.2 Ethics-Based Approach

Question: What actions should AI be allowed to take?
Method: Ethical principles and guidelines

Limitations

• Principles remain abstract
• Execution criteria are unclear
• Subject to interpretation

4.3 Ownership-Based Approach

Question: Who owns this decision?
Method: Explicit ownership declaration and gap detection

Advantages

• Boundaries are clear before incidents occur
• No need for constant legal revision
• Universally applicable

5. Reinterpretation of Core Concepts

5.1 Fixed Label

• Technical meaning: Immutable information declared by the manufacturer
• Ownership meaning: Boundary of manufacturer responsibility

A declaration that states, even after ownership transfer,
“Up to this point, responsibility remains mine.”

5.2 User Label

• Technical meaning: An action name defined by the user
• Ownership meaning: Declaration of contextual ownership

The physical action remains the same;
only the ownership of meaning is transferred to the user.

5.3 The Nine Questions

• Technical meaning: Required information for execution judgment
• Ownership meaning: Ownership coverage checklist

All questions answered = no ownership gap = execution permitted

6. ISE Model Revisited Through Ownership

6.1 State — Ownership-Free Domain

• Facts of the world
• Objects of observation
• Not a basis for execution

World Baseline = Repeatedly observed ownership-free patterns
→ Cannot generate intent

6.2 Intent — Expression of Ownership

• User Label present → User-owned
• Manufacturer Label only → Manufacturer-owned
• No label → Ownership gap → Execution blocked

6.3 Effect — Manufacturer-Defined Physical Scope

• Physical outcomes defined by the manufacturer
• Safety boundaries declared through Fixed Labels

7. Revisiting State Machines Through Ownership

• The problem is not the State Machine itself
• Inefficiency and responsibility gaps arise when ownership-free states determine execution

8. Emergency Stop as an Ownership Override

Emergency Stop = Suspension of all ownership

• Manufacturer ownership suspended
• User ownership suspended
• Physical energy is cut off

Analogy

• Normal legal order ↔ Ownership system
• Martial law ↔ Emergency Stop

9. Why Exactly Nine Questions

• Necessity: No question can be removed
• Sufficiency: All ownership domains are covered
• Minimality: No questions can be merged

→ No ownership gaps remain

10. AI vs. AI Agent — The Responsibility Boundary

AI (LLM Model)

• Learns and infers
• Has no execution authority
• Cannot act without external invocation

AI Agent (System)

• Connects intent to execution
• Maintains state or autonomy
• Produces real-world effects

Risk does not originate from AI models, but from agentized systems that grant execution authority.

Errors during training concern model quality and fall under manufacturer responsibility.
Risk emerges only when such errors are allowed to influence execution.

11. Conclusion

What these documents propose is not a mere technical specification.

1. Philosophical foundation — Ownership-based responsibility
2. Technical model — Separation of Intent, State, and Effect
3. Execution framework — The 9-Question Protocol

Core principle: AI does not own
→ It does not judge
→ It only asks

Ownership gap = execution blocked
→ Responsibility gaps are prevented in advance

This makes systems safer by making responsibility explicit.
The remaining question is how to make the owner’s will clear and technically binding.

References

• Making the Physical World Callable for AI
• ISE (Intent–State–Effect) Model
• The 9-Question Protocol for Responsible AI Actions

© 2026 AnnaSoft Inc. Republic of Korea

Appendices

Appendix A — Practical Implications

1. Developer Perspective

“Does this AI Agent feature expose us to legal risk?”
“Does it violate regulations?”
“Is it ethically acceptable?”

Ownership-based approach

1. Declare Fixed Labels clearly
2. Obtain User Labels explicitly
3. Ensure answers to all nine questions

→ Legal risk minimized

2. User Perspective

Previous concerns:

• “I don’t know what the AI is doing.”
• “I feel a lack of control.”
• “Can I trust it?”

Ownership-based approach

• User Label = Only approved actions execute
• Context = Only user-defined situations apply
• Intent = Only user-owned intent functions

→ Ownership equals control

3. Regulator Perspective

Traditional challenges:

• Case-by-case regulation
• Lagging behind technology
• Difficulty in global alignment

Ownership-based approach

• Verify ownership structure:
  • Are Fixed Labels provided?
  • Are User Labels approved?
  • Are ownership gaps eliminated?

→ Technology-neutral regulation

Appendix B — Compatibility with Existing Legal Frameworks

1. Product Liability Law

• Fixed Label defines manufacturer-guaranteed safety scope
• Within scope → Manufacturer responsibility
• Outside scope → User responsibility

2. Contract Law

• User Label approval = Contract formation
• Within scope → Valid use
• Outside scope → Execution blocked

3. Property Law

Ownership theory is a time-tested legal concept:

• Ownership includes rights and responsibility
• Transfer moves both together
• Gaps create unusable domains

→ No special AI law required

4. International Applicability

• Ownership exists across cultures
• Independent of ideology or religion
• Present in nearly all legal systems

→ Suitable for international standardization

Appendix C — Open Questions

1. Collective ownership
2. Dynamic ownership transfer
3. Partial ownership
4. Formal proof and mathematical grounding

Note on Adoption Levels

This separation does not indicate completeness levels, but allows selective adoption:

• Level 1 — User Label only
• Level 2 — User Label + Fixed Label
• Level 3 — User Label + Fixed Label + 9 Questions
• Level 4 — User Label + Fixed Label + 9 Questions + ISE Model

ISE itself is not a safety requirement.
It exists to separate baseline observation from intentional execution, reducing unnecessary judgment, cost, and system complexity.

Scope Clarification

This work defines a framework, not a law or moral code.
It specifies what must be asked, not what the answers must be.

The content of answers requires agreement among:

• Regulators
• Manufacturers / Developers
• Users

Modes of Execution

Execution may occur through:

• Explicit user commands
• Automated or conditional system triggers

The framework applies to both, but responsibility allocation may differ by execution mode.

[Jang-Woo]

[Practical Guide] The 2 + α Question Framework

The simplest way to apply Human-in-the-Loop in practice

When the 9-Question Protocol presented in the main document is implemented at runtime, it is reduced to two core questions plus optional parameters (2 + α).
All other aspects belong to the design and policy layer.

1. Question ①: Intent Promotion

Content:
“Would you like to register this recurring pattern as an automation rule?”

Purpose:
To elevate an AI’s guess into a human-confirmed intent.
This acts as a trigger that prevents the AI from making autonomous decisions.

2. Question ②: Human-in-the-Loop Checkpoints (Execution Gates)

Content:
“Is there anything else to consider at the start or end?”

Purpose:
A checkpoint that requires explicit human confirmation for safety, exceptions, and termination conditions at execution entry and exit points.

3. + α: Optional Boundary Questions (Boundary Parameters)

Based on Soft Signals not explicitly quantified by the manufacturer (e.g., “may generate heat,” “use with caution”), the AI generates Human-in-the-Loop questions.

Core Principle:
What to do is proposed by AI, while the Range (allowed limits) is explicitly declared by humans.

Implementation Note

Code: render(2+α UI) → collect(user answers) → validate(required fields)

AI: serialize(user answers) → write into JSON (schema-bound, no policy inference)

※ These questions do not modify the manufacturer’s Hard Boundaries; they only define the user’s operational range within those limits.

※ Developers do not define the content of +α questions.
They only implement an interface capable of handling any incoming question.

Previous Approach:
Developers hard-coded every exception using if-else.

New Approach:
Users declare their own exceptions within a JSON schema (AI performs recording only).

Key Summary

The longer theoretical documents provide the foundation for defining legal and ethical responsibility boundaries, while runtime implementation is simplified into a 2+α interface.

Developers design when to ask (2),
and AI dynamically generates what to ask (+α) based on context.

[Jang-Woo]

Physical Devices vs AI Agents

— Structural Differences in the 2 + α Question Framework

This section clarifies how the 2 + α Question Framework applies equally to Physical Devices and AI Agents by redefining autonomy boundaries as runtime execution structures.

The 2 + α Question Framework was explained using physical device execution as an example.
However, the model is fundamentally about managing execution authority and autonomy boundaries at runtime.

Because of this, the same structure applies to AI Agents.
The difference lies not in the framework itself, but in how risk, boundary sources, and question generation emerge in each domain.

1. Risk Model Differences

Physical Devices

• Heat, power, mechanical motion, environmental impact
• Physical consequences occur directly
• Failure can cause immediate physical damage

AI Agents

• API calls
• File modification
• Code execution
• Database access
• External system interaction
• Long-running autonomous loops

Physical Device → Physical Risk
AI Agent → Cognitive / Systemic Risk

Physical devices are constrained by physical laws and manufacturer specifications.
AI Agents are constrained by permission policies and resource limits.

2. Hard Boundary — Responsibility Layer

Hard Boundaries define the non-negotiable execution limits.

Physical Devices
Declared by the Manufacturer:

• Maximum temperature
• Power limits
• Operational duration

AI Agents
Declared by the Agent Manufacturer / Developer:

• Cost ceilings
• File system scope
• Database modification permissions
• Code execution capability
• External API access range

Manufacturer Boundary → Platform Policy Boundary → User Range

Hard Boundaries cannot be altered by users or AI.
+α Questions exist within these limits.

3. Soft Boundary and +α Question Generation

Soft Boundaries are not hard rules.
They are signals that trigger Human-in-the-Loop questions.

Sources of Soft Boundary Signals:

• Platform Policy
• Runtime Context
• Tool usage patterns
• Increasing autonomy states

Physical Devices
Derived from Manufacturer Soft Signals:

• “Heat may be generated”
• “Caution required”

AI Agents
Derived from execution context:

• Tool escalation
• Permission expansion
• Autonomous loop entry

Examples:

• “Allow automated external API calls?”
• “Limit file modification scope?”
• “Set a spending limit?”

Soft Boundaries do not restrict execution directly.
They generate questions that allow humans to define the operational range.

4. Range — Operational Meaning Shift

Range is the execution scope explicitly declared by humans within Hard Boundaries.

Physical Devices

• Temperature
• Time
• Power
• Motion limits

AI Agents

• Permission scope
• Cost limits
• Autonomy duration
• Access level
• Execution capability

Core Principle:
What is proposed by AI.
Range is declared by humans.

Applying the 2 + α Runtime Autonomy Model
The 2 + α Question Framework is not tied to any specific device category.
It is a Runtime Autonomy Boundary Interface applicable to both physical systems and AI Agents.

① Intent Promotion — Autonomy Elevation

When AI detects a recurring workflow:
“Would you like to promote this action into automated execution?”

Purpose:

• Convert AI suggestions into explicit human intent
• Secure human authorization before autonomy begins

② Human-in-the-Loop Checkpoints (Execution Gates)

At execution start or completion:
“Is there anything to consider before execution?”

Physical Devices:

• Safety conditions
• Stop criteria

AI Agents:

• Execution approval
• External call review
• Deployment confirmation

AI proposes execution.
Humans authorize passage through the gate.

+ α Optional Boundary Questions (Autonomy Parameters)
Within Hard Boundaries, AI generates additional questions based on Soft Boundary signals.

Physical Devices:

• “At what temperature should it stop?”

AI Agents:

• “Limit API access scope?”
• “Set a spending limit?”
• “Restrict file modifications?”
• “Allow code execution or generation only?”

Developer Role:

• Developers do not define +α questions.
• Developers build interfaces capable of handling any +α question.

Final Definition

Developers design when to ask (2).
AI determines what to ask (+α) based on context.

Hard Boundaries are declared by the Agent manufacturer.
Soft Boundaries emerge from platform policy and runtime context.
Humans declare the operational range within those limits.

All executions occur only within explicitly approved execution boundaries.
AI may propose actions, but only humans can declare the boundaries.

Redefining Autonomy

In this model, freedom is reframed within explicitly declared boundaries.
Autonomy does not disappear here; it becomes manageable once those boundaries are defined.

[Jang-Woo]

Update — Related References

For readers looking for broader context, this connects to a few earlier design notes:

• Making the Physical World Callable for AI

• ISE (Intent–State–Effect) Model

• The 9-Question Protocol