Explicit host routes, live capability scopes, pure checking and durable effects.
Effects, Capabilities, and Boundaries
C3-BOUND-001 — Effects and callable routes
Core-3 appends intent after physics in the inherited effect order. It
identifies access to the Intent host protocol, not an inferred property of
English text. Proof terms are pure and have no effect row. Existing six-domain
tags and the Core-2 boundary matrix remain unchanged.
Physics, Proof, and Intent are not additional callable domains.
| Origin | Route to runtime Intent |
|---|---|
| Algorithm | Explicit IntentEngine.run host call with declared effects and live authority |
| Flow | Recorded activity through an authorized Algorithm host boundary |
| State | Owned request in a post-commit outbox, then authorized host delivery |
| Compute | No direct model/Intent calls; host dispatch occurs outside the kernel |
| Optimize | No Intent in pure signals/evaluation; host orchestration occurs outside the signal |
| Hardware | No direct model/Intent calls; an external host may react to owned observations |
| Physics | No model-side invocation; host orchestration is separately authorized |
| Proof | No invocation during checking/conversion; external search may propose terms |
| Intent candidate | Existing checked operations only; nested Intent needs explicit delegated host authority and shared limits |
An allowed route is not an execution grant. Effects include all operations the
candidate can perform, not only intent; the generator may not conceal IO or
hardware access behind the Intent effect. The checked intent interface fixes
the maximum candidate-effect set before resolution, and every candidate’s
effects must be a subset. Live capability possession cannot widen that set.
C3-BOUND-002 — Live authority and scope separation
An IntentEngine capability is host-issued, unforgeable, lifetime-bound, and
not serializable. Its scope specifies admitted request/intent identities,
providers, context sources/destinations, approval principals and delegation,
validation services, candidate operation/effect allowlists, and resource limits.
It references or borrows separately granted execution capabilities; it does
not mint Device, Store, FlowEngine, Solver, Simulator, or Fabric authority.
Persisted policies, approvals, proof receipts, and requests record requirements and provenance only. Capability checks occur against live host state at each effect. Revocation, expiry, owner mismatch, or insufficient remaining budget prevents dispatch. A successful mathematical proof cannot override those checks.
C3-BOUND-003 — Compiler, search, and execution trust
The pure compiler/bootstrap host ABI does not gain model access through this
edition. Existing developer-generation protocols retain their original scope.
Runtime Intent is an explicit application host boundary under intent-preview,
not implicit evaluation of .zl.md during an ordinary build or artifact load.
Proof search and code synthesis are untrusted and may be nondeterministic. The host constrains their inputs, outputs, subprocesses, and services; the kernel checks completed proof objects without consulting them. An external checker can supply evidence only under a named trust policy or by producing a certificate translated to the Zerg kernel. Lean acceptance is not by itself Zerg acceptance. Testing a candidate must not release production capabilities before admission; isolated test authority is separately scoped.
C3-BOUND-004 — Durable and physical effects
State emits requests only after a successful commit; aborting the transaction must not trigger a model call. Flow records the request/result boundary for replay. For device/network effects, preserve owned action identity, freshness, deduplication and reconciliation semantics from the inherited boundary. Neither an Intent plan nor its proof turns a crash gap into atomic external execution. Effects may remain indeterminate, and retries require the declared idempotency/recovery policy and fresh live authority.