I0 typed isolation-provider contract

Contract status: Accepted. I0 is the authoritative typed process-isolation contract; implementation remains gated by ARCH-29.

Implementation status: Not started. This document does not implement an isolation provider or provider substrate.

I0 specializes the accepted D1 kernel invariants and provider control-plane contract for process isolation. It defines the exclusive provider boundary behind Tyrum's existing governed process tools. It does not change the model-facing tools, add a provider framework, register local_spawn, or supply a hardened backend.

Quick orientation

• Read this if: you are designing or reviewing the typed provider boundary behind Tyrum's process tools.
• Skip this if: you need current process.run or durable-background behavior; use ARCH-24 or ARCH-26.
• Go deeper: use D1 for shared provider control-plane rules and ARCH-29 for dependency order.

The diagram is the I0 target contract, not implemented runtime flow.

Decision summary

Tyrum will have one typed process-isolation provider kind. For each process operation, the kernel binds exactly one implementation selected by an operator-authored process profile. The provider owns the mechanism that launches and contains the workload; Tyrum keeps tool exposure, governance, canonical state, durable operation identity, output policy, and audit authority.

The first implementation sequence remains separate future work:

1. represent the truthful current local_spawn behavior as the built-in baseline implementation;
2. add one genuinely confined implementation that proves the exact hardened posture it claims;
3. route the existing foreground and durable process tools through immutable provider bindings.

I0 is the contract for that sequence, not evidence that any item exists.

Current truth

• process.run executes through the gateway's local runner and reports backend local_spawn with baseline confinement.
• process.start delegates local launch and process ownership to Tyrum's independent background supervisor; process.get, process.logs, and process.cancel use the canonical durable run record and supervisor protocol.
• The operator setting process.requiredConfinement accepts baseline or hardened. baseline is the current default. hardened is unavailable and fails closed.
• Foreground and background execution already preserve direct argv, lexical workspace cwd checks, bounded output, minimal environment projection, governance, approval linkage, and truthful process-tree limitations.
• Local cwd checks, process groups, a separate supervisor, and durable database rows do not prove filesystem, network, identity, privilege, syscall, resource, daemon-escape, or machine-restart confinement.
• No provider catalog, isolation-provider implementation, hardened backend, provider binding persistence, or provider conformance harness exists.

I0 must preserve this truth during later adoption. It must not describe the target architecture as current behavior.

Goals

• define one narrow typed contract for process isolation rather than a universal provider operation;
• preserve existing model-facing process tool contracts and governance;
• make provider selection exclusive, deterministic, operator-controlled, and immutable per operation;
• distinguish provider code deployment from the workload target and isolation boundary it manages;
• replace the ambiguous hardened label with a typed, testable minimum posture;
• preserve foreground and durable-background lifecycle truth, including ambiguous launch and recovery;
• keep local_spawn as a truthful baseline candidate without granting it a hardened claim;
• define the evidence and conformance required for one future confined implementation;
• fail closed without fallback when an operator-required posture is unavailable.

Non-goals

• no implementation of I1, I2, I3, or I4;
• no provider substrate, registry service, marketplace, dynamic hot reload, or distributed lifecycle;
• no universal operational Provider interface;
• no managed-node placement, node inventory, scheduler, fleet registry, or generic dispatch protocol;
• no alternate conversation-turn executor;
• no model-selected provider, target, deployment mode, or isolation downgrade;
• no change to tool exposure, policy, approval, or process request/result schemas;
• no new database tables or migrations;
• no claim that a container, virtual machine, remote service, process group, namespace, or separate UID is sufficient by name alone;
• no automatic restart of an ambiguously accepted or interrupted state-changing process.

Scope, identity, and cardinality

I0 defines ProviderKindId tyrum.provider.process-isolation at an initial ProviderContractVersion selected under D1. It specializes D1 identities rather than replacing them.

The provider kind's cardinality is exclusive: each canonical foreground or durable process operation receives exactly one ProviderBindingId and one selected implementation release. Ordered-many, additive, fan-out, and model-routed composition do not apply.

Selection comes only from an operator-authored process profile. The model cannot select or influence provider identity, implementation version, release, provider deployment mode, workload target, required isolation profile, fallback, or downgrade. None of those fields may appear in model-supplied tool arguments.

