Deployment Model and Physical Boundaries

Purpose of This Section

This document describes the deployment choices and physical constraints that ground the assistant in reality. These choices are intentionally conservative, prioritizing containment, predictability, and graceful failure over availability, scale, or convenience. The central premise is that where a system runs, and what it is physically tied to, matters as much as what it can do.

The Virtual Machine as Primary Boundary

The assistant is deployed inside a dedicated virtual machine running a stable, long-term-support operating system. The VM serves as the assistant’s sole execution surface — the only place where its processes run and its state resides.

This boundary provides several properties simultaneously. It isolates the assistant from the host environment, so that a compromise of the assistant does not automatically compromise the operator’s machine. It provides a clean, inspectable surface that can be audited or rebuilt without ambiguity about what belongs to the assistant and what does not. It enables snapshotting and rollback as recovery tools. And it simplifies incident containment: if something goes wrong, the scope of the problem is the VM, not the broader infrastructure.

Equally important is what the VM boundary prevents. Because the assistant does not share an operating environment with the operator, it cannot accidentally inherit elevated privileges, access credentials stored in the host’s keychain, or interact with devices and services that were never intended for its use.

On-Premises Deployment

The VM is hosted on physical hardware located on the operator’s premises rather than on a public VPS or cloud provider. This choice is grounded in risk management rather than ideology.

An on-premises deployment exposes no public endpoints by default. Physical access constraints serve as an additional security layer — one that requires no configuration and cannot be bypassed remotely. Failure modes are obvious and bounded: if the power goes out or the hardware fails, the assistant stops. There is no third-party control plane that might intervene, persist state, or introduce changes outside the operator’s awareness.

The tradeoff is availability for sovereignty. The assistant may be unreachable during hardware failures, power outages, or network disruptions that a cloud deployment would survive. For a personal assistant operating under bounded authority, that tradeoff is acceptable and, in many respects, desirable. An assistant that is unreachable is an assistant that cannot act — and in a system designed around controlled delegation, that is the safer failure mode.

Rejection of High Availability

High availability is a common and often unquestioned design goal in distributed systems. It is not a goal here. If the assistant becomes unavailable, work pauses. No automatic failover occurs. No secondary instance assumes control.

This is not a limitation we intend to address later. It is a deliberate design choice rooted in the observation that availability amplifies risk whenever authority exists. A system that is always reachable is a system that is always capable of acting on its delegated authority. For personal infrastructure where the operator is the sole source of oversight, uninterrupted availability without uninterrupted supervision is a liability, not an asset.

Physical Dependency as a Safety Feature

The assistant’s continued operation is coupled to physical and economic realities. The machine must be powered. The operator must maintain the hardware. Utilities and subscriptions must be paid. If any of these conditions ceases to hold, the assistant ceases to operate.

We treat this coupling as a designed end-of-life mechanism rather than a fragility to be engineered away. By tying operation to physical presence and ongoing human intent, the system avoids three failure modes that plague longer-lived automated systems: orphaned authority, where delegated permissions outlive the context in which they were granted; zombie automation, where processes continue executing after their purpose has lapsed; and unintended persistence, where a system survives beyond the operator’s interest or ability to oversee it.

Absence of Remote Persistence

No attempt is made to ensure the assistant continues operating indefinitely or autonomously. There are no background replicas, cloud fallbacks, or long-lived service accounts designed to survive the operator’s disappearance. If the system stops, it stops cleanly. This property is a direct consequence of the coworker model: a coworker whose principal has left the organization does not continue executing on their behalf.

Snapshotting and Rebuildability

The VM deployment enables periodic snapshots, offline backups of configuration and documentation, and cold restores that require re-authentication. Snapshots are treated as recovery tools, not operational crutches. Restoring a snapshot does not restore authority or active sessions — credentials must be re-established, and delegation must be re-granted. This ensures that recovery is a conscious act, not an invisible rewind that might reintroduce a compromised state.

Threat Model Implications

This deployment model directly mitigates several classes of risk: silent remote compromise (because there are no exposed endpoints), unbounded lateral movement (because the VM isolates the assistant from the host), undetected persistence (because operation depends on physical infrastructure), and orphaned identities (because the assistant’s lifecycle is tied to the operator’s ongoing intent).

It does not attempt to defend against physical access by a determined adversary. That risk is accepted and documented. For a personal deployment in a private residence, the physical access threat model is bounded by the same assumptions that govern the rest of the operator’s infrastructure.

Non-Goals

Continuous uptime, multi-operator access, geographic redundancy, and automated disaster recovery are all explicitly out of scope. These are standard requirements in enterprise and multi-tenant systems, but they introduce complexity, indirection, and implicit authority that conflict with the goals of this architecture. A personal assistant needs to work reliably for one person, not survive arbitrary failure scenarios for many.

Summary

By anchoring the assistant to a single, inspectable virtual machine on physical hardware, the system gains clear execution boundaries, predictable failure modes, natural lifecycle termination, and a reduced attack surface. The deployment model enforces a principle that runs through the rest of this paper: capability must always be grounded in context, and context includes the physical and economic realities that sustain the system.

---

This document translates philosophical constraints into physical and infrastructural boundaries. Subsequent sections build on this foundation to define how the assistant interacts with networks, identities, and external systems.