A home outlives a process
A named home is the durable directory for one product instance. It contains the source checkout, managed Git repository, config, control state, keys, and application data. Provisioning prepares those files so you can inspect and author before running anything.
A process is the live execution of that home. Each started Rune runs in the foreground as its own operating-system process. The runtime lock and process instance distinguish a current process from files left by an earlier one. That is why init does not start, and status cannot use a PID file as truth.
A supervisor can own the foreground command, but generated service text does not install, enable, or start it. The operator still chooses the account, supervision, logs, and restart policy. A system-wide process policy is not implied by the existence of a home.
A checkout is editable; a deployment is immutable
The checkout is where you change Scheme, tests, identity, and documentation. Repo-mode validation and command execution use that working tree. They are useful before deployment because they do not require a foreground named process.
Git main is the only managed deployment boundary. A push validates a candidate and attempts activation before promoting it. A failed candidate leaves the previous active bundle and visible main in place. Editing the source checkout alone cannot change the active specialization.
A named exe invocation reads a private materialization of the active immutable bundle, while a repo-mode invocation reads the selected checkout. Both keep the caller's current directory, but their repo roots and data directories differ. That difference explains why a command can work locally and still run older behavior by name.
Application data is separate from control state
Rune's control database records managed runtime and deployment information. Application SQLite is an independent API with validated logical database names. The app cannot select an arbitrary path through that API, so it cannot accidentally open Rune's control database as its own state.
Memory data lasts for a process. Disk data persists under the private home for named execution or under the checkout's .rune directory for repo execution. A new exe process has new memory state. Disk persistence does not automatically provide backup, replication, or a retention policy.
Invocation-scoped transactions prevent an unfinished operation from retaining a transaction after the handler ends. Typed JSON cells distinguish integers, reals, text, null, and blobs. The returned result still needs validation by the caller. Durable storage does not turn a failed write into success.
Names organize trusted workloads
Each Rune has its own home, keys, repository, database, lock, and endpoints. Those separate directories help the operator manage independent products. They do not form hostile-tenant isolation when all processes share one Unix account.
For a hostile workload boundary, use separate accounts, containers, VMs, or hosts with an appropriate operator policy. Declared capabilities and opaque credential handles reduce accidental authority. They do not justify treating arbitrary repositories as safe.
Local HTTP binding reduces accidental exposure, but public access still needs an explicit authentication, TLS, proxy, and access-control design. No onboarding example configures those protections for you.
The runtime has a bounded product scope
Rune provides Scheme execution, commands, Git deployment, optional HTTP service behavior, and SQLite. It does not provide production LLM inference, chat hosting, or A2A hosting. Fleet, P2P Phase 2, and new Lisp authoring features are not shipped capabilities in these guides.
Flint adds Scheme CI policy on top of Rune. That policy still needs a supported Linux execution environment for native jobs. macOS control-plane checks do not establish Linux execution or release acceptance.
Preview documentation describes a contract that can be compared with an installed build. It is not a release announcement. The compatibility check and the Flint version boundary explain why version strings alone are insufficient.