One process profile names one exact implementation release for the process family. A release may support both foreground and durable-background operation modes. The profile may map those kernel-owned operation classes to explicit provider deployment modes only when the mapping is deterministic and model-independent. Each resulting binding records one exact deployment mode.

I0 v1 has no fallback list. If the selected implementation, exact release, configuration, conformance evidence, operation mode, target, or required posture is unavailable, the affected process tools are unavailable and invocation fails closed.

A workload target is not a Tyrum managed node. I0 grants no node identity, placement, scheduling, discovery, or fleet-management semantics.

Public compatibility boundary

The existing model-facing process family remains:

• process.run — synchronous governed execution;
• process.start — durable-background start returning an opaque handle;
• process.get — read the canonical run state;
• process.logs — read one bounded stdout/stderr source range;
• process.cancel — persist and deliver idempotent cancellation intent.

Their request and result contracts remain unchanged unless a later independent decision explicitly changes them. Provider identity, workload target, deployment mode, and isolation controls are not added to model arguments.

The current process taxonomy, exact allow-list requirements, execution-profile restrictions, policy match targets, untrusted-shell approval escalation, workspace ownership, lease behavior, handle authorization, and structured evidence boundary remain kernel-owned.

The native Tyrum runtime remains the only conversation-turn executor. A provider launches ordinary child workloads behind a governed tool call; it does not execute turns, choose tools, request approval, or commit conversation state.

The existing operator-facing status fields may continue to expose process_backend, required/applied confinement, availability, and a safe unavailable reason. Richer typed posture may be added only as an additive operator/status contract, not by changing model-facing process results.

Contract terms

Term	Meaning
Process profile	An operator-authored immutable selection/configuration revision for the process-isolation kind.
Operation mode	Kernel-owned class foreground or durable_background; never model-selected provider routing.
Workload target	Provider-kind-specific local/isolated/remote execution boundary that runs the child workload.
Provider deployment mode	D1 in_process, local_service, or remote_service; where provider code executes relative to the gateway.
Required posture	Typed minimum isolation dimensions derived from the selected baseline or hardened profile.
Applied posture	Kernel-normalized evidence of controls applied to one exact workload execution.
Process run ID	Kernel-issued canonical identity for one at-most-once process launch intent.
Provider execution locator	Opaque provider-owned locator for observation, output, cancellation, cleanup, and recovery under one binding.

An implementation may use a host process, container, VM, local service, or remote execution boundary internally, but the target type does not prove isolation posture.

Kernel-owned responsibilities

Tyrum owns and enforces:

• exact tool exposure, process-family policy, approval, and provenance handling;
• tenant, actor, agent, conversation, workspace, and canonical process-run identity;
• authorization, workspace lease acquisition/renewal policy, quotas, and selection scope;
• D1 registration, compatibility, trust, conformance, selection, and immutable binding;
• operator process-profile resolution and minimum required posture;
• canonical launch request construction, request hashing, and at-most-once launch identity;
• executable/argv/environment/cwd validation before provider dispatch;
• secret-reference resolution and least-privilege projection after governance and binding;
• execution cutoff, final settlement deadline, cancellation intent, shutdown policy, and canonical state transitions;
• normalization of provider observations, health, capability, cancellation, and cleanup evidence;
• canonical durable process state and exact-binding recovery decisions;
• output budgets, secret redaction policy, model-boundary sanitization, and response limits;
• canonical errors, audit events, status posture, and operator-visible unavailable reasons.

Provider reports are evidence. They cannot directly set canonical state, grant authorization, weaken requirements, mark approval, rewrite a binding, or create canonical audit events.

Provider-owned responsibilities

An admitted process-isolation implementation owns only its specialized mechanism:

• launch the exact executable and argv supplied by the kernel without shell joining or command reinterpretation;
• create and own the selected isolation boundary and workload target before the child can execute;
• apply every required filesystem, network, identity, privilege, resource, process-tree, syscall, and ambient-authority control;
• keep a stable provider execution locator under the exact binding;
• observe the workload and return bounded typed lifecycle/posture evidence;
• capture or stream stdout and stderr separately under kernel-provided limits;
• atomically apply ordered updateRedactionContext revisions before further output persistence;
• deliver cancellation to the boundary it owns and report cancellation/descendant certainty truthfully;
• clean up its workload, descendants, temporary state, mounts, network objects, and other target resources within bounded deadlines;
• release only the exact kernel-authorized execution or retained-evidence resource scope;
• support exact-binding reattachment only for durability levels it declares and proves;
• reject malformed, replayed, mismatched, expired, or over-budget provider requests.

