HackerTrans
TopNewTrendsCommentsPastAskShowJobs

Jang-woo

no profile record

Submissions

[untitled]

1 points·by Jang-woo·2 maanden geleden·0 comments

[untitled]

1 points·by Jang-woo·3 maanden geleden·0 comments

Show HN: Answer 9 questions, get a Matter firmware with safe boundaries

anna.software
3 points·by Jang-woo·3 maanden geleden·1 comments

[untitled]

1 points·by Jang-woo·3 maanden geleden·0 comments

[untitled]

1 points·by Jang-woo·3 maanden geleden·0 comments

Show HN: Stop programming devices. Just answer questions

github.com
4 points·by Jang-woo·3 maanden geleden·1 comments

Should AI have the right to say 'No' to its owner?

github.com
5 points·by Jang-woo·3 maanden geleden·33 comments

We may not have a model problem – we may have an execution boundary problem

github.com
1 points·by Jang-woo·5 maanden geleden·0 comments

comments

Jang-woo
·3 maanden geleden·discuss
Boundaries sounds complex, but it's just one of your answers. If AI is going to control your device, you define the minimum it needs to know.

Example: Caution: heat risk
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
That's a great connection.

You're right that current systems aren't close to that level of reasoning.

What I'm wondering is whether we can approximate some of it structurally — by defining when execution is allowed or not — even without that level of sophistication in the model itself.

Curious how far you think simple constraint systems can go before something like that kind of reasoning becomes necessary.
Jang-woo
·3 maanden geleden·discuss
One thing we realized while building this:

Commands don’t give control.

Defining conditions does.

Curious how others think about this — especially when AI starts interacting with physical systems.
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
I think you're reading it more strongly than I intended.

The point about "ownership" in that document is more about where authority over execution sits, not about restricting what AI is allowed to reason about.

So it's not saying "AI shouldn't reason about things it doesn't own," but rather asking who has the authority to define and enforce the conditions under which actions are allowed to execute.

I agree that in current systems (like smartphones), a lot of this is already handled through predefined constraints.

What I'm trying to explore is whether that idea needs to be extended or structured differently when the system has more autonomy and operates in less predictable environments.
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
That's really interesting — thanks for sharing the notes.

The "rebel agent" framing feels very close to what I'm trying to get at, especially the idea that refusal can be part of correct behavior rather than failure.

One difference I'm trying to think through is where that decision lives.

In a lot of these examples, the agent itself decides to deviate based on its understanding of the situation.

What I'm wondering is whether we can (or should) define that earlier — at the level of the action itself.

So instead of the agent deciding to "rebel" at runtime, the system would already encode when execution is permitted, and refusal becomes the default if conditions aren't met.

The explanation part you mentioned also seems important — not just saying "no", but making it legible why execution wasn't allowed.

Curious how much of that work treats rebellion as something emergent from the agent, vs something structurally defined in the system.
Jang-woo
·3 maanden geleden·discuss
[dead]
Jang-woo
·3 maanden geleden·discuss
That's a good point.

I think you're right that at the model level, competition pushes toward "always say yes."

What I'm wondering about is whether control needs to exist at a different layer — not in the model itself, but in the system that decides whether actions are allowed to execute.

In other words, even if a model is willing to say "yes," the system using it might still need to decide whether execution is permitted.

Otherwise, it feels like we're relying entirely on model behavior for safety, which seems fragile in competitive environments.
Jang-woo
·3 maanden geleden·discuss
I've been thinking about AI systems acting in the physical world.

Most discussions about control focus on what the system should do, and how to make execution reliable.

But it seems like a lot of real-world failures aren't about incorrect execution.

They're about execution happening at all.

An action can be technically correct — executed exactly as specified — and still be the wrong thing to do because the context has changed.

This made me wonder if control should be framed differently.

Instead of focusing on defining actions, maybe we should focus on defining when actions are allowed to happen.

In other words, control might be less about execution and more about permission.

If conditions aren't satisfied, the system shouldn't try and fail — it simply shouldn't execute.

I'm curious if people have seen similar issues in real-world systems, or if this framing connects to existing work.
Jang-woo
·5 maanden geleden·discuss
[dead]
Jang-woo
·5 maanden geleden·discuss
It’s encouraging to see the conversation shifting from model performance toward execution responsibility and security structure.
Jang-woo
·5 maanden geleden·discuss
Really appreciated this perspective.

A lot of conversations focus on what models can become, but far fewer ask where judgment actually lives when these systems begin to act.

The uncertainty you describe isn’t just philosophical — it’s a design constraint.

Maybe the next leap isn’t only about understanding the model, but about structuring the boundaries around execution.
Jang-woo
·5 maanden geleden·discuss
Really interesting read. This feels less like a security bug and more like a missing execution boundary.
Jang-woo
·5 maanden geleden·discuss
[flagged]