Hot Reload Is a Runtime Operation, Not a Deployment Event

The runtime platform absorbs code updates as runtime operations rather than as deployment events. Logic updates land into the running runtime, in-flight operations finish with the old logic, and the next operation uses the new. There is no restart, no warm-up, and no state loss; recompilation is something the runtime does, not something a deployment pipeline coordinates from outside.

Why it is held

Hot reload built as a deployment pattern fragments. Each team picks a blue-green or canary or rolling-restart routine; each routine has to drain in-flight operations, warm new instances, and coordinate state migration; each implementation has bugs the team rebuilds when discovered. The application code that handles "drain me, warm me, migrate me" is not the application's actual logic -- it is bookkeeping the platform could provide. Treating hot reload as a runtime primitive removes the coordination layer entirely: the runtime swaps the code, in-flight operations complete with the version they started with, and the next operation uses the new version without an external orchestrator.

The platform-as-recompiler stance composes with the persistent-state primitive ([[Runtime State Is Persistent by Default, Not by Application Discipline]]). Recompilation does not destroy the state graph; objects keep their state and their identity across the code change. Without runtime-level persistence, hot reload would have to coordinate state migration as part of the code change -- exactly the deploy-pipeline pattern the platform replaces. With runtime-level persistence, recompilation operates on living objects whose state is unaffected by the logic update.

The platform-as-recompiler stance also composes with atomicity ([[Agent Operations Commit Wholly or Roll Back Wholly]]). In-flight operations finish with the old logic because the atomic envelope holds the code version constant for the duration of the operation; the next operation starts with the new logic because the platform has committed the recompilation between operations. Without atomicity, an in-flight operation might find itself partway through with old logic and partway through with new -- exactly the kind of partial-state failure the atomic primitive forbids. The two primitives reinforce each other at the boundary of the recompilation event.

The reference runtime provides this primitive directly: a runtime compile call recompiles a source file into the runtime; the driver's compile callback logs the event and updates the program registry; objects retain their state across the recompilation. The foundation layer's operator tooling exposes a compile command as the operator surface, making hot reload a wizard-tier operation rather than an external deploy step. The Cloud Server Reference's eight-primitives table marks hot reload as "Provided" with no gaps and notes that the hot-reload demo flows directly -- the MVA's hot-reload phase produces empirical evidence for this Conviction.

The Conviction is held because the no-deploy-coordination experience is what platform adoption purchases for development velocity. When recompile-while-running is the runtime's promise, the development cycle compresses dramatically: edit code, issue the compile command, observe new behavior; no container rebuild, no rolling restart, no in-flight-request drain. Trading the primitive for a deploy pipeline would surrender the development-velocity property that justifies much of the platform's other costs.

What it asks

Honoring this Conviction asks the project to keep recompilation inside the runtime, not to orchestrate it from outside.

The hot-reload demo is empirical evidence for this Conviction, not just a build-out task. The demonstration must include both halves: (a) recompile while the runtime is running, and (b) observe in-flight operations finish with old logic while the next operation uses the new. A demo that only shows recompile-and-call (without the in-flight half) is incomplete -- the load-bearing claim is the in-flight transition, not the recompile event itself.
Downstream workstreams build on the runtime's recompilation mechanism, not on a deployment pipeline. When agent-identity, sample-agent, or future workstreams add code that updates over time, they update via the platform's recompilation mechanism, not via container rebuilds or deployment events. A workstream that introduces a "we'll redeploy when this changes" pattern is operating outside the platform's hot-reload primitive and must surface the cost.
Decisions introducing deploy-pipeline coordination must surface the cost. A Decision adding "before deploying agent updates, drain in-flight requests via load-balancer signal" or "warm a new instance, then route traffic" is reintroducing the deployment-event pattern the primitive removed. Such Decisions weigh the orchestration cost against the platform-fit cost imposed on this Conviction.
Communication distinguishes runtime hot reload from deployment-pipeline patterns. When the project's hot-reload claim is communicated externally, the distinction between runtime recompilation (runtime primitive) and rolling-deploy patterns (orchestrator-coordinated) is the load-bearing detail. The two are sometimes conflated in agent-infrastructure copy that uses "hot deploy" loosely.
Workstream scoping checks whether code-update is the platform's or the orchestrator's. Workstreams proposing capabilities whose update cadence is the deploy pipeline (binary distribution, container image rebuild, cross-host coordination) need to acknowledge they are operating outside the platform's hot-reload guarantee for those changes. The platform is not for every form of code update; the boundary needs to be visible.

Drift recognition

The Conviction has weakened when the project's outputs treat recompilation as a deployment concern rather than as a runtime operation.