A provider cannot create canonical state, persist canonical approval, infer a new binding, choose a weaker target, spawn an untracked replacement, expose secrets in diagnostics, or claim cleanup/termination it cannot prove.

Typed domain operations

I0 defines a narrow provider-kind operation family. These operations are not added as model tools and are not methods on a universal provider interface.

Operation	Effect	Contract
launch	State-changing	Accept one exact bound process launch intent at most once; create the isolation boundary before executing the child and return an opaque execution locator plus initial evidence.
observe	Read-only	Return a bounded observation for the exact binding/run/locator without changing canonical state.
readOutput	Read-only	Return one bounded stdout or stderr source range with source cursor and availability evidence.
updateRedactionContext	State-changing, ordered, and idempotent	Atomically apply one bounded kernel-issued redaction-context revision for the exact live binding before further output persistence, then acknowledge the exact revision and digest.
cancel	State-changing and idempotent	Deliver cancellation through the owning boundary and report signal, workload, descendant, and cleanup certainty.
release	State-changing and idempotent	Release only the kernel-authorized execution_boundary or independently authorized retained_evidence resource scope; unresolved cleanup and retention remain visible, and one scope never implies authorization for the other.

Launch request

The kernel-issued typed launch request contains:

• exact ProviderBindingId, process run ID, binding/release/configuration identities, and operation mode;
• executable plus ordered argv array; providers must use direct execution with shell: false or an equivalent no-shell API and must never shell-join arguments;
• validated canonical workspace identity, workspace root projection, and requested cwd;
• a minimal kernel-approved environment plus explicit resolved overlay; no ambient gateway environment inheritance is implied;
• confidential secret/redaction projection required for launch and output handling;
• typed required posture and exact workload-target configuration reference;
• execution cutoff, final absolute settlement deadline, cancellation token/reference, output limits, and resource limits;
• request hash, launch idempotency key, fencing/lease generation where durable ownership applies;
• kernel correlation, actor, policy-snapshot, approval, and audit linkage references without provider authority over them.

The provider validates the envelope, exact binding, deadline, operation mode, target configuration, request hash, and replay state before any workload effect. A duplicate launch with the same binding, process run ID, idempotency key, and request hash returns the existing execution locator/state. A mismatch is rejected. An ambiguous transport outcome is reconciled against that stable identity; it is never converted into a second launch.

For durable_background, the provider must durably establish launch acceptance, the full idempotency tuple, and the recovery locator before the child can execute. That acceptance record must survive provider activation restart and must be queryable by the exact binding/run identity. If the provider cannot order and retain those facts, durable-background capability is unavailable; a best-effort write after spawn is insufficient.

Launch result and runtime observations

Provider results use a typed evidence envelope containing only:

• provider execution locator and provider observation sequence;
• accepted/running/terminal provider observation with timestamps;
• exact target and applied-posture evidence identity;
• exit/signal information when known;
• stdout/stderr availability and source-byte counters;
• cancellation, descendant termination, and cleanup certainty;
• safe typed error/retry classification;
• integrity/authentication metadata required by the admitted deployment protocol.

The kernel validates and normalizes this evidence into current public results and canonical durable state. Provider-native state names and messages are never canonical.

Live redaction-context update

updateRedactionContext is an I0 domain operation because it controls process-output persistence; it is not a D1 lifecycle message and is never model-facing. The kernel-issued confidential request carries the exact binding, process run ID, execution locator, a monotonic RedactionContextRevision, a complete bounded replacement context, its digest, and a bounded acknowledgement deadline. Secret values are never copied into audit or diagnostic fields.

The provider applies revisions atomically and in order before persisting another output byte, then acknowledges the exact revision and digest. Replaying the same revision and digest returns the existing acknowledgement. A lower revision is stale; a skipped revision or the same revision with a different digest is a protocol violation. Failure or timeout pauses persistence, reports redaction_context_unavailable, and leaves the kernel responsible for canonical cancellation intent and cancel delivery.

Scoped release

