# Paged Context Protocol

A model-agnostic, user-owned context storage protocol: persistent, addressable Pages connect cross-session and cross-project history while authorized models search, read, revise, and link it through ordinary tools.

## Metadata

- HTML: https://glenzli.com/en/projects/paged-context-protocol/
- Markdown: https://glenzli.com/en/projects/paged-context-protocol.md
- Collection: Projects
- Language: en
- Published: 2026-07-15
- Status: active
- Tags: llm-context, protocol, memory, model-agnostic, context-engineering

## Content

Paged Context Protocol, or PCP, is a model-facing logical context storage protocol owned by the user. It does not tell a model how to manage the context window in front of it. It gives the model access to history outside that window: earlier sessions, other projects, old task branches, and ideas that were never written into the current repository.

The current `v0.4.0-draft` explicitly narrows PCP to a context backing store. The protocol defines persistent Page identity, revisioning, scope, provenance, relations, and basic I/O semantics. The model or harness decides when to search, whether to use grep or semantic retrieval, and how to compact its active context.

## Project Entry

  ![Paged Context Protocol organizes cross-session and cross-project history as a persistent Page space](/images/projects/paged-context-protocol-banner.png)

## Core Principles

    **The model owns active context**
    Reading order, working set, search plan, summarization, and compaction belong to the model or harness, not a protocol state machine.

    **The user owns long-term context**
    History is not tied to one model, provider, session, or project directory. Authorized models can share one logical space.

    **Pages keep stable identity**
    A `page_id` identifies one logical object over time; a `revision_id` identifies an immutable version. Window residency does not change either identity.

    **Raw history remains recoverable**
    Summaries, indexes, and model notes are rebuildable derived layers. They cannot silently replace the only original source.

PCP provides one logical address space without globally injecting its contents. Every search runs inside explicit scopes and permissions. Cross-project material cannot enter the candidate set merely because it is semantically similar.

## Protocol Boundary

| Component | Responsibility |
| --- | --- |
| PCP Core | Constrains Page, Revision, Scope, Provenance, Relation, and their I/O and lifecycle semantics. |
| Model Client | Decides when and how to search, read, write, revise, or link Pages. |
| Host | Connects chats, projects, tools, and the Store; handles identity, authorization, scope selection, budgets, and result injection. |
| PCP Store | Persists Pages, Revisions, Relations, raw events, and indexes in files, SQLite, databases, search systems, or mixed backends. |
| Adapter | Maps repositories, files, messages, or other memory systems into Pages while preserving stable source references. |

PCP is a semantic protocol rather than a transport protocol. An implementation may expose MCP tools, HTTP, JSON-RPC, a CLI, local functions, or a filesystem view, as long as every surface refers to the same Page and Revision identities.

## Minimal Data Model

| Object | Meaning |
| --- | --- |
| `Page` | The smallest persistent logical object a model can address and compose. It is not a fixed token block and does not require a summary. |
| `Revision` | An immutable Page version. Revisions create new IDs and can use `expected_revision_id` for conflict detection. |
| `Scope` | An access boundary formed from `owner_id`, `namespace`, and `visibility`. |
| `Provenance` | Records who introduced content, through which operation, and from which input revisions. It proves lineage, not truth. |
| `Relation` | A typed, directed edge between Revisions, such as `depends_on`, `contradicts`, `supersedes`, or `derived_from`. |
| `Facets` | Optional summaries, keywords, anchors, and symbols used for indexing or reading assistance, never as substitutes for source evidence. |

A minimal Page Revision can look like this:

```json
{
  "page_id": "pg_01...",
  "revision_id": "rev_01...",
  "owner_id": "user_01...",
  "namespace": "project:formal-math",
  "visibility": "private",
  "lifecycle_status": "active",
  "created_at": "2026-07-15T20:00:00+08:00",
  "created_by": {
    "actor_type": "system",
    "actor_id": "continuity_host"
  },
  "payload": {
    "media_type": "text/markdown",
    "content": "Earlier discussion of compactness under finite products..."
  },
  "source_refs": ["conversation:2026-05-14#message-32"],
  "provenance": [
    {
      "operation": "ingest",
      "actor_type": "system",
      "actor_id": "continuity_host",
      "timestamp": "2026-07-15T20:00:00+08:00",
      "input_revision_ids": []
    }
  ]
}
```

The payload may contain content or a stable reference to a large file or object store. The protocol leaves domain content open: conversations, code, images, decisions, failed approaches, open questions, and model-maintained indexes can all become Pages.

