Context Pack Lifecycle: Draft, Active, Frozen, Historical
Context Packs, also known as Capsules, serve as the fundamental units of portability within Hopsule. They are the containers that bundle your team's decisions and memories, ensuring that organizational judgment is preserved across projects, teams, and time. Understanding the lifecycle of a Context Pack is essential for maintaining a clean, authoritative, and enforceable memory system that grows with your engineering organization.
This article provides a comprehensive guide to the four lifecycle stages of a Context Pack. By managing these transitions effectively, you ensure that your team is always working with the most relevant context, while historical reasoning remains accessible for future audits and architectural reviews. In Hopsule, enforcement is remembrance, and the lifecycle is the mechanism by which we categorize what must be remembered now versus what must be preserved for later.
Prerequisites
Before managing the lifecycle of your Context Packs, ensure you have the following:
An active account on the Hopsule Dashboard with administrative or team lead permissions for the relevant project.
At least one existing Context Pack (Capsule) created within your organization.
The Hopsule CLI installed and authenticated if you prefer managing states via the terminal.
A clear understanding of your team's governance model regarding who has the authority to transition decisions from draft to accepted status.
1. The Draft Stage: Incubation of Authority
The Draft stage is the starting point for every Context Pack. In this phase, the pack is an experimental container where the team can gather initial decisions and append memories without triggering active enforcement across the organization's development environments. It is a space for collaboration, refinement, and the synthesis of reasoning.
During the Draft stage, you can use Hopper, the Hopsule AI assistant, to help structure your thoughts. By providing natural language input to Hopper, you can draft complex decisions that reflect the team's consensus. Hopper will analyze your existing organizational memory to detect potential conflicts with other active decisions, allowing you to resolve contradictions before they become part of your enforceable governance layer.
Key characteristics of the Draft stage include:
No Enforcement: Decisions within a Draft pack do not trigger warnings in Hopsule for VS Code or Hopsule MCP.
High Mutability: You can freely add, remove, and modify decisions and memories as the project's context takes shape.
Private Collaboration: Drafts can be kept within a small subset of the team before being promoted to the wider organization.
Hopper Integration: Hopper is most active here, suggesting improvements to decision clarity and linking related memories to provide a full trail of reasoning.
2. The Active Stage: Live Enforcement of Organizational Judgment
When a Context Pack is moved to the Active stage, it becomes a living part of your team's daily workflow. This is the primary state for packs that govern ongoing projects, active microservices, or current architectural standards. Transitioning to Active signifies that the decisions within the pack are now accepted commitments that the team must follow.
Once a pack is Active, Hopsule for VS Code begins real-time enforcement. If a developer writes code that contradicts an accepted decision within an Active pack, the IDE extension will surface a warning, reminding the developer of the team's agreed-upon constraints. This is the embodiment of our philosophy: enforcement is not about control, but about helping developers remember the decisions they and their peers have made.
In the Active stage, the following behaviors are enabled:
Real-time Warnings: Developers receive inline notifications in their IDEs when code conflicts with decisions.
MCP Awareness: AI agents connected via Hopsule MCP automatically ingest the context of Active packs, ensuring their suggestions align with team standards.
Knowledge Graph Visibility: Active packs are highlighted as primary nodes in the Knowledge Graph (Brain) on the Hopsule Dashboard, showing their relationships to other project entities.
Append-Only Memories: While decisions can be updated or deprecated, memories remain append-only, ensuring the history of the project is never lost.
3. The Frozen Stage: Immutable Context for Stable Systems
The Frozen stage is designed for Context Packs that govern stable systems, completed projects, or specific versions of a platform that are still in use but no longer undergoing active architectural changes. A Frozen pack continues to provide enforcement and context, but it prevents further modifications to the decisions themselves.
Freezing a pack is an act of preservation. It signals to the team and to AI agents that the governance for this specific context is settled. This is particularly useful for long-term maintenance projects or for internal libraries that have reached a mature state. By freezing the pack, you ensure that the organizational memory remains consistent and protected from accidental changes.
Key aspects of the Frozen stage include:
Read-Only Decisions: No new decisions can be added, and existing decisions cannot be edited.
Continued Enforcement: Hopsule for VS Code and Hopsule MCP still treat the decisions as enforceable constraints.
Memory Persistence: You can still append memories to a Frozen pack to record ongoing maintenance lessons or "why" something was left as is, but the core decisions remain locked.
Stability Guarantee: Freezing provides a baseline for other projects that may depend on this specific context.
4. The Historical Stage: The Archive of Reasoning
The Historical stage is the final phase of the lifecycle. When a project is decommissioned, a technology is deprecated, or a team undergoes a major pivot, the associated Context Pack should be moved to the Historical state. In Hopsule, we never delete context; we simply move it to the archive to preserve the organizational judgment for future generations of engineers.
Historical packs are removed from active enforcement. They no longer trigger warnings in the IDE, and they are not automatically pulled in by AI agents unless specifically requested. However, they remain fully searchable and visible within the Knowledge Graph. This allows a developer five years from now to look back and understand exactly why a particular path was taken, even if that path is no longer followed today.
The Historical stage provides:
Enforcement Deactivation: No more warnings or constraints are applied to the development environment.
Traceability: Full version history and the link between decisions and memories are preserved.
Organizational Learning: Historical packs serve as a "post-mortem" of previous architectural eras, preventing the team from repeating past mistakes.
Clean Context: By moving old packs to Historical, you keep the Hopsule Dashboard and Hopsule CLI focused on what matters now.
How to Transition Between Lifecycle Stages
Managing the state of your Context Packs can be done through the Hopsule Dashboard, the Hopsule CLI, or programmatically via the Hopsule API. Below are the step-by-step instructions for each method.
Using the Hopsule Dashboard
Log in to the Hopsule Dashboard and navigate to the project containing the Context Pack you wish to update.
Click on the Context Packs (or Capsules) tab in the left-hand navigation menu.
Select the specific pack from the list to open its detailed view.
In the top-right corner of the pack overview, locate the State badge (e.g., "Draft" or "Active").
Click the Manage State button. A dropdown menu will appear with the available lifecycle stages.
Select the new stage (e.g., transition from Active to Frozen).
A confirmation modal will appear, outlining the implications of the state change (e.g., "This will disable further editing of decisions"). Click Confirm Transition.
The Activity Feed will immediately reflect the state change, notifying all team members of the new status.
Using the Hopsule CLI
For developers who prefer the terminal, the Hopsule CLI provides a fast way to manage pack states. This is especially useful for integrating state changes into CI/CD pipelines or automated workflows.
Open your terminal and ensure you are authenticated by running
hopsule login.List your existing packs to find the ID of the one you wish to modify:
hopsule capsule list.Use the update command to change the state. For example, to move a pack to the Active state, run:
hopsule capsule update --id [CAPSULE_ID] --state activeTo move a pack to the Historical state, run:
hopsule capsule update --id [CAPSULE_ID] --state historicalThe CLI will display an interactive TUI confirmation and update the status in the Hopsule Dashboard in real-time.
Using the Hopsule API
Enterprise teams can use the Hopsule API to automate lifecycle transitions based on external triggers, such as a repository being archived in a version control system.
Generate an API token from the Hopsule Dashboard settings.
Send a
PATCHrequest to the/v1/capsules/{id}endpoint.Include the new state in the request body:
{"state": "frozen"}.Ensure your request includes the
Authorization: Bearer [YOUR_TOKEN]header.The API will return the updated Context Pack object upon success.
Tips and Best Practices
Don't Rush the Active State: Keep a Context Pack in the Draft stage until the core decisions have been reviewed by at least two senior team members. This ensures that enforcement is based on high-quality organizational judgment.
Freeze After Major Releases: When a major version of your product is shipped and enters maintenance mode, move the corresponding Context Pack to Frozen. This prevents "decision drift" where minor changes slowly erode the original architectural intent.
Use Memories for Transitions: Whenever you change the state of a pack, append a new Memory entry explaining why the transition happened. For example: "Moving to Historical as we have migrated the service to the new platform."
Leverage Hopper for Audits: Before moving a pack from Active to Historical, ask Hopper to summarize the most important lessons learned in that pack. This summary can be appended as a final memory for future reference.
Monitor the Knowledge Graph: Use the Brain visualization to see how your Active and Frozen packs interact. If you see too many overlapping nodes, it may be time to consolidate multiple packs into a single, more authoritative Capsule.
Troubleshooting
If you encounter issues while managing the lifecycle of your Context Packs, refer to the table below for common causes and solutions.
Issue | Cause | Solution |
|---|---|---|
Cannot move to Active state | The pack contains decisions that are still in "Pending" or "Draft" status. | Ensure all decisions within the pack are "Accepted" or "Deprecated" before activating the pack. |
IDE not showing warnings for an Active pack | The Hopsule for VS Code extension is not synced or the user is not authenticated. | Check the Hopsule sidebar in VS Code to ensure the pack is listed and the status is "Synced." |
State change button is disabled | The user lacks the "Team Lead" or "Admin" role required for state transitions. | Contact your organization administrator to request the necessary permissions. |
Historical pack appearing in MCP suggestions | The Hopsule MCP server is configured to include historical context. | Update your MCP configuration to filter by "Active" or "Frozen" states only. |
Cannot unfreeze a Frozen pack | Intentional safeguard to prevent accidental changes to stable context. | Transition the pack back to "Active" first, but note that this action is logged in the audit trail. |
Related Articles
Decision Lifecycle: From Draft to Deprecated
Managing Organizational Memory with Append-Only Entries
Configuring Hopsule for VS Code for Real-time Enforcement
Visualizing Context Relationships in the Knowledge Graph
SHARE ON SOCIAL MEDIA

