Update and Change Control

Purpose of This Section

This document defines how the assistant evolves over time without compromising security, auditability, or human oversight. Updates are treated as governed events, not background maintenance. The objective is to enable improvement while preventing silent drift, privilege escalation, or accidental regression.

Change as a Risk Surface

In traditional systems, updates are generally assumed to be beneficial. Patches fix bugs, new versions add features, and staying current is treated as good hygiene. In an AI-driven system with broad capabilities and delegated authority, this assumption is unsafe. Every change introduces risk: behavioral drift that alters how the assistant responds to familiar situations, expanded authority if new features request broader permissions, new dependencies that widen the supply chain, and security regressions that reopen previously closed attack surfaces.

The architecture treats change itself as the threat surface. An update is not inherently better than the state it replaces — it is different, and that difference must be evaluated on its own terms before it is accepted.

Monitoring Without Autonomy

The assistant is permitted to monitor for updates to its own software and dependencies. It can check repositories, compare version numbers, and identify when newer releases are available. What it cannot do is apply any update autonomously. When an update is detected, the assistant must explicitly request authorization from the operator, declaring the update source and the scope of the proposed change. The operator then decides whether to proceed.

This division preserves proactivity — the assistant surfaces relevant information — without surrendering control. The assistant can say “a new version is available, here is what it changes, and here is where it comes from.” It cannot say “I have updated myself.”

Scheduled Update Requests

A scheduled job periodically prompts the operator with update information: whether an update is available, the exact repository or source it originates from, the scope of the proposed change, and any known risks or behavioral differences. No update proceeds without an explicit human response. Silence is treated as denial. If the operator does not respond to an update request, the system continues running its current version indefinitely. This avoids the common pattern where updates are applied after a timeout, on the assumption that the operator’s silence implies consent.

Fixed Update Sources

Update sources are pinned and immutable unless the operator explicitly changes them. The assistant cannot redirect updates to alternative repositories, modify its own update logic, or bypass declared sources. Any discrepancy between expected and actual update sources — a redirect, a changed URL, an unexpected signing key — is treated as a security event regardless of whether the new source appears legitimate. Supply chain attacks frequently rely on redirecting update mechanisms to compromised mirrors, and fixed sources eliminate this vector entirely.

Authorization Model

Each update authorization is explicit, time-bound, and single-use. An approval applies only to the specific update declared at the time of the request. There is no standing approval that permits future updates without review, no blanket authorization for a category of changes, and no mechanism by which past approvals carry forward. If three updates are available, three separate authorizations are required.

This is deliberately friction-heavy. The friction is the feature. It ensures that every change to the assistant’s software passes through a moment of conscious human evaluation, which is the last reliable checkpoint before the change takes effect.

Execution Boundaries

When an update is authorized, execution occurs within the existing isolated environment. No new permissions are granted implicitly as part of the update process. No credentials are modified. No secrets are introduced. The update changes the assistant’s software; it does not change the assistant’s authority. Post-update behavior is observed before normal operation resumes, giving the operator a window to detect regressions or unexpected changes before the assistant acts on its existing delegation.

Rollback

Because the backup model preserves documentation and configuration rather than execution state, rollback does not require restoring a runtime snapshot. Instead, rollback is achieved by redeploying a prior version of the assistant’s software into a clean environment and restoring the documentation vault and configuration from backup. The documentation remains intact regardless of which software version is running, and configuration is revalidated during the rollback to ensure compatibility with the older version.

This approach makes rollback a straightforward operation rather than an emergency procedure. It also avoids the risks inherent in snapshot-based rollback, where restoring a prior state might reintroduce compromised credentials or expired sessions.

Change Documentation

Every approved update triggers documentation in the memory vault: what changed, why the change was accepted, what risks were considered, and what validation was performed afterward. This record serves the same function as documentation elsewhere in the architecture — it provides a traceable, human-readable account of decisions that can be reviewed after the fact. When a behavioral change is noticed weeks later, the documentation provides a starting point for determining whether the change was introduced by a specific update.

Unauthorized Change Detection

Certain events are treated as incidents regardless of their apparent intent: code changes without authorization, update attempts outside the normal schedule, modifications to the update mechanism itself, and dependency changes that were not disclosed in the update request. Detection of any of these triggers credential revocation and investigation. The response is deliberately aggressive because unauthorized changes to the assistant’s software represent a direct compromise of the trust model — if the assistant’s behavior can change without the operator’s knowledge, the operator’s oversight is meaningless.

Lifecycle Awareness

The assistant is designed with the understanding that it is replaceable, upgradeable, and impermanent. This awareness is not philosophical — it is structural. Because the assistant’s memory is externalized and its authority is delegated rather than inherent, a newer version can assume its role without loss of context. This prevents the accumulation of implicit assumptions, undocumented configurations, and version-specific behaviors that make long-lived systems fragile and resistant to change.

Summary

By treating updates as governed, documented, and reversible events, the architecture enables continuous improvement without silent drift. Change is permitted, but it is never invisible. Every modification to the assistant’s software passes through explicit authorization, is bounded in scope, is documented in the memory vault, and can be reversed through redeployment. The system evolves, but it evolves under the operator’s direction.

---

This document establishes controlled evolution. The next section addresses external integrations and API governance within the same framework.