02 — Core Rule

Preserve state before the work branches.

Use a savepoint before changing issue scope, approving a draft structure, splitting work into VSRs, handing work to another agent, restoring prior state, absorbing new instructions, merging a revised process, moving from exploration to production, using headless agents, or committing public-facing material.

The operator should know what survives the next move.

03 — What a Savepoint Is

A savepoint is a structured record of project state.

A strong savepoint is not decorative. It is restorable.

04 — What a Savepoint Is Not

A transcript records everything that happened. A savepoint records what should survive. The transcript is evidence. The savepoint is state.

A summary compresses. A savepoint preserves decisions, exclusions, conflicts, unresolved questions, and next-state instructions.

Memory can preserve preferences or recurring context. A savepoint preserves project state.

A savepoint captures state. A handoff packet tells the next agent or system how to use that state.

05 — Savepoint Anatomy

A useful savepoint has eight parts.

1. Identity / Scope
2. Objective
3. Current State
4. Approved Decisions
5. Active Constraints
6. Conflict Register
7. Open Questions
8. Next Action

Example:

Project:
Issue / Report:
Savepoint date:
Savepoint version:
Current phase:

Objective:
Current state:
Approved decisions:
Active constraints:
Conflict register:
Open questions:
Next action:

06 — The Savepoint Lifecycle

1. Review current project state.
2. Preview proposed savepoint before committing it.
3. Create a conflict register instead of silently smoothing contradictions.
4. Get operator approval.
5. Commit the savepoint as the working baseline.
6. Create a new savepoint after any major merge, restore, branch, or approval.

The purpose is not bureaucracy.

The purpose is controlled continuity.

07 — Handoff Packets

A handoff packet is a savepoint adapted for another person, tool, system, or phase.

Savepoints preserve state.

Handoff packets transfer state.

Use a handoff packet when a project moves from one working context to another: research becomes a draft, a transcript becomes a record, a report becomes a field tool, a draft becomes implementation work, or a long-running project moves from one contributor to another.

A good handoff packet does not expose private process history. It gives the receiver the minimum durable state needed to continue accurately.

08 — Handoff Packet Anatomy

A useful handoff packet has six parts.

1. Objective
2. Relevant Findings
3. Required Preservation
4. Constraints
5. Open Questions
6. Suggested First Action

Template:

HANDOFF PACKET

Objective:
Relevant findings:
Required preservation:
Recommended execution output:
Constraints:
Open questions:
Suggested first action:

09 — Savepoint Types

Content / Report Savepoint

Captures thesis, report status, section routing, approved framing, rejected directions, source posture, and next draft action.

Reasoning Session Savepoint

Captures session purpose, major turns, useful objections, durable findings, unresolved questions, pull quotes, source flags, and routing notes.

Source Savepoint

Captures selected source backbone, rejected sources, source use notes, limitations, claim-control rules, and pending citations.

Attribution / Responsibility Savepoint

Captures which sections or decisions belong to which person, system, role, or team; which materials are approved; which materials require review; and which attributions need to be preserved.

Implementation Handoff Savepoint

Captures project structure, assets needed, implementation constraints, unresolved questions, risk notes, deployment or delivery constraints, and next actions.

10 — Savepoint Trigger Conditions

Create or update a savepoint when any of these happen: scope changes, ownership or responsibility changes, source posture changes, a reasoning session produces a durable finding, drift appears, another person or system needs the work, or the system makes a state error.

Example triggers:

• A project changes from exploration to execution.
• A section, decision, or deliverable is approved and should not be casually rewritten.
• A source set changes from broad research to selected support.
• A reasoning session produces an applied tool or durable recommendation.
• A quote, claim, or responsibility label is corrected.
• An old assumption conflicts with the current direction.

11 — The Conflict Register

A conflict register prevents quiet corruption.

Template:

CONFLICT REGISTER

Conflict:
Why it matters:
Affected section:
Current instruction:
Older instruction / competing state:
Recommended resolution:
Operator decision needed:

12 — Savepoint Templates

Quick Savepoint

SAVEPOINT — QUICK

Project:
Current objective:
Approved decisions:
Active constraints:
Do not carry forward:
Open questions:
Next action:

Full Savepoint

SAVEPOINT — FULL

Project:
Issue / report:
Version:
Date:
Current phase:

Objective:
Current state:
Approved decisions:
Rejected directions:
Active constraints:
Source posture:
Authorship rules:
Artifacts produced:
Artifacts pending:
Conflict register:
Open questions:
Next action:
Restore instructions:

Handoff Packet

HANDOFF PACKET

Objective:
Relevant findings:
Required preservation:
Recommended execution output:
Constraints:
Open questions:
Suggested first action:

13 — Applied Scenario: Long-Running Research Project

SAVEPOINT — RESEARCH PROJECT

Project:
A multi-session research and implementation project

Current phase:
Research completed; implementation plan in review.

Objective:
Preserve the current project state before moving from research into execution.

Approved decisions:
- The main objective has been defined.
- The source set has been reviewed.
- The implementation sequence has been drafted.
- Open risks remain unresolved and must not be hidden.

Active constraints:
- Do not treat exploratory notes as approved decisions.
- Do not merge old assumptions into the current plan without review.
- Do not proceed to execution until unresolved risks are assigned.

Current materials:
- Research notes
- Decision log
- Source list
- Draft implementation plan
- Open questions register

Conflict register:
- Risk: early assumptions may no longer match the approved direction.
- Risk: source notes may support background context but not final claims.
- Risk: unresolved questions may be mistaken for settled decisions.
- Risk: execution may begin before ownership is assigned.

Next action:
Review the conflict register, resolve open questions, and create a new savepoint before implementation begins.

14 — What This Replaces

Replaces “The thread is enough” with “The thread is a record, not a state object.”

Replaces “The assistant will remember” with “The project state must be preserved.”

Replaces “Summarize where we are” with “Prepare a savepoint candidate and identify conflicts.”

Replaces “Just hand this off” with “Transfer objective, findings, constraints, open questions, and first action.”

Replaces “The system apologized” with “Restore the affected state and show the delta.”

15 — Protocol Package Resources

Use these companion resources when turning the savepoint method into a working protocol package:

• Savepoint Protocol Quickstart
• Savepoint Operator Guide
• Savepoint Templates
• Savepoint Field Card

Includes operator guide, templates, field card, and printable Quickstart PDF where provided.

16 — Source & Claim Notes

This report is based on the savepoint method developed for the Access Layer package.

Savepoints are presented as an applied continuity framework. They are not described as an external standard.

The underlying logic is practical: AI continuity fails when conversational residue is mistaken for project state. Savepoints create explicit reviewable state, especially before branching, restoring, merging, or handing work to another agent or system.

This report should remain procedural, not philosophical. Its job is to give the operator a working continuity tool.

17 — Closing Signal

Continuity does not preserve itself.

A thread can keep moving while the project state drifts.

A model can apologize while the affected state remains broken.

A memory feature can remember a preference while the current decision disappears.

A handoff can sound complete while the next agent inherits the wrong thing.

Savepoints are not bureaucracy.

They are continuity control.

The operator’s rule:

Preserve the state before the system performs continuity on your behalf.