Common boundary questions.

Is RuleOak a prompt guardrail?

No. Its primary boundary is concrete actions, not model text. Prompt/content signals can be contextual inputs, but authorization/effect evidence is the core.

Is RuleOak a sandbox?

No. Actions that bypass the SDK/CLI/MCP boundary remain outside enforcement. Use OS/process/network controls for containment.

What makes an Effect Boundary different from policy-only?

Policy-only can answer “may execute.” A full Effect Boundary also has trusted postcondition semantics for the relevant action so outcome/retry state can be established.

What happens when the effect cannot be verified?

The outcome stays unresolved. RuleOak should recommend verification rather than manufacturing success/no-effect from a timeout, exit code or HTTP status.

Why one-use execution authority?

It binds authorization to one attempt and makes simple replay explicit. A later retry requires fresh authority.

Does RuleOak require cloud infrastructure?

No for core public workflows. It is local-first. External services you choose to integrate remain separate provider boundaries.

Is the local evidence tamper-proof?

No. Hash chaining is tamper-evident for the recorded sequence; a privileged local actor can replace/delete the entire store unless evidence is externally anchored.

Is v0.50.0 production-ready?

It is a pre-1.0 developer preview for evaluation, controlled pilots and integration testing. Production-like use requires review against your threat model and operating environment.