Code update routines that include "drain", "warm-up", or "rolling restart" steps. The platform's hot-reload primitive does not drain in-flight operations; in-flight operations finish atomically with old logic. When operational documentation or runbooks include drain steps before code updates, the deploy-pipeline pattern is reasserting itself, and the platform's primitive is being worked around.
Container rebuilds for in-place agent code changes. A Decision rebuilding the runtime container to update agent reasoning code inverts the Conviction's stance. The runtime is supposed to absorb the change in place; rebuilding the container means the runtime is being treated as immutable infrastructure with the code change happening outside it.
In-flight request drain coordinated by an external load balancer before code update. When the operational pattern requires external coordination (load balancer drain, ingress shutoff, traffic migration) for what should be a runtime-level recompile, the platform has been demoted from "absorbs code updates" to "is one component the deploy pipeline updates." The demotion is gradual but visible in the operational tooling that accumulates around it.
"In-flight operations may experience inconsistency during code update" framings. The Conviction's stance is that in-flight operations finish with the version they started with -- atomically, without inconsistency. Documentation that warns about inconsistency during code updates either describes a platform that has weakened or describes a code update mechanism that bypasses the platform's primitive.
Cumulative drift across multiple sessions. If two or three consecutive sessions land features whose code-update story is "redeploy when this changes" without the workstream surfacing the platform-fit cost, the project has drifted from holding the Conviction. The drift compounds: each redeployable feature lowers the perceived value of the platform's recompile primitive for the next feature.

Sources

The project's agent-runtime value-proposition draft, Section 3 ("What runtime-level primitives look like"), Draft v2 dated 2026-04-25. Carries the hot-reload primitive's articulation: "Update an agent's reasoning code while the agent is running. In-flight operations finish with the old logic; the next operation uses the new. No restart, no state loss, no warm-up." This Conviction's stance opening paraphrases the upstream paragraph; the no-restart / no-state-loss / no-warm-up triple and the in-flight-old / next-new transition are preserved verbatim because they are the load-bearing distinctions. Cited by path; not authored as a Reference node per the URL-resolvability principle in the Reference Form Contract.
The Cloud Server Reference's Mapping section. The eight-primitives table identifies the runtime's compile call as the runtime mechanism, the foundation's operator compile command and the driver compile callback as the foundation-layer mediation, "Provided" status with the note that the hot-reload demo flows directly -- the MVA's hot-reload phase produces the empirical evidence this Conviction's What It Asks section calls for. The Reference is the graph's authoritative anchor for what the foundation provides for this primitive.

Relations

conforms_to::[[Conviction Form Contract]]
- Conviction-form node in the eOS-DeepContext graph. Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape and the prohibitions on has_commitment::, decided_on::, and has_epistemic_status:: in the identity block. The filename uses the held-stance comma form ("X is Y, Not Z").
in_practice_domain::[[eOS Continuum]]
- The hot-reload primitive is one of eight runtime primitives the eOS-Harness MVA is responsible for grounding in the graph.
informed_by::[[Cloud Server (Croes, 2012, rev. 2026)]]
- The Reference's eight-primitives table provides the graph's authoritative framing for what the foundation layer provides for hot reload: the runtime's compile call as the runtime mechanism, the foundation's operator compile command and the driver compile callback as the mediation, "Provided" status with note that the hot-reload demo flows directly. The Reference grounds the implementation-level claims this Conviction's What It Asks section makes about MVA hot-reload demonstration and downstream workstream patterns.
informed_by::[[Recompiling an LPC File Over HTTP Updates the Next HTTP Response Without DGD Restart]]
- The Empirical Observation produced by the MVA workstream. Demonstrates the recompile-while-running and next-operation-uses-new halves of this Conviction's stance via a captured three-request smoke against a live MVA demonstration instance. The in-flight-finishes-with-old half is named there as the explicit limit of the current evidence -- it would require a concurrent-request probe (deferred-response in flight while a compile call lands) to demonstrate directly. The Observation's "What Would Revise It" section enumerates the concurrent probe and a stateful-master extension as the two extensions that would deepen the evidence base; both are out of MVA scope.
informs_downstream::[[eOS-Harness Minimum Viable Architecture]]
- The MVA's hello-world instance phase produced the Empirical Observation above as the empirical evidence for this Conviction's stance. Future workstreams (sample agents, agent identity) inherit the Conviction's asks as the default code-update mechanism.
composes_with::[[Runtime State Is Persistent by Default, Not by Application Discipline]]
- Hot reload and persistence reinforce each other: recompilation operates on living objects whose state is unaffected by the logic update; persistence means the state graph survives the code change without migration. Without runtime-level persistence, hot reload would have to coordinate state migration as part of the code change -- the deploy-pipeline pattern. The two primitives presuppose each other at the recompilation boundary.
composes_with::[[Agent Operations Commit Wholly or Roll Back Wholly]]
- Hot reload and atomicity reinforce each other at the recompilation boundary: in-flight operations finish with old logic because the atomic envelope holds the code version constant for the operation's duration; the next operation starts with new logic because the platform has committed the recompilation between operations. Without atomicity, an in-flight operation might mix old and new logic mid-step -- exactly the partial-state failure the atomic primitive forbids.
grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]
- The meta-Conviction this primitive is one instance of: what is normally a pattern (deploy-pipeline orchestration, drain-and-warm, rolling restart) becomes a primitive in the runtime that every line of agent code can rely on; external deploy-pipeline patterns cannot deliver platform-level logic update without state loss.
grounded_in::[[Runtime State Is Persistent by Default, Not by Application Discipline]]
- Hot reload matters because the running state survives the reload: the objects a recompilation touches keep their identity and their persistent state across the code change. Without orthogonal persistence, a code update would necessarily be a deployment event, because there would be no durable object state for the new code to resume operating on in place.