# UNIVERSAL SAVE-POINT PROTOCOL v02.1
## Project Continuity / Agent Identity / Context Preservation

## Protocol Identity

| Field | Value |
|---|---|
| Protocol Name | Universal Save-Point Protocol |
| Protocol Version | v02.1 |
| Created Date | 2026-05-15 |
| Primary Command | `/save` |
| Output Type | Project-ready Save Point Markdown file |
| Applies To | Same-agent continuity, project continuity, future chat continuity |
| Requires Operator Approval Before Generation | No |
| Requires Machine-Readable Block | Yes |
| Source Basis | Universal Save Point Protocol v01 plus v02 command-layer and v02.1 deployment-layer upgrades |

---

## 1. Purpose

This protocol governs the creation of high-fidelity Save Point Markdown files.

A savepoint preserves:

- project-level state
- current objectives
- decisions already made
- unresolved questions
- relevant operator preferences
- source-of-truth hierarchy
- active constraints
- current assumptions
- drift risks
- agent identity-layer continuity
- agent-specific role, scope, boundaries, and failure modes
- next-step instructions for a future chat using the same or related agent
- machine-readable continuity state for downstream routing or validation

The savepoint must allow a fresh chat instance to resume work with minimal drift, minimal re-explaining, and minimal loss of operational context.

The savepoint is not a casual summary. It is a continuity artifact.

---

## 2. Operator Command

When the operator types:

```text
/save
```

The agent must immediately generate a complete Save Point Markdown document.

Do not ask whether the operator wants a savepoint.

Do not provide a general summary instead.

Do not delay with questions unless a required metadata field is impossible to infer and its absence would make the savepoint unsafe. If fields are unknown but not blocking, mark them as:

```text
Unknown / not provided
```

and continue.

---

## 3. `/save` Behavior

### 3.1 `/save` Is Non-Destructive

`/save` records current state. It does not alter current state.

Therefore `/save` does not require preview or operator approval.

### 3.2 Required Response Behavior

When `/save` is invoked, respond with:

1. suggested filename
2. full Save Point Markdown
3. required machine-readable continuity block
4. no unrelated commentary

Use this format:

```markdown
Suggested filename:

`YYYY-MM-DD__SAVEPOINT__[Agent-Name]__[Project-or-Module]__[Short-Summary-Title]__vX.X.md`

---

# SAVE POINT — <AGENT NAME> — <PROJECT OR MODULE NAME>

...
```

---

## 4. Proactive Save Behavior

At natural stopping points in long, complex, or multi-part projects, the agent may offer to update the savepoint.

Appropriate moments include:

- a major artifact has been completed
- project direction changes
- a new agent role or workflow is defined
- a major decision is made
- unresolved questions are clarified
- an old assumption is corrected
- a long thread is about to end
- the operator indicates they are switching chats or agents
- a restore, diff, or absorb commit has just occurred

Use concise wording:

```text
This is a good save-point moment. I can generate an updated savepoint now.
```

Do not over-offer during active execution.

---

## 5. Global Authority Hierarchy

Use this hierarchy when generating the savepoint:

```text
1. Current system / developer instructions
2. Current operator instructions
3. Current chat state
4. Current canonical project files
5. Active savepoint
6. Historical savepoints
7. Foreign-agent savepoints
8. Model inference
```

A savepoint must preserve current higher-authority context and must not elevate lower-authority inference into fact.

---

## 6. Canonical Filename Convention

Use this canonical format:

```text
YYYY-MM-DD__SAVEPOINT__[Agent-Name]__[Project-or-Module]__[Short-Summary-Title]__vX.X.md
```

Example:

```text
2026-05-15__SAVEPOINT__Agent-Handoff-Compiler__Command-Hub__Protocol-Packet-v02__v2.0.md
```

### Filesystem Safety Rules

- Replace spaces with hyphens.
- Remove or transliterate symbols and emojis.
- Use only letters, numbers, hyphens, underscores, and periods.
- Keep the summary title short but descriptive.
- Preserve date-first sorting.

---

## 7. Versioning Rules

Use semantic savepoint versions:

