# PAM v1.0 ↔ OCP 0.4 mapping

**Status:** experimental adjacent-standard mapping; informative until the registered fixture set and two independent adapters pass  
**Prepared:** 2026-08-12  
**OCP target:** Open Continuity Protocol 0.4 — Consolidated Editor's Working Draft  
**PAM target:** [Portable AI Memory Specification v1.0](https://portable-ai-memory.org/spec/v1.0/), Published 2026-02-17, with its JSON Schema Draft 2020-12 memory-store schema  
**Directions:** `P→O` means PAM import into OCP; `O→P` means OCP export to PAM

This mapping is version-pinned. It covers all nine OCP core records and the OCP 0.4 distinctions among exact `snapshotRef`, mutable `liveStatusRef`, source authority, runtime source, epistemic basis, review state, one delivery recipient, plaintext processing recipients, bounded proposal rights, and package-local identifiers. It does not make PAM an OCP authorization, acceptance, or runtime-package format.

## 1. Architectural result

PAM and OCP are composable but not substitutes.

- PAM v1.0 is a portable memory interchange and export representation whose main unit is a natural-language memory object. It also defines relations, conversation indexing, provenance-like metadata, integrity/signature fields, and incremental export metadata.
- OCP 0.4 is a governed-context protocol. It separates imported evidence, structured interpretation, scoped review/acceptance, client declaration, inert disclosure request, non-secret authorization receipt, minimized runtime presentation, proposed change, and immutable review decision.
- A PAM document enters OCP as untrusted source material. Successful schema, hash, integrity, signature, or transport verification does not make its memories accepted, subject-confirmed, authorized for disclosure, or authorized for action.
- PAM has no semantically equivalent object for five OCP records. Its analogues for `context_space` and `context_package` are weak and lossy, while `context_item` is only partial and lossy. Eight of nine OCP core records therefore lack even the mapping's strongest source-record analogue. No OCP core record has yet been proven losslessly round-trippable through PAM alone: every mapping MUST carry explicit loss accounting, and any omitted OCP semantics require an OCP sidecar or declared loss.
- OCP content never conveys external-action authority. PAM `write` or `delete` labels do not alter that boundary.

This mapping remains experimental until machine-readable mapping tables, positive and negative fixtures, loss-report fixtures, and A→B→A semantic comparisons exist for two independent implementations.

## 2. Authority and state levels

| Level | PAM material | OCP 0.4 representation | Mapping rule |
|---|---|---|---|
| Source bytes or source assertion | PAM export, memory, conversation, relation, provenance | `source_record` or a registered source/profile object | `P→O` starts here. Preserve exact source identity and treat content as `untrusted_data`. |
| Provider interpretation | memory derived by inference, extraction, summary, or relation | candidate `context_item` with `epistemic_basis` and exact provenance | Provider interpretation remains a candidate. It cannot become `subject_confirmed` or `accepted` by import. |
| Scoped accepted context | no PAM-native equivalent | exact `context_item` revision plus accepting `review_decision` and committed `accepted_scope` | PAM `active`, high confidence, signature, or user label never creates this state. |
| Disclosure request | no PAM-native equivalent | inert `context_request` | PAM access metadata is a source constraint, not an OCP request. |
| Disclosure decision record | coarse per-memory access metadata | non-secret `grant_receipt` plus current deployment authorization | PAM permissions never become a receipt, token, capability, or authorization decision. |
| Purpose-bound runtime presentation | memory-store export | immutable, minimized `context_package` under one active receipt | A PAM export may be carried as transfer evidence; it is not an OCP runtime package without OCP package construction. |
| External action | PAM may label `write` or `delete` access | outside OCP context authority | OCP remains `external_action_authority: "none"`; a separate domain authorization is required. |

## 3. Exact OCP reference and recipient rules

PAM identifiers and links do not satisfy either OCP reference form by themselves.

| OCP 0.4 structure | PAM analogue | Rule |
|---|---|---|
| `snapshotRef {id, revision, schema_uri, digest}` | memory ID, relation endpoint, export ID | Create only after the referenced OCP record exists. `digest` covers the complete RFC 8785 canonical OCP record, including its ID and revision. A PAM content hash is not substitutable. |
| `liveStatusRef {uri, last_checked_at?}` | no reliable equivalent | A mapping may create a status endpoint only from the OCP deployment. PAM status fields are immutable imported claims, not live OCP status. |
| one `delivery_recipient` | `shared_with` entry or destination label | PAM does not identify an authenticated OCP client service, client instance, and exact declaration snapshot. A new OCP decision supplies all three. |
| `processing_recipients[]` | no complete equivalent | PAM does not disclose every model provider/subprocessor receiving plaintext with OCP purpose codes. The OCP request must stay within the exact client declaration. |
| package-local/pairwise aliases | owner ID, DID, memory IDs | Never expose PAM or OCP stable identifiers as runtime aliases by default. Generate OCP aliases under the verified recipient/instance/purpose/epoch domain. |

An adapter MUST preserve unresolved source-native references as unresolved evidence. It MUST NOT fabricate an exact snapshot, live status endpoint, authenticated recipient, or processor declaration.

## 4. Cardinality and conversion units

| Source unit | Target unit | Cardinality | Required interpretation |
|---|---|---:|---|
| PAM memory | OCP source evidence | `1 → 1` | Preserve the memory representation in or behind one `source_record`. |
| PAM memory | OCP candidate context | `1 → 0..n` | A memory may be quarantined, mapped once, or split into multiple typed candidates. |
| PAM export | OCP import transaction | `1 → 1` | The export is one import source; it does not become one accepted space. |
| OCP context item | PAM memory | `1 → 0..n` | Structured values, subjects, scopes, or profiles may require omission, rendering, or multiple memories. |
| OCP context space | PAM metadata | `1 → 0..1`, lossy | A domain label cannot preserve subjects, authority model, policy reference, or lifecycle. |
| OCP request/receipt/package/proposal/decision | PAM object | `1 → 0` semantically | Use a registered OCP sidecar or report loss. A root PAM export is only a weak transfer analogue for a package. |

A conversion is not lossless merely because all `content` strings survive. Loss evaluation includes typed meaning, subjects, source/runtime roles, epistemic basis, review decision and scope, lifecycle, recipients/processors, authorization separation, integrity coverage, aliases, and unknown extensions.

## 5. PAM root and companion-file mapping

| PAM field or file | `P→O` target | `O→P` source | Loss and guardrail |
|---|---|---|---|
| `schema`, `schema_version`, `spec_uri` | source-format identity and adapter configuration | fixed mapping metadata | Require exact PAM v1.0. Do not fetch an untrusted schema URI during parsing. |
| `export_id` | source-native correlation value | new PAM export ID | Do not reuse as an OCP record, subject, or package alias. |
| `exported_by` | source-authority claim and runtime label input | exporter label | A product label is not authenticated actor identity. Record verified transport/signature identity separately. |
| `export_date` | claimed export time | PAM export time | Keep distinct from OCP `observed_at`, `acquired_at`, and record `created_at`. |
| `owner.id` | candidate source subject | authorized export subject alias | Does not prove authorizer, account holder, controller, or authenticated principal. |
| `owner.did` | identity-evidence reference under a profile | only with explicit identity-disclosure approval | Globally correlatable; omit by default. Resolution is not authorization. |
| `memories[]` | source records plus zero-or-more candidates | authorized deterministic renderings | Field mapping appears below. |
| `relations[]` | quarantined relation source or registered lineage/evidence profile | selected relationship projection | Core OCP has no generic relation record; preserve direction and endpoint mapping explicitly. |
| conversation index/files | Conversation/Message Profile source objects | profile export | Preserve branch/part order where supported. Derived-memory links remain advisory evidence. |
| embeddings | omit by default or quarantine under a registered profile | no core source | Model-specific, correlation-prone, and non-authoritative. Never index or disclose merely because present. |
| root `integrity` | verification evidence about its precisely covered PAM view | recomputed PAM integrity | PAM coverage is not an OCP record/package digest. Record the exact covered projection. |
| `signature` | imported verification evidence | PAM signature only under an executable profile | Valid signature does not prove truth, ownership, acceptance, or permission. |
| incremental export metadata | import reconstruction metadata | PAM delta under an explicit export policy | PAM ID-based updates reconstruct PAM source state; they never overwrite accepted OCP state. |
| `type_registry` | source-vocabulary reference | pinned PAM registry reference | Unknown types stay inert/quarantined; no heuristic conversion. |

## 6. PAM memory-field mapping

| PAM memory field | `P→O` mapping | `O→P` mapping | Required rule |
|---|---|---|---|
| `id` | private source-native identifier on/behind `source_record` | export-local PAM ID | Generate independent OCP IDs; preserve a provider-side map. |
| `type`, `custom_type` | input to an explicit category/predicate map | declared reverse map | PAM type is not an OCP predicate or epistemic basis. Unknown values are quarantined or loss-reported. |
| `content` | exact source content; optionally parsed into `statement` | deterministic rendering of typed statement | Parsing/rendering is lossy. Retain source and adapter version. |
| `content_hash` | PAM-specific hash result | recomputed from emitted PAM content | Its normalization differs from OCP RFC 8785 record digests. Never copy between fields. |
| creation/update times | source-claimed times | closest compatible PAM times | Never replace OCP immutable revision semantics. |
| validity times | `context_item.validity` where semantics match | direct where compatible | Preserve absence/unknown; do not synthesize from export time. |
| `superseded_by` | candidate relation after reference validation | mapped export-local ID | Does not authorize accepted-state supersession. |
| `status` | imported lifecycle hint | compatible lifecycle projection | PAM `active` maps to an active candidate record, never accepted review state. |
| `summary` | source rendering or separately derived candidate | deterministic optional summary | Record provenance; do not replace original content. |
| `tags` | profile vocabulary or opaque metadata | mapped tags only under a declared vocabulary | No core OCP semantics are inferred. |
| `confidence` | optional calibrated-profile input | omit unless scales are explicitly compatible | Core OCP has no universal confidence scalar; never use for acceptance or authorization. |
| `access.visibility` | source-stated upper-bound constraint | current export policy only | Too coarse for OCP purpose, recipient, time, view, processing, and retention. |
| `access.exportable` | hard negative source constraint | derive from current OCP policy | `false` blocks export; `true` does not authorize a recipient or purpose. |
| `access.shared_with[]` | source permission evidence only | do not derive from OCP receipt | Never maps to a receipt, token, proposal right, or action authority. |
| `provenance.platform` | `source_record.source_authority` label input | mapped product label | Authentication evidence remains separate. |
| platform user ID | private source metadata or omit | only with explicit identity approval | High correlation risk; never use as package alias. |
| conversation/message refs | exact source reference after validation | profile-local references | Preserve unresolved state; do not invent evidence. |
| extraction method | OCP provenance method plus `epistemic_basis` routing | compatible value | Inference maps at most to `provider_inferred`; explicit input may map to `subject_asserted`, not `subject_confirmed`. |
| extraction time | derivation/acquisition time | compatible time | Keep distinct from observation and record creation. |
| extractor | `runtime_source.actor`/software label input | adapter/runtime label | Unverified unless separate evidence exists. |
| language | typed string language or profile metadata | compatible BCP 47 tag | Validate under the target profile. |
| domain | context-space label hint | lossy label | Does not preserve a `context_space` snapshot or authority boundary. |
| arbitrary metadata | inert extension/source data | registered extension only | Unknown data is not rendered, indexed, disclosed, or model-consumed. |

## 7. PAM type routing to OCP 0.4

The table is a conservative routing hint, not automatic semantic conversion.

| PAM type | Candidate OCP 0.4 category | Default epistemic basis | Constraint |
|---|---|---|---|
| `fact` | `statement` | `imported_unclassified` | Truth and acceptance remain unresolved. |
| `preference` | `behavior_preference` or `statement` | `subject_asserted` only with attributable subject input; otherwise `provider_interpreted` | Always `instruction_treatment: "untrusted_data"`. |
| `skill` | `statement` | `subject_asserted` or `provider_interpreted` | Independent attestation requires a credential profile. |
| `context` | `note` or `statement` | `imported_unclassified` | Do not create a space from prose alone. |
| `relationship` | `statement` | `third_party_asserted` or `imported_unclassified` | Third-party and multi-party rules apply. |
| `goal` | `goal` | attributable basis | A goal never authorizes execution. |
| `instruction` | `behavior_preference` at most | attributable basis or `imported_unclassified` | Never enter system/developer/tool instructions or authorization policy. |
| `identity` | `statement` | attributable basis | Sensitive identity rules and credential separation apply. |
| `environment` | `statement` or `note` | attributable basis | Minimize security-sensitive configuration. |
| `project` | `note`, `goal`, or `statement` | mapping-dependent | One memory may split into several candidates. |
| `custom` | profile-defined or quarantine | `imported_unclassified` | Preserve `custom_type`; never guess. |

## 8. Lifecycle mapping

PAM memory lifecycle, OCP record lifecycle, and OCP review state are separate axes.

| PAM state/event | OCP record lifecycle candidate | OCP review state | Required handling |
|---|---|---|---|
| absent / `active` | `active` | `candidate` at most | Current in the source does not mean accepted. |
| `superseded` | `superseded` after reference validation | no automatic change | Accepted replacement/supersession still requires proposal and accepting decision. |
| `deprecated` | active plus a warning/profile value | unchanged/candidate | No exact core state; report approximation. |
| `retracted` | withdrawal evidence; possibly `withdrawn` after authorized processing | no automatic accepted withdrawal | Authenticate authority and review any accepted-state change. |
| `archived` | source/profile metadata | none | Exclude from current-purpose packages unless policy explicitly permits historical use. |
| incremental insert/update | new source/import revision | candidate | Never overwrite an accepted revision. |
| incremental retraction | retraction evidence | profile-defined withdrawal/retraction processing only | Baseline proposals do not include withdrawal. Preserve history; do not silently delete, and require a registered operation-specific decision/tombstone profile before changing accepted state. |

## 9. Coverage of the nine OCP core records

| OCP 0.4 record | Closest PAM material | Coverage | Mandatory loss statement |
|---|---|---|---|
| `context_space` | owner and domain metadata | weak, lossy | Subjects, exact space snapshot, authority model, policy, and lifecycle are absent. |
| `source_record` | PAM export/memory/provenance | strongest | OCP source authority/runtime source separation, instruction treatment, sensitivity, availability, and exact acquisition roles require additions. |
| `context_item` | memory object | partial, lossy | Structured predicate/value, epistemic basis, accepting decision, accepted scope, sensitivity, and exact provenance differ or are absent. |
| `client_declaration` | none | none | Delivery client/instance, processors, supported retention/uses/offline/proposals, deletion support, contacts, expiry, and assurance are absent. |
| `context_request` | access metadata only as a source constraint | none semantically | Purpose object, exact selectors, views, delivery recipient, processors, time, retention, uses, proposal rights, delegation, and offline request are absent. |
| `grant_receipt` | `shared_with` only as source evidence | none semantically | No exact request snapshot, live status, typed containment, authorization decision, client instance, processor set, or revocation state. |
| `context_package` | root export | weak transfer analogue | No active-receipt binding, one delivery recipient, processor set, package-local aliases, layer/view separation, time/use/retention, omissions, or no-action field. |
| `update_proposal` | incremental memory operation | none semantically | No exact receipt/live status, bounded proposal right, exact `target_ref`, submitter authority, or inert review state. |
| `review_decision` | none | none | No reviewer authority, outcome, exact proposal snapshot, accepted-result semantic/scope commitment, or resulting-item linkage. |

## 10. Recipient, authorization, and control-channel boundary

- PAM source access fields constrain import/export but never create OCP authority.
- An OCP request must bind the exact current `client_declaration` and remain within its processor and supported-mode declarations.
- A new deployment authorization decision produces a non-secret `grant_receipt`. Neither PAM nor the receipt is a bearer credential.
- A runtime package is built only from the exact active receipt, one authenticated delivery recipient/client instance, every approved plaintext processor, current policy, and authorized accepted items.
- PAM `instruction` and every other imported string remain inert data. They MUST NOT influence system/developer instructions, tool policy, credential selection, authorization comparison, review outcome, or action execution.
- Signatures and authenticated transport establish only the relationship their selected profile actually verifies. They do not establish semantic truth or acceptance.

## 11. Deterministic `P→O` algorithm

1. Parse raw PAM bytes in quarantine with duplicate-member rejection, byte/depth/count limits, pinned PAM v1.0 schemas, and no network schema resolution.
2. Validate schema and references; verify each content hash, root integrity view, and supported signature separately. Record exact covered bytes/projection, result, verifier, time, and limitations.
3. Create source artifact/record representations with separate `source_authority`, `runtime_source`, acquisition time, source identifiers, and `instruction_treatment: "untrusted_data"`.
4. Preserve unknown custom types, metadata, relations, companion files, and verification failures as inert source material. Do not render or index them by default.
5. Apply only a versioned deterministic mapping table. Each memory produces zero, one, or more candidate context items; every candidate cites an exact source snapshot and adapter version.
6. Set `review.status` to `candidate`. Set `epistemic_basis` from attributable evidence, otherwise `imported_unclassified`; never synthesize `subject_confirmed`, credential verification, or acceptance.
7. Route any desired accepted-state change through `update_proposal` and an authorized accepting `review_decision` that commits to the resulting item semantics and exact accepted scope.
8. Emit a machine-readable import report for every source path: mapped, preserved, quarantined, omitted, unsupported, or failed.

## 12. Deterministic `O→P` algorithm

1. Require a current OCP request, deployment authorization, exact active receipt, verified delivery recipient/client instance, purpose, selected views, and export/transfer policy.
2. Select only authorized layers/items. Apply pairwise/export-local identifiers; never expose store-internal or runtime-package aliases as universal identities.
3. Refuse a lossless claim when selected OCP semantics lack PAM representation and no registered sidecar preserves them.
4. Render structured values deterministically. Record vocabulary, adapter, rendering, split/merge behavior, and information loss.
5. Map record lifecycle only through the table above. Never encode acceptance merely as PAM `active`; preserve decision and accepted scope in a sidecar or report their loss.
6. Compute PAM content hashes, integrity, and any signature over the emitted PAM representation. Never copy OCP snapshot/package digests into PAM checksum fields.
7. Exclude credentials, tokens, evidence bodies, private keys, high-correlation IDs, and unknown extensions unless the exact export decision permits them.
8. Validate the completed PAM document and loss report before delivery.

## 13. Required loss report

Every conversion run claiming this mapping records:

- exact source and target versions/schemas;
- adapter identifier, version, and implementation digest where available;
- direction, time, source count, and target count;
- per-path disposition: `exact`, `normalized`, `split`, `merged`, `rendered`, `preserved_opaque`, `quarantined`, `omitted_by_policy`, `unsupported`, or `failed`;
- produced target references;
- identifier transformation and residual correlation exposure;
- source-authority/runtime-source and provenance retention;
- epistemic-basis and lifecycle approximation;
- review-decision and accepted-scope preservation/loss;
- client/request/receipt/package/proposal semantics preserved only by a sidecar;
- integrity/signature coverage differences;
- unknown-extension handling;
- warnings, blocking errors, and unresolved references.

## 14. Round-trip acceptance criteria

An A→B→A comparison MUST evaluate OCP semantics, not merely text equality. At minimum it checks:

1. source records and exact provenance mappings;
2. typed statements, categories, and epistemic bases;
3. subjects under the declared identifier transformation;
4. record lifecycle and source retraction/supersession evidence;
5. accepting decisions and accepted scopes when a sidecar claims preservation;
6. unknown non-critical extensions or explicit losses;
7. unsupported/critical-data failure behavior;
8. absence of tokens, credentials, stable runtime IDs, and action authority;
9. deterministic loss reports; and
10. package-local/pairwise aliases differing across delivery recipients, instances, and rotation epochs.

If PAM alone is used, the comparator MUST report the unavailable OCP records and semantics. It MUST NOT promote a textual reconstruction to accepted-state equivalence.

## 15. Required fixtures before registration

1. Minimal PAM memory → exact source record + candidate item.
2. PAM `active` proving no OCP acceptance.
3. PAM `instruction` proving `behavior_preference`/quarantine and no privileged-channel insertion.
4. `shared_with: write/delete` proving no receipt, proposal right, or action authority.
5. `llm_inference` proving `provider_inferred` candidate state, never subject confirmation.
6. Multi-subject relationship quarantined without an authority profile.
7. PAM content-hash versus OCP RFC 8785 snapshot-digest difference.
8. Signed PAM with signature result separated from truth, acceptance, and authorization.
9. Incremental update/retraction proving no direct accepted write.
10. Unknown custom type/metadata proving inert preservation and loss reporting.
11. Exact declaration/request mutation showing an undeclared processor fails.
12. OCP accepted item export showing explicit decision/scope loss without a sidecar.
13. Exact `target_ref` proposal mapping showing PAM incremental update is insufficient.
14. Two-recipient export showing pairwise/package-local identifier separation.
15. A→B→A run with deterministic, byte-verifiable loss report.

## 16. Open mapping decisions

- Whether one registered PAM sidecar should preserve OCP spaces, exact references, review decisions/scopes, receipts, proposals, packages, and losses, or whether those remain in a separate OCP transfer bundle.
- Whether PAM signature semantics can become an OCP import-verification profile after independent vectors and complete issuer/key/status rules exist.
- Whether a shared predicate/type vocabulary can map natural-language PAM types without heuristic or model-defined semantics.
- Whether PAM owner identity can be used without defeating OCP pairwise/package-local identifier defaults.
- How a future PAM version changes review, scope, purpose, processing, and instruction-safety semantics. Any later version requires a new version-pinned mapping and re-audit.
