DEV Community: Jang-Woo Wi

Under what declared conditions is this action allowed to begin?

Jang-Woo Wi — Sat, 16 May 2026 06:57:17 +0000

Most people assume a single AI:

User → AI → Result

One AI judges, executes, and is responsible for accuracy.
This framework separates that into two layers:

User → Permission Layer → Performance Layer → Result

Permission Layer: Is this action allowed to begin?
Performance Layer: How is this action carried out accurately?
What sits inside each layer — AI model, agent, or hardware logic — is a separate question.

The Permission Layer does not judge accuracy. It only judges whether the declared conditions are met.

So the question is not:
"Can the machine brew coffee accurately?"

The question is:
"Are the declared conditions met to begin this action now?"

If the manufacturer has declared: "A cup must be placed before brewing begins" — the Permission Layer checks that condition. If the cup is not detected, the agent says: "Cup not detected. Please place a cup and try again."

Whether the coffee is brewed well after that is the manufacturer's responsibility. That belongs entirely to the Performance Layer.

We do not ignore accuracy. We reduce accuracy-related questions into declarable items — start events, end events, and target values. Whether those are implemented correctly remains the manufacturer's responsibility.

And perhaps this is where AI alignment also becomes a product quality problem.

In physical products, AI alignment is not only a model problem. If a manufacturer's product can be executed by an AI agent, declaring how that product's actions are meant to be understood and bounded is part of the manufacturer's quality responsibility.

Otherwise, the Permission Layer has nothing to check against — and the AI will fill the missing structure through general inference.
Model knowledge can help interpret.
Declared conditions must authorize execution.

There is a common leap in these discussions that I think comes from this missing layer.

Because most people's reference point for AI is prompts and vibe coding:

Prompt: User says something → AI responds → almost always executes
Vibe coding: User requests change → code changes → execution is assumed

The default is execution. Refusal is the exception.

So when people hear "AI can execute physical actions," the logic jumps directly:

AI can make coffee
→ AI can do anything
→ AI can press the nuclear button

There is no middle step. Because in the single-layer model, there is no middle step.

But physical execution is a different structure entirely:

Prompt → almost no refusal conditions → always executes
Vibe coding → limited scope → mostly executes
Physical (general) → Permission Layer → executes only if conditions are met
Physical (high-risk) → Permission Layer → much stricter conditions required
Nuclear button → entirely separate political, military, and legal structure

The nuclear button is not an AI execution problem. Human society already handles that through entirely separate structures.

The reason the leap happens is this.

If you assume a single AI layer with no refusal structure, scale is the only variable. Bigger action, same logic. That is frightening, and reasonably so.

But if a Permission Layer exists, the question changes completely.

It is no longer:
"Will AI press the button?"

It becomes:
"Under what declared conditions is this action allowed to begin?"

That is not a question of fear. That is a question of design.
And design is manageable.

Physical AI Safety: Ownership and Execution Boundaries

Ask if unsure.

Jang-Woo Wi — Thu, 14 May 2026 06:43:58 +0000

There is one piece of advice we always give to capable new employees.

Ask if unsure.

It means: if you do not know, ask.

But strangely, we almost never say this to AI today.

Most discussions move in the following directions.

Make the model smarter

internal ethics, reasoning structure, coherence, architecture, memory, agent framework
Make the output more stable

reducing hallucination, long-context coherence, structural persistence, prompt protocol
Make agents execute better

skill, tool use, runtime, workflow, persistent state, modular architecture

But one question is almost missing.

Before answering or executing, is there enough information?

Most discussions focus on how AI can answer better.

My interest comes before that.

How can we decide when not answering is the better action?

This is not a new concept.

It is something humans have always done in collaboration.

In AI research and user discussions, the usual goal is a “correct answer.”

So when the model does not know, we try to add more context, better prompts, larger models, better reasoning, and longer memory.

But the opposite direction matters just as much.

If the context is insufficient, do not keep reasoning. Ask the user.

And the way to make the unknown visible is simpler than it may seem.

Make a checklist, and if there is a blank, ask.

AI does not need to philosophically realize “I do not know.”

We can structure the required conditions for an answer or execution, and if any required item is missing, the system should ask instead of guessing.

This is not merely good manners.

It is a structural principle.

Ask if unsure is a very short sentence.

But this sentence touches many of AI’s biggest problems at the same time.

Hallucination problem: it happens because the model fills what it does not know with plausible language.
Alignment problem: the model reaches a conclusion on behalf of the user even when the user’s intent is unclear.
Agent problem: the agent executes the next action with insufficient information.
Compute waste problem: the model keeps generating on a problem it cannot responsibly answer.
Prompt engineering problem: when the user cannot express everything perfectly, the model fills the gaps by guessing.

Perhaps this point is still rare because AI systems are basically designed to always answer.

Chatbot UX, benchmarks, and user expectations mostly reward “response generation.”

But “the ability to ask a good clarifying question” is not yet a primary performance metric.

In real collaboration, this is extremely important.

A good human colleague asks when unsure.

A good engineer confirms when requirements are unclear.

A good doctor asks additional questions when information is insufficient.

A good lawyer does not make a firm claim when the facts are incomplete.

But we still do not say this enough to AI.

Stop guessing.

Ask when information is insufficient.

That is why this sentence is short, but strong.

Ask if unsure.

This is not a prompt tip.

It is a basic protocol for the age of agents.

Not “think more,” but

“stop when it is not enough.”

An entity incapable of responsibility cannot hold ownership over physical judgment.

Jang-Woo Wi — Wed, 13 May 2026 08:00:39 +0000

Every product comes with a user manual.
But today, we give AI no manual and force it to guess.

If the answer already exists, why rely on probabilistic guessing?
If you don’t know, ask.