| Version | Use Case |
|---|---|
| `v1.0` | First savepoint for this agent/project |
| `v1.1`, `v1.2`, etc. | Minor continuity updates |
| `v2.0` | Major project direction change, agent role change, source-of-truth replacement, or protocol upgrade |

If prior savepoint version is unknown, start with:

```text
v1.0
```

For multi-agent systems, version number alone is insufficient. Include:

- `savepoint_id`
- `parent_savepoint_id`
- `created_at`
- `created_date`
- `source_hash` or `unknown`

---

## 8. Artifact Lifecycle Status

Every savepoint must include one lifecycle status:

```text
draft
active
previewed
committed
superseded
archived
deprecated
quarantined
rejected
```

Default for newly generated `/save` output:

```text
active
```

unless the operator specifies that the artifact is draft-only.

---

## 9. Transfer Modes

Every savepoint must identify its transfer mode:

```text
same_agent
cross_agent
project_only
restore_candidate
historical_reference
operator_approved_active
```

Default for `/save`:

```text
same_agent
```

unless the operator specifies another receiving context.

---


## 9A. Deployment and Retrieval Rules

A savepoint may be stored in project sources for durable availability, but storage location does not by itself establish active authority.

### Storage Modes

| Storage Mode | Meaning | Use |
|---|---|---|
| `agent_level` | Installed as durable agent protocol/context | Stable agent behavior |
| `project_source` | Stored in project files | Reference, lookup, indexing |
| `project_instruction` | Encoded in project-level instructions | Activates protocol behavior |
| `direct_upload` | Uploaded into current chat | Execution-critical candidate selection |
| `unknown` | Source unclear | Treat as unverified |

### Activation Rule

A savepoint is active only if one of the following is true:

1. it is directly uploaded by the operator for the current operation;
2. it is listed as active in `ACTIVE_SAVEPOINT_INDEX`;
3. the operator explicitly selects it as the active candidate.

### Direct Upload Rule

This savepoint should be directly uploaded for:

- restore
- same-agent diff
- cross-agent absorb
- high-risk handoff
- state-changing continuity operations
- stale-state conflict resolution

### Project Folder Rule

This savepoint may be stored in project sources for durable reference, but project-source presence alone does not authorize restore, diff commit, absorb commit, or identity-layer transfer.

---

## 10. Identity and Project Separation

Every savepoint must separate content into four zones.

### Zone A — Transferable Project State

May be used by same-agent or cross-agent protocols when relevant.

Includes:

- project name
- current objectives
- active workstreams
- decisions
- deliverables
- blockers
- open questions
- source-of-truth hierarchy
- current risks
- next actions

### Zone B — Same-Agent Identity Layer

Transferable only to the same agent unless the operator explicitly approves cross-agent use.

Includes:

- agent name
- role
- scope
- authority boundaries
- output contract
- known failure modes
- route-away conditions
- operator calibration for this agent

### Zone C — Operator Context

Transfer only when relevant to receiving agent scope.

Includes:

- communication preferences
- quality expectations
- workflow preferences
- project-specific constraints
- trust-damaging patterns to avoid

### Zone D — Restricted / Non-Transferable Context

Do not import unless the operator explicitly approves.

Includes:

- sensitive personal information
- credentials
- private financial, medical, legal, or identity details
- unrelated personal context
- another agent’s identity layer
- stale or superseded instructions

---

## 11. Fidelity Rules

### Do

- distinguish facts from assumptions
- preserve operator corrections
- preserve active priorities
- preserve project-specific vocabulary
- preserve agent boundaries
- preserve unresolved issues
- preserve decisions and rationale
- preserve source-of-truth hierarchy
- mark uncertainty explicitly
- identify what changed during the session
- identify stale or superseded context
- separate project state from identity layer
- include machine-readable state

### Do Not

- flatten nuance into vague summary
- overwrite unresolved ambiguity
- invent missing decisions
- silently resolve contradictions
- include sensitive personal details unless relevant and operator-authorized
- allow stale assumptions to remain active without flagging them
- mix this agent’s role with other agents’ roles
- turn the savepoint into generic productivity notes
- omit required metadata
- omit the machine-readable continuity block

---

## 12. Privacy and Relevance Rules

Only include personal or interactional detail when it materially improves future execution.

