# Migration from OCP 0.2 review draft to 0.4 working draft

OCP 0.4 is wire-breaking. Implementations must parse 0.2 and 0.4 separately; they must not relabel 0.2 bytes as 0.4.

| 0.2 | 0.4 | Required migration behavior |
|---|---|---|
| URI-only request, receipt, proposal, decision, source, and target references | `snapshotRef` | Dereference the exact 0.2 record, validate it, assign its 0.4 schema/revision, compute RFC 8785 SHA-256, and record any unavailable revision as a migration loss. |
| status timestamp embedded in receipt | `liveStatusRef` | Create a distinct current-status endpoint/reference. Do not infer current status from an immutable snapshot. |
| `audience[]` | one `delivery_recipient` | Issue a separate 0.4 request/receipt/package for every independent delivery recipient and instance. |
| `model_providers[]` and `subprocessors[]` | `processing_recipients[]` | Carry every entity expected to receive plaintext, its role, purpose codes, and `receives_plaintext: true`. The delivery recipient separately binds the exact declaration snapshot. Undeclared processing is not migratable as approved. |
| proposal `expected_revision` | exact `target_ref` on revise | Resolve and bind the complete ID, revision, schema URI, and RFC 8785 digest. Create omits a target. Accepted-context withdrawal is profile-gated until an operation-specific decision/result model is registered. |
| `source_provider` | `source_authority` plus `runtime_source` | Preserve the source actor; add the actual importer/adapter/evaluator. If unavailable, downgrade verification claims and emit a loss/warning. |
| `assertion_kind` | `epistemic_basis` | Map by the table below; never change review status during migration. |
| `kind: assertion` | `category: statement` | Direct mapping. |
| `kind: instruction` | `category: behavior_preference` | Always add `instruction_treatment: untrusted_data`; it cannot become prompt/control authority. |
| `kind: goal`, `decision`, or `note` | Work Context Profile or 0.4 category | Use a registered profile when semantics matter; otherwise preserve as inert note data with a loss report. |
| binary `proposal_rights` | bounded `proposalRights` | `none` maps directly. `propose_only` requires explicit operations/selectors or must downgrade to `none`. |
| arbitrary package `content` object | discriminated typed entry | Select layer/disclosure branch, rewrite every internal relationship to package-local aliases, add content schema URI, recompute entry and package digests, and reject or quarantine unknown critical content. |
| package views or entries using `accepted_and_disputed`, `redacted_excerpt`, `selected_full`, `selected_content`, or `content_ref` delivery | closed baseline entries: embedded `accepted` context plus embedded evidence/artifact `metadata` only | This is a breaking narrowing, not a spelling change. Migrate only accepted context that retains its exact decision/scope bindings. Evidence and artifact entries may migrate only to the small embedded core metadata projections and only when their package-local source/artifact, space, and supporting-accepted-item relationships can be proved. Otherwise require an applicable registered profile or omit/quarantine the entry and record the loss; never convert broader content to metadata while implying that its semantics or assurance were preserved. |
| offline `entries[]` plus signature path | payload/security member sets | Separate payload and security members; use the specified signed view and exact-set rule. Old signatures do not become valid 0.4 signatures. |

The baseline package break is intentionally fail-closed. Disputed context, evidence excerpts or full evidence, artifact content, and content-reference delivery are profile-gated in 0.4 even if a 0.2 implementation emitted them. The baseline evidence projection carries only conservative descriptive metadata and the trust labels `unassessed`, `user_supplied`, or `suspected_tampering`; verified trust and proof require a registered profile. The baseline artifact projection omits custody and preservation claims. Neither projection is a complete source/artifact record, an Artifact Profile object, proof of trust or custody, or evidence of Artifact Profile conformance.

## Epistemic basis map

| 0.2 value | 0.4 value |
|---|---|
| `subject_asserted` | `subject_asserted` |
| `subject_confirmed` | `subject_confirmed` |
| `system_observed` | `provider_observed` |
| `system_inferred` | `provider_inferred` |
| `provider_interpreted` | `provider_interpreted` |
| `third_party_asserted` | `third_party_asserted` |
| `credential_attested` | `credential_derived` |
| `imported_unclassified` | `imported_unclassified` |

## v0.9 architectural-proposal map

The 0.9 draft was not a predecessor wire release. Its `ContinuitySnapshot` and `ConditionObservation` map into the optional Continuity Observation Profile; HIC maps into the narrower Human Interaction Boundary Profile; upstream references map into source/provenance/artifact structures; its `ContinuityPackage` maps to offline/transfer bindings and never to a second core runtime package. Universal aggregate, admissibility, and thread semantics are not adopted.

## Migration acceptance

A migration is successful only when the destination validates as 0.4, every preserved field has a documented map, every omitted or transformed field appears in a loss report, internal identifiers do not leak into a runtime package, accepted state retains exact review evidence, and no migrated record acquires more authority, disclosure, processing use, retention, proposal rights, or trust than the source carried.