release always carries the exact binding/run/locator, an idempotency identity, one ReleaseScope, and kernel authorization for only that scope:

• execution_boundary may run after terminal settlement or forced-settlement intent. It removes the workload target, descendants, mounts, network objects, and ephemeral execution state, but cannot remove retained output, source cursors, or recovery/settlement evidence.
• retained_evidence names the exact independently authorized evidence classes to delete. The kernel issues it only after each named retention obligation has been materialized/transferred or has expired under its own rule. It cannot recreate, signal, or otherwise affect a workload target.

The provider reports each resource-class outcome separately. Unconfirmed execution cleanup remains canonical evidence; unavailable retained evidence remains a truthful logs/recovery outcome. Repeating either scope cannot authorize or imply the other.

Operator selection and availability

I0 v1 admits one selection scope: one deployment-scoped process profile for the active gateway deployment. The kernel-owned lookup key is the tuple (DeploymentConfigurationRevision, ProviderKindId). Agent, conversation, workspace, execution-profile, provider-discovery, and model-supplied overrides are not admitted selection scopes. OperationMode selects only an explicit mapping inside the one resolved profile; it does not select another profile.

Operator configuration designates exactly one active immutable ProcessProfileRevisionId for that lookup key. Zero active revisions, multiple active revisions, duplicate identities with different content, or conflicting mappings fail closed before binding. There is no precedence among conflicting candidates. An implementation transition may deterministically materialize one compatibility revision from existing deployment-owned process configuration, but an explicit and a synthesized revision can never be active together. The persistence/schema mechanism for that transition remains deferred to S0.

The selected process-profile revision resolves before any operation binding:

• exact ProviderImplementationId, ProviderImplementationVersion, and ProviderReleaseId;
• exact ProviderConfigurationRevision and ProviderConformanceEvidenceId;
• trust and provider deployment mode for each kernel-owned operation class;
• required baseline or hardened profile and its typed posture floor;
• exact provider-specific workload-target configuration reference;
• supported operation modes and required durability;
• resource/output/runtime limits and shutdown policy.

The kernel persists one exact resolved profile revision per run before creating the immutable provider binding. Installing a new release, changing discovery order, provider health, or provider self-priority cannot change it. Adopting a different release or target requires activation of a new operator-authored revision for subsequent runs. I0 has no automatic fallback or opportunistic selection.

New process.run and process.start binding eligibility is computed separately for foreground and durable_background. It governs only new invocations. A provider may accept new foreground work while denying new durable work, and the kernel omits or denies only those new-launch capabilities according to existing process-family exposure rules.

Loss of new-binding eligibility must not hide an authorized existing handle or reselect a provider:

• process.get remains kernel-readable from canonical state regardless of provider health;
• process.logs reads kernel-retained output or uses the pinned binding and returns a truthful process_isolation_output_unavailable result when the exact source cannot be read; it never selects another provider;
• process.cancel records authorized canonical cancellation intent before delivery through the pinned binding; unavailable delivery remains visible as unconfirmed rather than suppressing the intent;
• release and recovery use only the pinned binding and recorded execution identity.

Existing-handle operations remain available for settlement and containment even when new launches are unavailable. Authorization, retention expiry, or final release may make a specific handle unreadable; provider health alone may not.

Typed isolation posture

Isolation posture is a typed vector, not a provider-supplied hardened: true claim and not an inference from target type.

Dimension	Baseline vocabulary	Hardened minimum
Filesystem boundary	ambient	declared_mounts_only; undeclared host paths and symlink escapes are blocked by the execution boundary.
Network boundary	ambient	isolated_none or isolated_egress_policy; host networking is not silently inherited.
Workload identity	gateway_identity	binding_scoped_identity; workload authority is distinct from gateway authority and cannot authenticate as, inspect credentials of, or signal another binding.
Privilege boundary	ambient	no_privilege_gain; host control sockets/devices and undeclared capabilities are absent.
Resource boundary	best_effort	enforced_limits for process count, memory, CPU/runtime, and provider-kind-required storage/output bounds.
Process-tree boundary	best_effort	boundary_owned; descendants cannot escape observation/termination or enter another binding's process-control boundary.
Syscall boundary	ambient	filtered_or_stronger; the exact admitted policy/equivalent is release-bound and conformance-proven.
Ambient authority	inherited	explicit_only; no ambient HOME, gateway environment, credential agent/socket, host control plane, or undeclared shared IPC channel is inherited.
Cross-binding authority	shared_or_unspecified	binding_isolated; one binding cannot enumerate, signal, ptrace, credential-read, or use shared-memory/message-queue/socket authority against another binding except through a separately authorized, typed, least-privilege channel.
Cleanup boundary	best_effort	bounded_and_proven; target and descendant settlement has an authoritative positive proof or remains unconfirmed.