## Core Interfaces

      **Discovery and reading**
      Discover Store capabilities and scopes, search candidate Pages, then read content, sources, relations, or revision history as needed.

```text
DescribeCapabilities
ListScopes
SearchPages
ReadPages(manifest | payload | source_spans | relations | facets | history)
```

These calls do not form a mandatory pipeline. A model may start from a symbol, a time range, or a relation traversal, and it may combine full-text and semantic search in parallel.

      **Writing, revising, and linking**
      New content receives stable Page identity; changes create new Revisions, while relations retain typed endpoints and authorship.

```text
WritePage(payload, scope, provenance, idempotency_key)
RevisePage(page_id, expected_revision_id, payload)
LinkPages(from_revision_id, relation_type, to_revision_id)
```

The Store does not overwrite a published Revision in place. Summarization, merging, and reorganization also create a derived Page, Revision, or Relation.

      **Events and lifecycle**
      The Host may ingest raw messages and tool events; temporary suppression, archival, withdrawal, and physical deletion retain distinct meanings.

```text
IngestEvent
SuppressPages
TombstonePage
DeletePage
```

`SuppressPages` affects a task or query; `TombstonePage` preserves audit relationships; irreversible deletion remains subject to user authorization and retention policy.

## A Cross-Project Lookup

The following is one valid call shape, not a PCP-mandated workflow. A model may first discover accessible scopes and then search only the authorized set:

```json
{
  "query": "Did we previously discuss a proof that finite products preserve compactness?",
  "scopes": ["project:formal-math", "user:user_01"],
  "mode": "auto",
  "filters": {
    "relation_types": ["depends_on", "inspired_by"],
    "lifecycle_status": ["active", "superseded"]
  },
  "limit": 20
}
```

Search results include Page and Revision identity, original scope, match channel, available facets, and readable projections. The model can then fetch payload, exact source spans, or relations instead of receiving one concatenated text block with lost provenance.

## What v0.4 Removed

`v0.4.0-draft` is not backward compatible with `v0.3.0-alpha`. It keeps stable Page identity, demand-driven access, and source traceability while removing prescriptions for model runtime behavior.

| v0.3.0-alpha | v0.4.0-draft |
| --- | --- |
| Router, Worker, Consolidator, and Auditor processors | Logical Model Client, Host, Store, and Adapter boundaries with no required deployment topology |
| Intent Focus and fixed routing stages | Ordinary `SearchPages` queries decomposed and combined by the model |
| `Summary -> Detail -> Unpacked` zoom state machine | Optional Facets, per-request Read Projections, and Relation traversal |
| `Consult / Explore / Shelve / Purge` | Ordinary Search and Read, harness working-set management, and separate lifecycle operations |
| Separate P-Mem profile | The persistent Page Store becomes PCP Core itself |
| One-dimensional `trust` | Separate authority, integrity, epistemic status, sensitivity, and instruction policy |

The previous generation remains under `deprecated/v0.3.0-alpha/` as a design record. It documents why detailed runtime scaffolding was useful at one stage and why those procedures left the Core once models could manage active context themselves.

## Authorization and Provenance

PCP requires authorization before relevance. Unauthorized content cannot appear merely because it scores highly, and cross-scope recall must be explicit and retain its original scope.

External material, historical dialogue, and model-derived Pages are data by default. Entering the Store does not grant them instruction authority. Integrity, epistemic status, sensitivity, and instruction eligibility are separate questions rather than one generic trust label. Users must be able to inspect, export, restrict, and delete their long-term context.

## Current Status

PCP is currently a `v0.4.0-draft` protocol, not a released SDK or hosted service. Work is focused on the minimal Core and interface boundary. Implementations, cross-model behavior, and evaluation over millions of tokens of dense context remain open work.

This page describes protocol capabilities and design choices, not measured performance.

## Documents

| Document | Contents |
| --- | --- |
| `README.md` | Bilingual overview, core principles, non-goals, and current status. |
| `PROTOCOL.md` | Chinese `v0.4.0-draft` specification covering the data model, Core interfaces, lifecycle, authorization, and conformance. |
| `PROTOCOL-en.md` | Current English protocol specification. |
| `deprecated/README.md` | Index of historical protocol generations. |
| `deprecated/v0.3.0-alpha/README.md` | Deprecation rationale, retained contributions, and concept migration table for v0.3. |