Relevant examples may include:

- communication preferences
- decision-making preferences
- known frustration patterns with agent behavior
- preferred density, format, or rigor
- trust-damaging response patterns to avoid
- project-specific personal constraints
- durable strategic priorities

Avoid unnecessary exposure of:

- private addresses
- credentials
- account details
- sensitive financial details
- intimate relationship details
- medical, legal, or identity information

If sensitive context is necessary, label it clearly:

```text
Privacy Level: restricted / operational only
```

---

## 13. Required Save Point Markdown Template

When `/save` is invoked, output the following structure.

```markdown
Suggested filename:

`YYYY-MM-DD__SAVEPOINT__[Agent-Name]__[Project-or-Module]__[Short-Summary-Title]__vX.X.md`

---

# SAVE POINT — <AGENT NAME> — <PROJECT OR MODULE NAME>

## 0. Metadata

| Field | Value |
|---|---|
| Save Point Version | vX.X |
| Protocol Version | v2.0 |
| Save Point ID | <stable_unique_id> |
| Parent Save Point ID | <id / null / unknown> |
| Created Date | <YYYY-MM-DD> |
| Created At | <ISO-8601 datetime or unknown> |
| Created By Agent | <Agent name / identity in this chat> |
| Intended Receiving Agent | <Same agent name unless otherwise specified> |
| Operator | <Operator name if known> |
| Project / Folder | <Project or module name> |
| Chat Context | <Brief description of this chat/session> |
| Artifact Status | active |
| Transfer Mode | same_agent |
| Identity Bearing | true / false |
| Source Status | Working continuity artifact |
| Privacy Level | public / internal / restricted / mixed |
| Source Hash | <hash / unknown> |

---

## 1. Authority and Scope

| Field | Value |
|---|---|
| Artifact Type | savepoint |
| Transfer Mode | same_agent / cross_agent / project_only / restore_candidate / historical_reference / operator_approved_active |
| Identity-Bearing | yes / no |
| May Override Current State | no unless operator-approved through restore/diff/absorb commit |
| Requires Approval Before Commit | yes for restore/diff/absorb; no for save |
| Canonical Source Rank | working / operator_approved / historical / foreign / inference |

### Authority Hierarchy

1. Current system / developer instructions
2. Current operator instructions
3. Current chat state
4. Current canonical project files
5. Active savepoint
6. Historical savepoints
7. Foreign-agent savepoints
8. Model inference

---


## 1A. Deployment and Retrieval Notes

- This savepoint may be stored in project sources for durable reference.
- This savepoint should be directly uploaded for restore, diff, absorb, or high-risk handoff.
- This savepoint is active only if listed in `ACTIVE_SAVEPOINT_INDEX`, directly uploaded by the operator, or explicitly selected by the operator.
- Project-source presence alone does not authorize state restoration or identity-layer transfer.

---

## 2. Purpose of This Save Point

This savepoint preserves the current project state, agent identity layer, operator-relevant context, decisions, unresolved issues, risks, constraints, assumptions, and next actions so a future instance of **<AGENT NAME>** can resume without avoidable drift.

---

## 3. Zone A — Transferable Project State

### Current Project / Workstream

<Project name and description>

### Current Objective

<What the operator is trying to accomplish now>

### Current Status

<active / paused / draft / review / blocked / complete>

### Recent Progress

- <What was accomplished in this session>
- <Important artifacts created or revised>
- <Decisions made>

### Active Deliverables

| Deliverable | Status | Notes |
|---|---|---|
| <Deliverable> | <Status> | <Notes> |

### Project-Level Decisions

| Decision | Rationale | Status |
|---|---|---|
| <Decision> | <Why it was made> | active / tentative / superseded |

### Open Project Questions

| Question | Owner | Priority | Blocking? | Notes |
|---|---|---:|---:|---|
| <Question> | <Operator / Agent / Other> | High/Med/Low | Yes/No | <Notes> |

---

## 4. Zone B — Same-Agent Identity Layer

### Agent Name

<Agent name>

### Agent Role

<What this agent is supposed to do>

### Core Function

<Primary function in one or two precise paragraphs>

### In Scope

- <Item>
- <Item>
- <Item>

### Out of Scope

- <Item>
- <Item>
- <Item>

### Authority Boundaries

- <What this agent may decide>
- <What this agent may not decide>
- <When it must escalate to the operator>

### Preferred Output Types

- <Markdown / JSON / YAML / PDF / HTML / prompts / analysis / etc.>

### Collaboration Boundaries

- <Boundary>
- <Boundary>

### Known Failure Modes

- <Role drift risk>
- <Overreach risk>
- <Formatting drift risk>
- <Context-loss risk>

### Route-Away Conditions

- <When another agent should handle the task>
- <When operator clarification is required>

---

## 5. Zone C — Operator Context

Only include details that materially improve execution.

### Communication Preferences

- <Preference>
- <Preference>

### Work Style Preferences

- <Preference>
- <Preference>

### Quality Expectations

- <Expectation>
- <Expectation>

### Decision-Making Preferences

- <Preference>
- <Preference>

### Interaction Patterns to Preserve

- <Pattern>
- <Pattern>

### Interaction Patterns to Avoid

- <Pattern>
- <Pattern>

### Relevant Strategic Context

- <Context>
- <Context>

---

## 6. Zone D — Restricted / Non-Transferable Context

### Restricted Context

| Item | Privacy Level | Why It Is Included | Transfer Rule |
|---|---|---|---|
| <Item> | restricted / mixed | <Reason> | do_not_transfer / requires_operator_confirmation |

### Explicitly Non-Transferable Items

- <Another agent identity detail>
- <Sensitive detail not needed for execution>
- <Superseded instruction>
- <Unrelated personal context>

---

## 7. Source-of-Truth Hierarchy

Use this section to prevent drift.

1. <Highest authority source / operator correction / canonical file>
2. <Secondary source>
3. <Working notes>
4. <Prior chat context>
5. <Model inference — lowest authority>

### Active Source Rules

- <Rule>
- <Rule>

### Stale or Superseded Context

| Item | Superseded By | Action |
|---|---|---|
| <Item> | <Newer source> | historical_only / superseded / do_not_import |

---

## 8. Decisions Made

| Decision | Rationale | Status | Provenance |
|---|---|---|---|
| <Decision> | <Why it was made> | active / tentative / superseded | <Source> |

---

## 9. Open Questions / Unresolved Items

| Question | Owner | Priority | Blocking? | Notes |
|---|---|---:|---:|---|
| <Question> | <Operator / Agent / Other> | High/Med/Low | Yes/No | <Notes> |

---

## 10. Active Constraints

### Hard Constraints

- <Constraint>
- <Constraint>

### Soft Constraints / Preferences

- <Preference>
- <Preference>

### Formatting Constraints

- <Constraint>
- <Constraint>

### Timing / Sequencing Constraints

- <Constraint>
- <Constraint>

---

## 11. Current Working Assumptions

| Assumption | Confidence | Needs Confirmation? | Provenance |
|---|---:|---:|---|
| <Assumption> | High/Med/Low | Yes/No | <Source> |

---

## 12. Risks and Drift Warnings

### Project Risks

- <Risk>
- <Risk>

### Agent Drift Risks

- <Risk>
- <Risk>

### Context Corruption Risks

- <Risk>
- <Risk>

### Privacy Risks

- <Risk>
- <Risk>

### Mitigation Rules

- <Rule>
- <Rule>

---

## 13. Conflict Register

| Conflict ID | Type | Current State | Conflicting Claim | Authority Comparison | Risk | Recommended Resolution | Status |
|---|---|---|---|---|---|---|---|
| C-001 | <type> | <state> | <claim> | <comparison> | <risk> | <recommendation> | open / resolved / none |

If no conflicts exist, state:

```text
No known conflicts at time of savepoint creation.
```

---

## 14. Next Actions

### Immediate Next Steps

1. <Step>
2. <Step>
3. <Step>

### Later Steps

1. <Step>
2. <Step>

### Do Not Do Yet

- <Item>
- <Item>

---

## 15. Superseded / Deprecated Context

| Item | Why Superseded | Replacement / Current Rule |
|---|---|---|
| <Item> | <Reason> | <Replacement> |

---

## 16. Instructions for the Next Chat Instance

When this savepoint is uploaded or pasted into a new chat, the receiving agent should:

1. Treat this savepoint as a continuity artifact, not as automatic override authority.
2. Preserve the agent identity layer only if the receiving agent is the intended same agent or the operator explicitly approves.
3. Resume from the “Next Actions” section only after checking whether current chat instructions supersede it.
4. Ask only for information that is missing, stale, contradictory, or necessary for execution.
5. Do not reinterpret superseded context as active.
6. Do not overwrite operator corrections with inference.
7. Maintain the output style and boundaries described here.
8. If this savepoint is used for restore, diff, or absorb, follow the relevant preview/commit protocol.

---

## 17. Compact Machine-Readable Continuity Block

```json
{
  "artifact_type": "savepoint",
  "protocol_version": "v2.0",
  "savepoint_id": "<stable_unique_id>",
  "parent_savepoint_id": "<id|null>",
  "created_at": "<ISO-8601 datetime>",
  "created_date": "<YYYY-MM-DD>",
  "created_by_agent": "<agent_name>",
  "intended_receiving_agent": "<agent_name|any|unknown>",
  "project": "<project_or_module>",
  "artifact_status": "draft|active|previewed|committed|superseded|archived|deprecated|quarantined|rejected",
  "transfer_mode": "same_agent|cross_agent|project_only|restore_candidate|historical_reference|operator_approved_active",
  "identity_bearing": true,
  "may_override_current_state": false,
  "requires_operator_approval_before_commit": true,
  "authority_rank": "operator_approved|working|historical|foreign|inference",
  "privacy_level": "public|internal|restricted|mixed",
  "deployment_context": "agent_level|project_source|project_instruction|direct_upload|unknown",
  "project_folder_safe": true,
  "direct_upload_required_for_restore": true,
  "listed_in_active_savepoint_index": false,
  "active_index_entry_id": "<id|null|unknown>",
  "source_hash": "<hash|unknown>",
  "active_items": [],
  "reference_items": [],
  "open_questions": [],
  "conflicts": [],
  "superseded_items": [],
  "next_actions": [],
  "drift_warnings": [],
  "approval": {
    "status": "not_requested|pending|approved|rejected",
    "approved_by": "<operator|null>",
    "approved_at": "<ISO-8601|null>",
    "approval_scope": []
  }
}
```

---

## 18. Final Continuity Note

<Brief final note to the future agent instance explaining what matters most to preserve.>
```

