Core-2 Effects, Capabilities and Boundaries

Status: normative preview; pure boundary/effect policy and native host capability guards and owned action journal implemented; source/device/solver execution unavailable

Implementation note: boundary-policy exposes the closed matrix and narrowing checks through core2_boundaries.h and zlm boundaries. Policy metadata is never an execution grant. The implementation guide is docs/core2-boundaries.md in the repository.

The capability-guards native host API implements scoped grants, attenuation, expiration/revocation, bounded attempt meters and redacted lifecycle views. It does not itself execute hardware, verify a State commit, record a Flow action or run a solver. Host constructors are not language or artifact constructors; C2-CAP-002 separately allocates their bounded CLI host adapter.

The separate action-journal native API composes live guards with owned requests, durable intent/receipts, crash-gap reconciliation, real Store post-commit release and immutable evaluator stimuli. docs/core2-actions.md describes its trusted provider contract and bounded filesystem format. Synthetic fixtures establish protocol behavior only, not physical execution, solver validity or promotion.

C2-EFF-001 — Effect order. The canonical order is io, alloc, time, random, reflect, unsafe, abort, compute, state, flow, optimize, hardware, physics. Sets are explicit, duplicate-free and canonical. Transitive inclusion and narrowing-only overrides inherit Core-1. Existing effect bits/tags are not reassigned; Core-2 extensions belong to ZLM3.

C2-CAP-001 — Live authority. Effects never create authority. Privileged operations require matching live, unforgeable, scoped capabilities. Capability types bind issuer, target/model scope, permitted operations and resource bounds. Checked artifacts contain capability requirements and typed ports, never live handles or credentials. Capabilities cannot be serialized into checkpoints, cloned by reflection or retained after session closure.

Boundary operation	Required authority	Effects added to inherited requirements
elaborate/simulate component	Elaborator / Simulator	hardware
synthesize/implement design	Toolchain	hardware
configure/readback/exchange/observe	Fabric bound to the target	hardware; io for physical I/O
measure intrinsic device	Measurement plus Fabric if driving/configuring	hardware, io
solve/evaluate SolverPlan	Solver	physics
generated proposal	existing compiler or Optimize admission	inherited effects; hardware/physics for evaluations

Pure static checking requires no physical authority. Time, random, allocation and external I/O effects are included when the operation’s declared contract uses them; a simulator is not implicitly granted hardware access.

C2-CAP-002 — Per-invocation reference-simulator host issuance. The hardware-simulation-cli adapter is a trusted local host for the caller’s explicitly authorized finite reference simulation. The trust boundary is the native CLI process and its calling host, not the source program, schedule, artifact or report. --allow-simulator is required caller opt-in to this local host policy; it is not an externally signed credential. The IDE may invoke this adapter only for a simulation request with allow_simulator: true and explicit finite work/byte budgets. An IDE request without that opt-in rejects.

Each invocation must create fresh issuer/session identities, restrict the capability kind to Simulator and the operation set to SIMULATE, and bind the component scope to the exact freshly checked native model identity. The operation limit is max_steps + 1 (one open and at most max_steps samples); max_steps is 1…1024, default 64. Caller-supplied work and byte budgets are independent integers in 0…1099511627776; zero is not unlimited. Expiration is 30 seconds after a fresh host monotonic-clock reading. Failure to obtain fresh identities or the clock, or deadline overflow, rejects issuance. These limits do not replace the model’s independent structural, sample or trace bounds. Every open and step still consumes the matching live capability under C2-CAP-001; a previous admission or recorded report cannot authorize a step.

The grant is non-exportable and scoped to this invocation. Source, schedule, flags and artifacts cannot supply a serialized issuer, capability or credential. The host closes its authority before publishing retained result data; another invocation requires fresh admission. No Fabric, Toolchain, Measurement or Solver authority is granted, and no device access, attested evidence or promotion is implied. The closed options and output/resource contract are delegated to docs/core2-simulation-cli.md in the repository. This allocation does not create a general-purpose CLI authority issuer.

C2-BOUND-001 — Closed callable matrix. The existing 5x5 submatrix is preserved. A dash forbids the crossing. Named crossings are typed boundaries, not direct calls; only diagonal entries admit direct composition/calls.

From / To	algorithm	compute	state	flow	optimize	hardware
algorithm	direct	Device.run	Store.transact	FlowEngine.start	Optimizer.run	simulator/fabric operation
compute	owned return	direct	—	—	—	—
state	post-commit reaction/outbox	post-commit reaction/outbox	direct	post-commit reaction/outbox	post-commit reaction/outbox	post-commit command/outbox
flow	recorded activity	recorded activity	recorded activity	direct	recorded activity	recorded hardware activity
optimize	report return or sealed pure evaluation	sealed compute evaluation	—	—	direct	sealed realization/evaluation
hardware	typed host/peripheral bridge	—	—	—	—	static direct composition

Hardware-to-host traffic is a port protocol with capacity, ownership, backpressure, ordering and error/timeout behavior. It does not grant hardware permission to invoke arbitrary software or enter a State transaction. Optimize evaluation may access physical hardware only within its sealed evaluator’s explicit capabilities, budget and recorded stimulus/observation envelope. It cannot publish State/Flow effects through a disguised host bridge.

C2-BOUND-002 — Physical models. Physics has no row or column. Algorithm invokes a solver; Flow records a solver run and its immutable result; Optimize proposes/evaluates SolverPlans through a sealed evaluator. State may stage a post-commit solver command through its existing outbox. Compute and hardware cannot directly invoke solvers; mixed simulation is orchestrated by an admitted host plan. Solver-selected implementation does not change the domain of the source contract.

C2-BOUND-003 — Durable physical actions. State stages owned command data, not live authority. An after-commit worker reacquires authority before issuing the command. Flow records request identity, attempt, target, receipts, results and uncertainties. Replay consumes recorded outcomes. If a crash occurs after a physical effect but before its receipt, automatic reissue requires a device deduplication/reconciliation contract; otherwise the activity becomes indeterminate and requires reconciliation. Exactly-once physical execution is not inferred from durable software bookkeeping. Failures release scoped resources and preserve enough receipt/provenance data for recovery.

C2-CAP-003 — Zero-step checked inspection. This clause supersedes only C2-CAP-002’s unconditional lower bound on max_steps: max_steps is 0…1024 for checked inspection and 1…1024 for hardware-simulate; the default remains 64. Zero-step checked inspection may check and report a source-resolved hardware artifact without running a sample. It does not authorize execution without a fresh Simulator capability. The operation budget remains max_steps + 1, including the open charge, and every other scope, byte/work, deadline and non-exportability bound in C2-CAP-002 remains unchanged.

C2-CAP-004 — Checked-profile zero-sample execution. This clause clarifies and supersedes C2-CAP-003’s command-name distinction: the lower bound follows the profile, not the command name. For source-resolved-combinational/1, max_steps is 0…1024 for both checked inspection and checked execution, including run and hardware-simulate. For the unchecked combinational and clocked simulation profiles, max_steps remains 1…1024. Zero-sample checked execution still requires caller opt-in, fresh scoped Simulator authority and the open charge; a nonempty schedule exceeds its zero-step bound. There is no budget, deadline, capability or source-closure bypass.