• conforms_to::[[Conviction Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Code Load Compiles Into the Live Runtime, Bounded by Capability Tiers

The eOS runtime platform accepts new code into the running runtime as a runtime operation; what the loaded code is allowed to do is bounded by the capability layer at the moment of load. An agent or developer adding a new capability does not redeploy the runtime, and does not reach for an external sandbox container -- the platform compiles the new code in place, and the runtime enforces the loaded code's permissions just as it enforces every existing object's permissions.

Why It Is Held

Code-load patterns built outside the runtime fragment. Each team picks a sandbox technology (containers, processes, virtualization, language-level isolators), each implementation has bugs the team rebuilds, and each requires its own coordination layer to plumb identity and permissions across the sandbox boundary. The application code that orchestrates "compile this, sandbox it, give it credentials, route requests to it" is not the application's actual logic -- it is bookkeeping the platform could provide. Treating sandboxed code load as a runtime primitive removes the orchestration entirely: the runtime compiles the code, the capability layer bounds what it can do, and the loaded code lives alongside existing objects under the same enforcement.

The platform-as-loader stance composes with the capability-separation primitive ([[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]). The capability layer that enforces existing objects' permissions also enforces loaded code's permissions; what tier the loaded code runs in is set at load time and bounds every operation thereafter. Without runtime-level capability separation, sandboxing newly-loaded code would require a separate enforcement mechanism -- exactly the per-team-rebuilt sandbox pattern the platform replaces. With runtime-level capability separation, code load is just one more event the existing capability machinery scopes.

The platform-as-loader stance also composes with the hot-reload primitive ([[Hot Reload Is a Runtime Operation, Not a Deployment Event]]). Both rest on the same runtime compile-and-load mechanism, but they make different claims: hot reload is about UPDATING existing code without restart; sandboxed code load is about ADDING NEW code bounded by capability. The two Convictions overlap mechanically while remaining distinct in stance -- a platform that supports hot reload but not sandboxed code load would be a platform where new code can only enter through a redeploy, and a platform that supports sandboxed code load but not hot reload would be one where new code lands but existing code never changes. Both stances together are what makes the platform's code-handling story coherent.

The eOS-kernellib foundation provides this primitive directly at the runtime layer: the runtime's compile-and-load mechanism compiles a source file and registers it as a program, and an inheritance filter checks whether the inheriting object has read access to the inherited program. The kernel layer's access daemon mediates that read-access check via the file-permission system, and its object-load interception point lets the foundation hook compile and load events for tracking, logging, or additional policy.

The Conviction is held because the no-external-sandbox experience is what platform adoption purchases for the agent-skill-extension story. When agents (or developers) can add new capabilities by compiling source into the running runtime under a chosen capability tier, the development cycle for new agent skills compresses to write-and-compile rather than build-deploy-orchestrate. Trading the primitive for an external sandbox would surrender exactly the property that makes the platform well-suited to LLM-driven dynamic-capability scenarios.

What It Asks

Honoring this Conviction asks the project to keep code load inside the runtime under the capability layer, not to delegate it to external sandbox technology.

• Demonstrations and tests load code through the runtime's own compile-and-load path, not through container orchestration. Capabilities are introduced by compiling source through the same mechanism, scoped to whatever capability tier the loading principal is in.
• Loaded code's capability tier is set at load time and bounds every operation it performs. A code-load event that does not specify the loaded code's capability tier (or that defaults to a privileged tier without explicit narrowing) is operating outside the spirit of the Conviction. The load operation explicitly scopes the loaded code's permissions; trusting "the developer will set the tier correctly" recreates the per-team-rebuilt-bookkeeping pattern the primitive removed.
• Decisions introducing external sandbox layers must surface the cost. A Decision adding "for additional isolation, run loaded code in a separate container" or "for compliance, route loaded code through an external policy engine" reintroduces the orchestration the primitive removed. Such Decisions weigh the orchestration cost against the platform-fit cost imposed on this Conviction. Don't trade the in-runtime capability bounding for the apparent safety of an external sandbox without surfacing the trade.
• Communication distinguishes runtime-bounded code load from pre-deploy-review patterns. When the project's sandboxed-code-load claim is communicated externally, the distinction between runtime-enforced capability bounds at load time (runtime primitive) and pre-deploy code-review-then-deploy patterns (build-pipeline pattern) is the load-bearing detail. The two are sometimes conflated in agent-infrastructure copy that uses "sandboxed" loosely.
• Workstream scoping checks the load mechanism for new capabilities. Workstreams adding new agent capabilities default to in-runtime load via the capability layer. A workstream that needs an external sandbox for its capability (e.g., for native-code extensions, GPU access, or tools that require their own runtime) must surface the boundary explicitly -- the platform's capability bounds do not extend across that boundary, and external sandboxing brings its own coordination cost.

Drift Recognition

The Conviction has weakened when the project's outputs treat new-code-load as something an external orchestrator handles rather than as a runtime operation under the capability layer.

• Container-based isolation introduced for new agent capabilities. When the operational pattern for adding a new agent skill is "build a container, deploy it, route requests to it" rather than "compile the source under the appropriate capability tier", the platform's primitive has been demoted from "the runtime loads code" to "the runtime hosts pre-loaded code." The container layer is the drift evidence; in a held-Conviction world, the container is not in the picture for in-runtime capabilities.
• External policy engines added to authorize loaded code. A Decision routing loaded-code authorization through an external policy engine (OPA, Cedar, or similar) inverts the Conviction's stance. Once external policy is the authoritative source, the runtime's capability tier becomes one input to a separate decision rather than the decision itself. The drift is gradual: each new external check moves enforcement further from the platform.
• Loaded code defaulting to a privileged tier without explicit narrowing. When code-load operations habitually run at a privileged tier and rely on the loading developer to remember to narrow afterward, the capability-bounding aspect of the primitive has weakened. The Conviction asks for the load operation to explicitly scope; defaulting to privileged is drift.
• "Pre-deploy review is what bounds what loaded code can do" framings. The Conviction's stance is that the capability layer bounds loaded code at load time and at every operation thereafter -- not that pre-deploy review is the bounding mechanism. Documentation that frames pre-deploy review as the safety story has weakened the Conviction; the platform is supposed to make pre-deploy review redundant for capability bounding.
• Cumulative drift across multiple sessions. If several consecutive rounds of work add capabilities via container orchestration, external sandboxing, or pre-deploy-review-only mechanisms without surfacing the platform-fit cost, the project has drifted from holding the Conviction even though no individual change broke it.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape.

• grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]

  • The sandboxed-code-load primitive is one instance of the broader stance that what is normally a pattern (build-deploy-orchestrate, external sandbox containers, pre-deploy review) becomes a primitive in the runtime that every line of agent code can rely on; external sandbox patterns cannot deliver platform-level code load under the runtime's own capability layer. Currently a ghost link; the diagnostic Conviction has not yet migrated.

• grounded_in::[[Runtime State Is Persistent by Default, Not by Application Discipline]]

  • Sandboxed code load matters because the loaded code and any objects it creates are persistent artifacts, not ephemeral process state -- a capability an agent compiles into the runtime today is still there tomorrow, under the same enforcement, without a redeploy step to re-establish it.

• composes_with::[[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]

  • Sandboxed code load and capability separation reinforce each other: the capability layer that enforces existing objects' permissions also enforces loaded code's permissions; what tier the loaded code runs in is set at load time and bounds every operation thereafter. Without runtime-level capability separation, sandboxing newly-loaded code would require a separate enforcement mechanism (containers, policy engines, external sandboxes); with it, code load is just one more event the existing capability machinery scopes.

• composes_with::[[Hot Reload Is a Runtime Operation, Not a Deployment Event]]

  • Sandboxed code load and hot reload share the same runtime compile-and-load mechanism but make different claims: hot reload is about updating existing code without restart; sandboxed code load is about adding new code bounded by capability. A platform supporting one but not the other would be incoherent for the agent-skill-extension story. Both stances together make the platform's code-handling story complete.