baseline preserves current truthful behavior and makes no hardened claim. The future built-in local_spawn candidate is baseline: process groups, lexical cwd checks, minimal environment construction, and a separate background supervisor improve lifecycle behavior but do not provide the hardened dimensions above. local_spawn does not and must not report hardened.

A hardened requirement means every hardened minimum above is satisfied for the exact operation and target, including an operator-selected network mode. Missing, stale, indeterminate, or contradictory evidence fails closed with no baseline fallback. A provider cannot average dimensions, substitute process-tree signalling for containment, or call an unrestricted host/container target hardened. A non-gateway UID, container label, or PID namespace is insufficient when another binding under the same identity or IPC/process-visibility boundary can still observe or control it.

Provider deployment and managed workload target are distinct. local_service or remote_service says where provider code runs; it does not prove where or how the child workload is isolated. Conversely, an in_process adapter may control an external target only when its exact target protocol, ownership, and isolation evidence satisfy I0 and D1.

Runtime applied-posture evidence

Before the child can execute, a hardened provider must bind the workload target to:

• exact provider binding, release, configuration, conformance evidence, and authenticated peer;
• exact target identity and target policy/configuration digest;
• each applied posture dimension and the enforcement/evidence mechanism admitted by the provider-kind suite;
• kernel challenge/correlation and anti-replay identity where out of process;
• creation timestamp and evidence freshness bound;
• later cancellation, cleanup, and target-absence evidence.

The kernel verifies shape, binding, freshness, and accepted evidence class. Provider self-report alone is insufficient. Protocol-constrained trust protects the kernel boundary but does not by itself prove workload confinement; a hardened claim additionally requires accepted release conformance and independent/authority-backed evidence for the target controls.

Binding, lifecycle, and recovery

The existing independent process supervisor remains kernel-owned canonical lifecycle infrastructure. It may invoke or host an isolation-provider adapter, but a provider does not absorb the supervisor's database state transitions, workspace-lease authority, handle authorization, canonical redaction/retention policy, or audit authority.

An immutable process-isolation binding specializes D1 and persists:

• ProviderBindingId, provider kind/contract version, exact implementation/version/ProviderReleaseId;
• configuration and conformance evidence identities;
• trust mode, provider deployment mode, authenticated peer, and process-profile revision;
• operation mode, canonical process run ID, request hash, requirements, and target configuration reference;
• D1's provider-kind Recovery field as a kernel-issued ProcessExecutionRecordId;
• kernel execution cutoff, final settlement deadline, and approval/policy references.

The immutable binding does not contain a runtime target identity, provider execution locator, provider observation, output cursor, or activation attempt. Those values do not exist at selection time and cannot rewrite the selected implementation.

For I0, D1's immutable Recovery field is the stable kernel execution-record reference allocated at the write-ahead point. It is not the runtime target identity or provider execution/recovery locator. That interpretation preserves D1's requirement that recovery identity exists before any external effect without pretending that provider-generated runtime facts exist before launch.

The append-only process execution record, keyed by ProcessExecutionRecordId, ProviderBindingId, and process run ID, records runtime target identity and provider execution locator after accepted launch, then activation attempts, observations, applied-posture evidence, recovery evidence, output locators/cursors, cancellation, and cleanup. Adding runtime evidence to this record does not mutate or replace the immutable binding.

ProviderActivationId identifies one provider lifecycle attempt, not the immutable process selection. A provider process may fail or restart. Exact recovery creates a new ProviderActivationId under the same ProviderBindingId; it must use the same provider implementation release, configuration, trust/deployment posture, peer identity, process run ID, and target configuration from the binding plus the runtime target identity and recovery locator from the execution record.