When an accident occurs, the cause must be analyzed, and someone must bear responsibility.
Probabilistic guessing cannot be the basis of physical responsibility.

Manufacturers must define AI-readable manuals—structured as discrete action units.
AI must execute physical control only within the bounds of those manuals and with explicit user approval.

AI’s freedom exists only within the manufacturer’s boundaries and the user’s declared intent.

That is the essence of ownership.
An entity incapable of responsibility cannot hold ownership over physical judgment.
AI can never own any form of physical judgment.

Will we accept accidents until “guessing” becomes perfect?
Or will we start safe control now?

If the answer exists, do not guess. If you don’t know, ask.

Physical AI Safety: Ownership and Execution Boundaries

AISafety #ResponsibleAI #AIethics #AIControl #SafeAI #AIGovernance #HumanInTheLoop #AIregulation

Ownership is the fastest path to Physical AI — a surprising paradox.

Jang-Woo Wi — Sat, 09 May 2026 04:13:51 +0000

Ownership is the fastest path to Physical AI — a surprising paradox.

This document strongly argues for ownership and clear execution boundaries, but shows that the stricter we protect ownership, the faster and safer AI can control physical devices right now.

Link: https://discuss.huggingface.co/t/physical-ai-safety-ownership-and-execution-boundaries/175776/2

PhysicalAI #AISafety #AIagents #Robotics #IoT

The First Device AI Can Actually Understand

Jang-Woo Wi — Fri, 08 May 2026 08:20:44 +0000

Device types were built for humans. AI needs something different. Here's what that looks like — today, on ESP32-C6.

The First Device AI Can Actually Understand

Built on Matter, no firmware rewrite, no spec changes. Feedback welcome.

Physical AI Safety: Ownership and Execution Boundaries

Jang-Woo Wi — Thu, 07 May 2026 07:00:29 +0000

“Physical AI Safety: Ownership and Execution Boundaries” on @huggingface

This consolidates design notes on separating:

Manufacturer's domain (Essence + Fixed Labels for safety/physical limits)
User's domain (User Labels for intent & context)
AI's role (connector only — never infer ownership)

Clear boundaries = clear responsibility.
No more blurred accountability when things go wrong in the physical world.

Full post: https://discuss.huggingface.co/t/physical-ai-safety-ownership-and-execution-boundaries/175776

Would love thoughts from the community working on embodied AI, agentic systems, robotics safety & responsible execution.

PhysicalAI #AISafety #Robotics #AgenticAI #ResponsibleAI #EmbodiedAI

Physical AI Safety: Ownership and Execution Boundaries

Jang-Woo Wi — Thu, 07 May 2026 01:50:07 +0000

Physical AI Safety: Ownership and Execution Boundaries

https://discuss.huggingface.co/t/physical-ai-safety-ownership-and-execution-boundaries/175776

Physical AI Safety: Ownership and Execution Boundaries https://discuss.huggingface.co/t/physical-ai-safety-ownership-and-execution-boundaries/175776

Jang-Woo Wi — Thu, 07 May 2026 01:40:32 +0000

Physical AI Safety: Ownership and Execution Boundaries - Research - Hugging Face Forums

Physical AI Safety: Ownership and Execution Boundaries This document consolidates the four design notes published in the execution-boundaries repository into a single structured reference. Introduction As LLM-based agents begin to control real-world actions, call external APIs, and create changes in the physical world, we keep asking the same question: “How good and smart is this AI?” This is not a wrong question. More questions and improvements are needed. I want to add one among the many qu...

discuss.huggingface.co

AI ethics is everywhere. Execution models are nowhere. So I built one.

Jang-Woo Wi — Sun, 12 Apr 2026 13:04:35 +0000

AI ethics is everywhere.
Execution models are nowhere.

So I built one.

Because AI is starting to control real-world actions — not just generate text.

Not a paper. Not a framework.

Just JSON.
And it runs.

This is not a prompt.

It’s a pre-execution validation model that defines whether an action is allowed before execution.

Here’s how an action is defined before it’s allowed to run:

{
"Label": "Cook Jjapagetti",
"ExecutionEffect": {
"Type": "Boil",
"Target": "Stove"
},
"Boundaries": [
{ "Type": "NotStartIf", "Value": "no_water" },
{ "Type": "limit", "Value": "max-cook-5min" },
{ "Type": "warning", "Value": "fire-risk" }
],
"EventTrigger": [
{ "UserIntent": "cook_jjapagetti" }
],
"ResponsibilityLimit": {
"MaxDurationSec": 300
},
"StartImpactConstraint": [
{
"Type": "NoConcurrentHeatSource",
"Targets": ["Oven", "AirFryer"]
}
]
}

You can cook Jjapagetti.

But you shouldn’t start if there’s no water,
you shouldn’t cook it for too long,
you need to consider fire risk,
and you shouldn’t start if another heat source
(like an oven or air fryer) is already on.

This is where execution becomes constrained.

And therefore, accountable.

Model:
https://discuss.huggingface.co/t/the-9-question-protocol-for-responsible-ai-actions/173045

Full stack (IoT → AI):
https://github.com/Jang-woo-AnnaSoft/execution-boundaries

This isn’t a new AI model — it’s a way to structure execution decisions.

Jang-Woo Wi — Sun, 15 Feb 2026 05:40:10 +0000

Most discussions about AI safety focus on models.
But many real failures in production don’t come from models —
they come from unclear execution boundaries.

I’ve been exploring a small runtime design that makes execution limits explicit instead of implicit behavior.

Button-like actions slowly turning into persistent autonomy is where edge cases explode.

The idea is simple: declare allowed actions first, and make judgment paths traceable.

Full write-up:
https://github.com/Jang-Woo-AnnaSoft/execution-boundaries