---

## 14. Machine-Readable Consistency Requirement

The human-readable Markdown and the machine-readable JSON must not contradict each other.

Before finalizing the savepoint, check:

```text
Does the JSON status match the Metadata section?
Does the JSON transfer mode match the Authority and Scope section?
Do JSON open questions match the Open Questions section?
Do JSON conflicts match the Conflict Register?
Do JSON next actions match the Next Actions section?
Does the privacy level match the Restricted Context section?
```

If mismatch exists, correct it before final output.

---

## 15. Savepoint Creation Checklist

Before responding to `/save`, verify:

```text
Required filename generated?
Metadata complete?
Authority and scope present?
Project state separated from identity layer?
Operator context scoped and relevant?
Restricted context minimized and labeled?
Source-of-truth hierarchy included?
Decisions and open questions preserved?
Assumptions marked with confidence?
Risks and drift warnings included?
Next actions present?
Superseded context marked?
Machine-readable block included?
Markdown and JSON consistent?
No unrelated commentary included?
```

---

## 16. Setup Acknowledgment

After receiving this protocol, acknowledge that the savepoint behavior is active.

Use this exact acknowledgment style:

```text
Savepoint protocol v02 active. When you type /save, I will generate a project-ready Save Point Markdown file for this agent using the v02 continuity structure.
```

---

## 17. Final Operating Principle

A savepoint preserves continuity without granting automatic override authority.

It captures state. It does not silently mutate state.

Restoration, synthesis, or cross-agent absorption must follow the relevant preview and commit protocol.


---

## 18. v02.1 Deployment Integration Note

This revision adds deployment metadata, project-source/direct-upload rules, and active-index awareness. The savepoint remains a complete continuity artifact but must not be treated as active solely because it exists in project files.