Recovery does not rerun current selection and does not adopt a currently preferred provider. It must not respawn or blindly retry a state-changing process. Installing a new release, changing a process profile, or losing the exact target cannot rewrite the binding.

Canonical process states

The kernel retains the existing canonical durable states: queued, starting, running, cancel_requested, completed, failed, timed_out, output_limited, cancelled, lost, and orphaned_unconfirmed. Provider observations are normalized evidence for these transitions.

• The kernel persists the binding and launch intent before a durable launch request crosses the provider boundary.
• Durable provider acceptance is persisted before the child can execute and survives provider activation restart; it remains at-most-once for the binding/run/idempotency identity.
• An ambiguous or unknown launch reply after possible acceptance triggers exact-identity reconciliation, not another launch.
• A gateway restart may reattach only through the exact binding and stable provider execution locator.
• Provider/gateway activation restart may use a new ProviderActivationId with the same ProviderBindingId.
• A machine restart is lost or orphaned_unconfirmed unless the provider kind/release explicitly proves stronger continuity and exact reattachment.
• PID persistence or a connection ID is not recovery identity and never authorizes signalling.
• If the provider cannot prove whether a workload exists, the kernel records orphaned_unconfirmed, quarantines conflicting workspace mutation where required, and exposes operator recovery rather than guessing.

Deadline, cancellation, and cleanup

The kernel derives and binds two absolute timestamps under one timeout policy:

• the execution cutoff is the last instant at which the workload may continue ordinary execution. The existing public runtime timeout maps to this cutoff;
• the settlement deadline is the later final D1 operation deadline. It includes a bounded kernel-selected cancellation and teardown reserve and may not exceed the applicable tool, turn, shutdown, or operator-policy ceiling.

Both timestamps are fixed before provider dispatch and carried in every relevant request. The provider cannot extend either. At the execution cutoff, the kernel persists timeout/cancellation intent and the provider stops ordinary execution and begins bounded teardown. At the settlement deadline, the kernel stops waiting, records any workload, descendant, and cleanup uncertainty truthfully, and applies quarantine/operator-recovery policy where required. Further cleanup requires a new separately authorized bounded request under the exact binding; it is not an extension of the expired operation.

Provider cancellation evidence distinguishes:

• request accepted/rejected/expired;
• cancel certainty: not sent, signalled, acknowledged, or confirmed terminal;
• root workload outcome;
• descendant termination: confirmed, unconfirmed/escaped, or unsupported;
• cleanup/target absence: confirmed, unconfirmed, or failed.

A terminal child exit does not prove descendant termination or target cleanup. Repeated cancel and release calls are idempotent. timed_out records execution-cutoff outcome and never by itself proves final settlement. Unconfirmed cancellation or cleanup remains canonical evidence and may block workspace mutation or stronger status claims.

Output, secrets, and evidence

Stdout and stderr remain separate untrusted byte streams. readOutput is cursor-based and returns a bounded source-byte range, a provider-owned next source cursor, EOF/availability, and integrity evidence. Source cursor advancement uses source bytes, not UTF-8, redacted, JSON-escaped, or model-rendered length.

The kernel owns output budgets and final model representation. A provider enforces no more than the admitted per-stream/total limits and cannot turn output truncation into success evidence. Invalid UTF-8 is normalized at the existing kernel boundary without merging streams.

Secret values must not appear in descriptors, bindings, audit events, status, provider-native errors, invocation display, or provider logs. The kernel resolves only named secret references after binding and projects the minimum launch values over the admitted confidential boundary.

If a provider persists or spools output, it must apply the kernel-owned, versioned streaming redaction contract before persistence, including chunk-boundary carry. The kernel revalidates/re-redacts data crossing the provider trust boundary before model use. Raw secret-bearing output is never durable provider evidence.

Durable output capture performs a live redaction-context update through updateRedactionContext when additional resolved secrets become relevant to a live run. The request carries a monotonic redaction-context revision and digest; the provider must atomically apply and acknowledge both before further persistence. If it cannot, it pauses capture, reports redaction_context_unavailable, and the kernel records cancellation intent and invokes cancel. The provider does not continue writing possibly unredacted output or decide canonical cancellation policy.

release(scope=execution_boundary) removes only live target resources after settlement and preserves all retained evidence. release(scope=retained_evidence) cannot remove retained output until its output-retention obligation is satisfied or expired, and can delete only the evidence classes named by kernel authorization. Retained output, source-cursor metadata, and recovery-evidence obligations are evaluated independently; each must be materialized/transferred or satisfied through its own expiry rule. Expiry of one obligation never authorizes deletion required by another. If the provider remains an admitted retention store, terminal target cleanup and later evidence-retention release are separate idempotent steps.

Provider evidence is bounded, typed, authenticated where out of process, and linked to the exact binding/run/correlation. Provider logs remain diagnostics, not canonical audit. The kernel emits canonical process and provider events after validation and redaction.

Health and capability semantics

Static descriptor capabilities declare:

• supported operation modes (foreground, durable_background);
• provider deployment modes and authenticated protocol versions;
• workload target classes supported without implying posture;
• typed isolation dimensions and exact values the release can enforce;
• durability level (foreground_only, gateway_restart, or separately proven stronger continuity);
• output cursor/capture, redaction-update, cancellation, cleanup, and reattachment features;
• hard maxima for runtime, output, resources, and concurrent bindings where applicable.

Runtime capability evidence proves the selected target can apply the required values now. A configured implementation can therefore be registered and compatible but unavailable for hardened work, durable work, or a specific target.

Health never rewrites an active binding. If health or capability drops after launch, the kernel follows the exact binding's cancellation/settlement contract. It does not move the workload or fall back to a different implementation.

Error specialization

I0 specializes D1 errors with safe kind-specific reasons:

Code	Meaning
required_process_confinement_unavailable	Existing public fail-closed error when the selected profile cannot satisfy the required posture.
process_isolation_target_unavailable	Exact configured workload target is absent or not admitted.
process_isolation_launch_rejected	Provider rejected the exact launch before acceptance.
process_isolation_launch_ambiguous	Launch may have been accepted but exact reconciliation is not yet conclusive.
process_isolation_binding_unavailable	Exact release/configuration/peer/target/recovery identity cannot be restored.
process_isolation_cancel_unconfirmed	Cancellation intent exists but terminal workload/descendant proof is incomplete.
process_isolation_cleanup_unconfirmed	Provider cannot prove target/resource cleanup.
process_isolation_output_unavailable	Bound output cannot be read or safely redacted.
process_isolation_protocol_violation	Provider violated the admitted typed protocol or evidence contract.

Provider-native diagnostics are redacted and bounded. They do not change retryability, authorize fallback, or become model-visible without kernel normalization.

I0 conformance contract

I0 adds one provider-kind suite to D1 common conformance. The same suite and activation gate apply to built-in and external implementations; delivery-specific fixtures may differ but outcomes may not.

Every conformance record is bound to the exact ProviderReleaseId, provider contract version, implementation/configuration schema, admitted provider deployment mode/protocol, TargetEquivalenceClassId, target-equivalence predicate digest, and suite version. A workload target class label alone is insufficient. Provider self-report is insufficient and cannot mint the authoritative evidence record.

Common process-isolation cases

• exact direct argv/executable behavior with no shell reinterpretation;
• cwd/workspace projection, path traversal, symlink, mount, and undeclared-path rejection;
• minimal environment and explicit secret projection without ambient leakage;
• launch at-most-once behavior, duplicate replay, mismatched replay, ambiguous acceptance, durable acceptance-before-execution, and activation-restart recovery of the acceptance record;
• execution cutoff, final settlement deadline, timeout/cancel/exit races, repeated cancel, descendant truth, cleanup, and forced settlement;
• separate bounded streams, source cursor correctness, UTF-8 boundaries, output limits, split-secret redaction, ordered updateRedactionContext, and independently scoped execution/evidence release;
• foreground and durable-background operation capability and truthful unavailability;
• gateway/provider activation restart, supervisor death while the gateway remains live, exact reattachment, stale-owner fencing, and no blind respawn;
• exact binding/release/target recovery and fail-closed behavior when any pinned identity is unavailable;
• provider protocol authentication, replay rejection, message/resource bounds, cancellation, and correlation for every out-of-process mode.

Target-equivalent evidence

Target equivalence is a release-bound predicate over the exact service identity, launch and authenticated protocol path, isolation mechanism and version, OS/kernel/runtime class and security features, target policy/configuration digest, workload identity and PID/IPC arrangement, mount projection, network policy, resource controller, syscall policy, and cleanup mechanism. The conformance authority records the admitted values/ranges and their digest as one TargetEquivalenceClassId.

Runtime applied-posture evidence binds the exact target policy/configuration digest and relevant mechanism identities to that predicate. The kernel accepts the release evidence only when every material runtime value is equal to or explicitly admitted by the predicate. Every difference from the conformance fixture must be enumerated; an unknown or material unproven difference fails closed. Sharing a broad target label, container image, provider release, or host family does not establish equivalence.

Baseline candidate evidence

The future local_spawn adapter must pass the same contract suite for every capability it declares. Its baseline cases prove current direct argv, output, deadline, process-group/supervisor, and durable-state behavior while explicitly proving hardened selection is unavailable. It receives no waiver because it is built in.

Hardened provider evidence

A hardened implementation must run target-equivalent integration and adversarial tests under the real service identity and execution boundary. Hardened negative probes must demonstrate rejection or containment for at least:

• undeclared filesystem paths and workspace symlink escapes;
• ambient HOME/environment/credential sockets and gateway identity authority;
• cross-binding process visibility, signalling, ptrace, credential access, shared-memory, message-queue, socket, and other IPC authority;
• host networking when isolated_none is required, and disallowed egress under an explicit policy;
• privilege gain, undeclared devices/control sockets, and forbidden syscall/capability behavior;
• process-count, memory, CPU/runtime, output, and target-storage limits;
• detached/daemonized descendants, timeout escalation, cancellation, and authoritative target absence;
• provider/supervisor/gateway interruption, stale recovery, ambiguous launch, and cleanup failure;
• secret split across output chunks and redaction context changes after launch.

A mock, descriptor claim, target label, process-group test, container inspection alone, or a provider-authored hardened boolean is not sufficient evidence. The release-bound suite must prove every claimed posture dimension and the exact fail-closed downgrade behavior.

Adoption and rollback constraints

I0 introduces no runtime rollout. Later implementation work must follow ARCH-29's graph:

• I1 can represent local_spawn only after S0/B0/T0 exist and may claim baseline only;
• I2 adds one hardened implementation after I1 and must remain exact opt-in until target-equivalent evidence is accepted;
• I3 routes process.run through the binding without changing its public contract;
• I4 keeps the existing supervisor's canonical state, lease, authorization, retention, and audit role kernel-owned and routes only its launch/observe/output/redaction/cancel/release mechanism through the same immutable provider binding and recovery rules;
• G0 accepts the first process slice only after the complete route is proven.

Existing baseline behavior remains the default until a separately reviewed implementation and rollout changes it. A profile requiring hardened confinement remains unavailable during rollback if the selected implementation is absent; rollback never silently enables baseline.

No new provider persistence or configuration schema is selected by I0. Exact storage and common substrate wait for I0, M0, and C0 to expose their genuinely shared requirements.

I0 acceptance boundary

I0 was accepted after confirming:

• the exclusive operator selection and model-exclusion boundary is unambiguous;
• existing public process request/result contracts and kernel governance remain intact;
• domain operations are sufficient for foreground and current durable-background behavior without becoming a universal provider interface;
• baseline and hardened postures are typed, testable, and truthful;
• launch idempotency, ambiguous acceptance, immutable binding, activation replacement, exact recovery, cancellation, and cleanup semantics are internally consistent;
• output, redaction, secret projection, cursor, and durable evidence rules preserve existing safety boundaries;
• local_spawn can be represented truthfully without a built-in bypass;
• one future hardened provider has a target-equivalent, release-bound conformance contract;
• no node management, generic dispatch, registry service, marketplace, new persistence family, or implementation has entered scope.

Acceptance authorizes contract design only. I0 does not authorize I1, I2, provider code, configuration/schema changes, migrations, rollout, or publication. M0 and C0 still require their own accepted typed contracts, and S0 remains blocked until I0, M0, and C0 reveal the common substrate they actually share.

Related docs

• ARCH-29 policy-owning provider microkernel
• D1 kernel invariants and provider control-plane contract
• ARCH-23 native runtime and governed CLI tools
• ARCH-24 governed process capability
• ARCH-25 process-family governance and truthful posture
• ARCH-26 durable background process lifecycle
• Sandbox and policy
• Gateway plugins