# OCP Next-Release Architecture Review

> **Historical design record.** This analysis was written against the then-current OCP 0.2 review snapshot. OCP 0.4 now supersedes that implementation-facing baseline; “current” below means current at the time of this review unless a passage explicitly discusses 0.4.

**Purpose:** Normalize the substantive proposals in reviewer inputs 1 and 2, compare them with the current `0.2-review-draft`, resolve conflicts, and recommend the architecture and version posture for the next authoritative project draft.

**Status:** Architecture recommendation for the lead editor. This file does not modify or supersede the current specification.

## 1. Evidence and weighting

Reviewed in full:

- `pasted-text-1.txt` (`R1`): logical review input `INPUT-1` in `review/source-feedback-manifest.json`, identified by its SHA-256 digest.
- `pasted-text-2.txt` (`R2`): logical review input `INPUT-2` in `review/source-feedback-manifest.json`, identified by its SHA-256 digest.
- Current specification at review time (`B0`): historical project path `deliverables/OCP-v0.2-Review-Draft.md`; this baseline is not redistributed in the 0.4 package.
- Companion pack overview and schema inventory at review time (`P0`): historical project path `deliverables/OCP-Schema-and-Conformance-Pack/README.md`, plus its `schemas/`, `profiles/`, `offline/`, and `adapters/` content; that baseline is not redistributed here.

Evidence weight is intentionally asymmetric:

1. `B0` and `P0` are the current implementation-facing baseline.
2. `R1` and `R2` are proposal sources. Both disclose that they did not have the complete original working draft and reconstructed it from a cover or assignment summary. Their claims about defects in the unseen original are not evidence of defects in `B0`.
3. `R2` is a concatenation of at least two incompatible revision attempts. Its early “slim accepted-context” design and later “expanded domain-object” design are treated separately as `R2-A` and `R2-B`.

The review therefore asks whether each proposal improves the current baseline, not whether the reviewers declared it “applied.”

## 2. Executive recommendation

The next project-authoritative draft should be **OCP 0.4 — Consolidated Editor’s Working Draft**, with **wire version `0.4`** only if the recommended breaking classification and schema changes are adopted. It should be authoritative only in the repository sense—“the current project draft until superseded”—and must remain explicitly **not an adopted standard, interoperability claim, security certification, or production recommendation**.

The architecture should retain the current narrow center:

- scoped accepted context, not universal identity or “portable self”;
- evidence and provider interpretation distinct from reviewed acceptance;
- client declaration → request → external authorization → non-secret receipt → minimized package;
- proposal → immutable review decision → new accepted revision;
- untrusted-data isolation and `external_action_authority: "none"`;
- loss-aware import/export and honest revocation/erasure language; and
- external standards for identity, authorization, transport, cryptography, credentials, provenance, and agent execution.

The current nine core record types are substantially the right set. The next draft should **not** add Artifact, Conversation, Message, Interaction Signal, Credential, Erasure Status, Stewardship, Capability, Provider Mapping, Agent Delegation, or organization objects to the semantic core. It should instead make the suite taxonomy precise:

1. **Core semantic records** — stable meaning and accepted-state governance.
2. **Protocol bindings** — HTTP/OAuth, local broker, offline archive, and transfer mechanics.
3. **Domain profiles** — conversation, artifact/lineage, work context, credentials, organization, multi-party authority.
4. **Security profiles** — remote package authenticity/confidentiality and offline package protection.
5. **Adjacent-standard mappings** — PAM, PROV, MCP, A2A, C2PA, VC, Solid.
6. **Conformance classes** — actor-specific claims and evidence; not profiles and not implementation marketing tiers.

The largest architectural correction is classification, not wholesale reinvention. `B0` currently says the core has nine record types, but the pack places `transfer-manifest.schema.json` in `schemas/`, the pack README calls that directory “eleven ... core schemas,” and Section 12.11 calls transfer a profile object. That ambiguity should be eliminated before another version is called authoritative.

## 3. Target architecture

```mermaid
flowchart TB
    AUTH["External trust and authorization\nOIDC, OAuth/RAR, GNAP, OS policy"]
    CORE["OCP Core semantics\nspace, source, item, declaration, request, receipt, package, proposal, decision"]
    BIND["Bindings\nremote HTTP, local broker, offline archive, transfer"]
    PROF["Domain profiles\nconversation, artifact, work, credential, organization, multi-party"]
    SEC["Security profiles\nremote package and offline protection"]
    MAP["Mappings\nPAM, PROV, MCP, A2A, C2PA, VC, Solid"]
    CONF["Conformance\nrole-specific assertions and evidence"]

    AUTH --> CORE
    CORE --> BIND
    CORE --> PROF
    BIND --> SEC
    CORE --> MAP
    BIND --> CONF
    PROF --> CONF
    SEC --> CONF
```

### 3.1 Architectural invariants

The next release should promote the following to concise, immutable architecture decision records and normative assertions:

1. **Observe and present; do not execute.** OCP may preserve observable continuity state and present context, but it never executes business logic or grants action authority.
2. **Acceptance is a governance dimension, not an epistemic origin.** A provider inference can be reviewed and accepted for a scope without becoming a subject assertion or objective truth.
3. **Evidence, interpretation, and acceptance are not object-store aliases.** Transformations between them are explicit, immutable, and linked to source and decision records.
4. **Authorization remains external and operation-time.** A request, receipt, signature, package ID, or record ID is never sufficient authority.
5. **Runtime presentation and durable transfer are different products.** Runtime packages are minimized and audience-pairwise; transfer packages are user-directed, quarantined, loss-reported, and independently protected.
6. **Identifiers have domains.** Store IDs, export IDs, and audience/package aliases are distinct. Runtime recipients do not receive stable store IDs by default.
7. **Context is always data.** It never enters instruction, policy, credential-selection, or tool-authorization channels.
8. **A source locator is not preservation.** Custody and verification claims require a profile and evidence.
9. **Revocation, retention expiry, deletion report, cryptographic erasure, and independent verification remain separate claims.**
10. **Unknown semantics fail closed for use and survive or appear in a loss report for transfer.**

### 3.2 Recommended core record set

The common envelope is a schema family, not a concrete record type. The recommended concrete core records remain:

| Record | Core reason | Recommended change from `B0` |
|---|---|---|
| `context_space` | Scope and authority evaluation boundary | Keep. Structurally allow non-personal domains only when the selected authority profile is declared; Core Personal conformance remains `authority_model: self`. |
| `source_record` | Evidence origin, acquisition, trust, availability, and untrusted treatment | Keep. Preserve source authority/provenance separately from runtime presentation source; neither implies review or action authority. |
| `context_item` | One portable typed statement with epistemic basis, review state, provenance, sensitivity, and lifecycle | Keep one type. Rename/clarify `assertion_kind` as epistemic basis if useful. Do not create separate `AcceptedClaim` and `InterpretationRecord` wire types. |
| `client_declaration` | Required input to meaningful review and recipient assurance labeling | Keep. Declarations remain claims about behavior, not proof of compliance. |
| `context_request` | Inert structured request across purpose, selectors/views, audience, time, uses, retention, proposals, delegation, and offline use | Keep. |
| `grant_receipt` | Non-secret record of the effective decision linked to a real authorization | Keep. Never contain a token or operate as a credential. |
| `context_package` | Immutable, minimized, purpose/audience/time-bound presentation | Keep. Runtime and transfer packages remain distinct. |
| `update_proposal` | Inert client proposal with optimistic concurrency | Keep. |
| `review_decision` | Immutable authority/review evidence that can produce a new accepted revision | Keep. |

#### Context-item refinement

`B0` correctly keeps epistemic origin (`assertion_kind`) separate from review status. `R2-A` would split accepted claims and interpretations into different object types; that makes forbidden combinations easier to prevent, but it also conflates “where this came from” with “what a reviewer decided” and creates record duplication when a candidate is accepted.

Keep one `context_item`, but tighten its combination matrix:

- baseline `review.status` is candidate / accepted; dispute/reaffirmation requires a registered typed-decision profile, while superseded / withdrawn / tombstoned belong only to record lifecycle.
- epistemic basis is subject asserted, subject confirmed, provider observed, provider inferred/interpreted, third-party asserted, credential-derived, imported-unclassified, or profile-defined.
- `accepted` always requires immutable decision and accepted scope.
- acceptance never rewrites epistemic basis.
- `subject_confirmed` requires subject/reviewer evidence and cannot be synthesized from model output.

The current `kind` enum (`assertion`, `instruction`, `goal`, `decision`, `note`) is too close to a domain ontology without defining those domain lifecycles. For wire `0.4`, either:

1. narrow core `kind` to a generic statement/assertion and move instruction/goal/decision semantics to a Work Context Profile; or
2. keep the labels explicitly as non-semantic presentation categories and require a profile URI/schema for any behavior beyond selection/display.

Option 1 is architecturally cleaner and is recommended if a wire-version change is already being made.

### 3.3 Things that should not become core records

| Candidate | Decision | Placement |
|---|---|---|
| `Artifact` / `ArtifactManifest` | Reject as core | Artifact and Lineage Profile; only references/evidence hooks in core. |
| `Conversation` / `Message` | Reject as core | Conversation Profile. Preserve branching; imported roles remain untrusted labels. |
| `InteractionSignal` | Reject as core | Source/event evidence or a domain profile. Do not turn telemetry into personal context. |
| `Goal`, `Decision`, `Instruction` | Modify | Work Context Profile if they require portable semantics; generic statement may remain core. |
| `Credential` | Reject as core | Credential Evidence Profile referencing VC/SD-JWT/native credentials. |
| `ErasureRecord` | Reject as core | Erasure Status Profile. Core owns receipt revocation semantics and bounded language only. |
| `StewardshipRecord` | Defer | Multi-party Authority Profile. Self-authorized personal core does not need a universal guardianship model. |
| `AgentDelegationRecord` | Defer | Delegation Profile only after independent authorization/attenuation prototypes. Baseline remains exactly `none`. |
| `OrganizationalSpace` | Reject as separate core type | Organization Authority/Custody Profile extending `context_space`. |
| `CapabilityDocument` | Reject as persistent core record | Binding-native discovery metadata. |
| `ProviderMapping` | Reject as general core record | Import Adapter Profile output/report and conformance fixture. |
| `RedactionRecord` | Defer as standalone type | Core package omissions and source redaction state are enough until a profile proves a portable record is necessary. |
| HIC/runtime continuity state | Reject as core execution layer | Optional observe-only runtime/binding profile; cannot grant authority or silently mutate accepted state. |

### 3.4 Binding/profile/mapping taxonomy

The next draft should stop using “profile” for every optional artifact.

#### Bindings

- **Remote HTTP Binding:** resource model, media types, idempotency, ETags, errors, discovery.
- **OAuth/RAR Authorization Binding:** typed authorization details, exact resource/client-instance binding, partial approval, revocation coordination.
- **Local Broker Binding:** authenticated local IPC/OS broker behavior; localhost alone never sufficient.
- **Offline Archive Binding:** manifest and archive safety. It is a serialization/transport binding, not a domain profile.
- **Transfer Binding:** source/destination lifecycle, entry results, receipts, retries, and source disposition.

#### Security profiles

- **Remote Package Security Profile:** issuer authenticity, recipient confidentiality, client-instance key binding, signed/protected fields, algorithms, trust, discovery/status/rotation, downgrade behavior, and negative vectors.
- **Offline Package Protection Profile:** durable manifest authenticity and recipient-controlled encryption, with wrong-recipient/tamper/downgrade vectors.

Until those exist and are executed, `SEC-001`, `SEC-002`, and `XFR-004` must remain unavailable exactly as `P0` currently states. A digest is not authentication. TLS is not offline recipient binding. `R1`’s blanket “signature required” language should not be adopted without selecting and testing the actual profile.

#### Domain profiles

- Conversation/Message
- Artifact/Lineage, including C2PA mapping
- Work Context (goal, decision, instruction, constraint)
- Credential Evidence
- Organization Authority/Custody
- Household/Joint Context
- Minors/Guardians
- Delegation/Agent Chain
- Live Sync/Multi-writer
- Erasure Status

#### Mappings

Mappings are neither profiles nor bindings. The highest priority is a field-level, lifecycle-level, loss-aware **PAM v1.0 mapping**. PROV, MCP, A2A, C2PA, VC/SD-JWT, Solid, and privacy-vocabulary mappings follow. Each mapping needs exact source version, cardinality, proof/authority boundary, unknown-data behavior, negative fixtures, and round-trip acceptance criteria.

### 3.5 Transfer placement decision

`B0` and `P0` disagree structurally:

- Section 9.4 lists nine core objects and omits `transfer_manifest`.
- Section 12.11 calls it a profile object.
- The pack stores it under `schemas/`, while profile objects live under `profiles/`.
- The pack README describes `schemas/` as eleven core schemas.

Recommended resolution:

- Keep **loss-aware export invariants** normative in Core.
- Put `transfer_manifest` and the transfer lifecycle in a **Transfer Binding/Profile package**, not in the nine-record semantic core.
- Move its schema to a clearly named location such as `bindings/transfer/` or `profiles/transfer/`.
- Require the Transfer Binding for a **Portable Provider / Exporter / Importer** conformance claim, but not for a runtime-only Core Client claim.
- If the project wants every “Core Provider” to export, say that explicitly in the conformance class; do not smuggle transfer into core via directory placement.

`offline_package_manifest` is a binding manifest, and `provider_adapter_fixture` is a conformance artifact. Neither should be described as a persistent OCP profile object.

## 4. Normalized reviewer-proposal decisions

The table consolidates repeated proposals. “Accept” means adopt materially as written; “Modify” means retain the objective but use the target architecture above; “Reject” means do not carry it into the next draft; “Defer” means require experiments/profile work first.

| Proposal | R1 | R2 | Current baseline | Decision | Architectural disposition |
|---|---|---|---|---|---|
| Narrow OCP to portable, reviewed, purpose-bound context | Strong | Strong | Implemented | **Accept** | Keep as the primary boundary. |
| Rename protocol status from “canonical context” to “accepted context” | Retain but redefine | Strong rename | Implemented/deprecated alias | **Accept** | “Canonical” only for deterministic bytes. |
| Preserve evidence → provider interpretation → accepted context separation | Strong | Strong | Implemented | **Accept** | Make the two independent axes (epistemic basis and review state) explicit. |
| External authorization; OCP receipt is not a token | Partial; incorrectly suggests token-response URI reference | Strong | Implemented | **Modify** | Keep non-secret receipt and operation-time authorization; never reference or embed token responses as though they were durable URIs. |
| Require `ClientDeclaration` | Strong | Strong | Implemented | **Accept** | Keep core, assurance-labeled, exact declaration reviewed. |
| Split accepted claim and interpretation into separate record types | No | `R2-A` yes | One `context_item` | **Reject** | One item with independent epistemic/review dimensions is less duplicative and more precise. |
| Make Artifact a core object | Yes | No in `R2-A`; yes/unclear later | Profile | **Reject** | Core source references plus Artifact/Lineage Profile. |
| Make Conversation/Message core | No | `R2-A` profile; `R2-B` core | Profile | **Reject** | Conversation remains profile. |
| Add `InteractionSignal` to core | Yes | Remove/profile | Absent | **Reject** | Telemetry/event evidence is not the portable semantic core. |
| Add StewardshipRecord to core | No | `R2-A` yes | Authority fields in space/decision | **Defer** | Required only with multi-party authority profile. |
| Add CapabilityDocument to core | No | `R2-A` yes | Discovery metadata | **Reject** | Binding-native discovery document, not a persistent record. |
| Add ProviderMapping and RedactionRecord to core | No | `R2-A` yes | Adapter fixture + omissions/redaction fields | **Modify** | Keep as profile/report structures unless prototypes prove standalone records are necessary. |
| Keep transfer manifest in core | Yes | Mixed | Ambiguous | **Modify** | Core export invariants; separate Transfer Binding schema and conformance claim. |
| Keep erasure record in core | Yes | Mixed | Erasure Status Profile | **Reject** | Revocation core; erasure evidence/profile separate. |
| Pairwise subject identifiers | Recommended | Strong | Implemented at package boundary | **Accept with refinement** | Stable store/export IDs and audience/package aliases must be separate domains. |
| Preserve subject IDs unchanged across round trips | Implied | Conflicts with pairwise model | Loss-aware mappings | **Modify** | Preserve semantic identity mapping, not necessarily the same disclosed ID. Export may preserve opaque continuity IDs under explicit scope; runtime presentation must alias. |
| Typed predicate/value claim model | Strong | Strong | Implemented | **Accept** | URI predicate + typed value + profile schema; no LLM-defined wire semantics. |
| Universal claim-type registry in core | Implicit small vocabulary | `R2-A` small registry | URI predicates/profile schemas | **Modify** | Registry governs stable identifiers, not a universal person ontology. Domain semantics live in profiles. |
| Full W3C PROV fields required on every object | R1 strong | R2 minimal mapping | Minimal OCP provenance + mapping | **Modify** | Keep minimal required provenance and publish PROV mapping; do not import full PROV graph complexity into core. |
| Mandatory signature on every package | Strong | Mixed | Digest core; security profile required for remote non-public | **Reject as core** | Require registered security profile for claimable remote/offline protection. |
| Mandatory JWE or `age` for sensitive content | R1 | JOSE/COSE guidance | No selected profile; classes unavailable | **Defer** | Select suites in security profiles with vectors, not prose-only algorithm names. |
| DPoP-style recipient binding as package field | R1 | R2 token/security guidance | Client-instance binding required by future profile | **Modify** | DPoP constrains OAuth tokens; package recipient confidentiality/authenticity needs a separate key-binding profile. Do not conflate them. |
| HTTP binding and media types | Strong | Strong | Implemented provisionally | **Accept with maturity caveat** | Keep a binding document; do not claim IANA registration. |
| Offline ZIP package | Strong | Strong | Implemented structurally | **Accept as binding** | Archive safety is present; cryptographic protection remains unavailable until registered/tested. |
| Proposal/review; no silent write | Strong | Strong | Implemented | **Accept** | Immutable proposal and decision; new revision on acceptance. |
| Automatic low-risk acceptance | R1 optional future profile | `R2-A` off; `R2-B` allows | Deferred profile | **Defer** | No core auto-accept. Prototype an Auto-Review Profile only with strict exclusions and reversal/audit. |
| Package “consumed/retained/destroyed” lifecycle | R1/R2 | Strong | Provider-visible built/available/delivered/expired/invalidated | **Reject as authoritative core state** | Recipient behavior is declared/attested/audited evidence, not a provider-known package state. |
| Prompt-injection and parser containment | Strong | Strong | Implemented | **Accept** | Keep data/control separation and sandbox requirements; conformance needs deployed boundary tests. |
| Package no-forwarding | Strong | Strong | Baseline delegation none | **Accept with evidence boundary** | It is a recipient obligation unless cryptographically recipient-bound; never market it as physical plaintext prevention. |
| Third-party default restriction | Strong | Strong | Personal core excludes high-risk third-party content | **Accept** | Multi-party/joint-data profile required for more. |
| Organizational context in a profile | Strong | Strong | Implemented as boundary/profile requirement | **Accept** | Organizational policy and custody remain outside personal core. |
| Extension preservation and fail-closed critical semantics | Partial | Strong | Implemented | **Accept** | Preserve/loss-report unknown non-critical data; reject critical unknowns. |
| Conformance harness and negative fixtures | Strong | Strong | Implemented locally | **Accept** | Preserve evidence limits; add independent implementation tests. |
| Neutral governance and no KnowOnce dependency | Strong | Strong | Implemented as draft posture | **Accept** | Governance must exist operationally before stable release. |
| Publish immediately as a credible implementable 0.2 | R1 conditional | R2 review-draft only | Current status already 0.2 review draft | **Reject as next-version posture** | Next draft is 0.4 only after consolidating classifications; no production/interoperability claim. |
| Treat PAM as merely early research / low overlap | R1 | R2 initially uncertain | Current spec recognizes PAM v1.0 as closest overlap | **Reject** | PAM mapping is a first-order exit criterion. Re-verify the source/version at release. |
| Build OCP agent identity/delegation runtime | Warned against, but profile proposed | Warned against | Deferred | **Reject for core / defer profile** | Reuse MCP/A2A/identity/authorization; OCP supplies governed context only. |

## 5. Conflicts that must be resolved explicitly

### 5.1 The reviewer inputs were not audits of the current artifact

Both reviewer documents say the actual specification body was unavailable. Their reconstructed schemas include examples that claim validation without supplied validation evidence and, in places, contain incompatible or incomplete constraints. The next editor should not reintroduce fields merely because a reviewer marked “Applied: Yes.” Only the proposal’s rationale should be carried forward.

### 5.2 `R2` contains two incompatible target models

`R2-A` proposes a slim accepted-context design, separate `AcceptedClaim`/`InterpretationRecord`, and Conversation/Message/Artifact outside core. `R2-B` later makes Conversation and Message first-class, introduces `ConflictSet`, expands domain objects, and permits a low-risk automatic-acceptance path. These are alternatives, not cumulative requirements. Adopt the slim boundary but keep `B0`’s single context-item representation.

### 5.3 “Small core” versus object-count inflation

`R1` calls for a bounded core while listing roughly twelve core objects. `R2-A` calls for an “8-object core” and later lists fourteen to sixteen. Count alone is not the issue; the issue is whether an object defines an invariant every conforming implementation needs. Conversation, artifact custody, erasure assurance, provider mappings, guardianship, and capability discovery do not meet that test.

### 5.4 Authorization receipt versus token binding

`R1` correctly separates authorization but then suggests that `authorization_ref` point to a token-endpoint response URI and that package recipient binding use DPoP-like token fields. That conflates three boundaries:

- authorization decision evidence;
- access-token/client-instance proof; and
- package issuer authenticity and recipient confidentiality.

The next draft must keep all three explicit. The receipt references a decision or protected server-side record. OAuth credentials authorize each protected operation. A registered package-security profile protects bytes and recipient keys.

### 5.5 Stable portability identifiers versus runtime privacy aliases

Review proposals variously require preserving `subject_ref` across round trips and rotating/pairwise identifiers. Both can be true only if identifier domains are defined. The next draft should specify:

- store-internal IDs: stable within provider, never disclosed by default;
- export/continuity IDs: opaque and scoped to a user-directed transfer, with mapping/loss report;
- runtime aliases: audience-pairwise or package-local; and
- profile identifiers: governed URIs for schemas/predicates, not people.

### 5.6 Signature/encryption requirements versus unavailable profiles

`R1` says every package must carry a signature and sensitive packages must use JWE or `age`. `P0` correctly marks Remote Security and offline-transfer protection unavailable because no registered profile or vectors exist. The next release must choose one of two honest paths:

1. ship and execute concrete profiles with positive/negative vectors; or
2. retain the unavailable claims and label examples structural only.

It must not copy algorithm names into core and imply security exists.

### 5.7 Transfer is central but not necessarily core

OCP’s mission requires loss-aware portability, but the runtime core does not require every client to implement transfer. Treat portability rules as core invariants and transfer mechanics as a required binding for the Portable Provider class. This is clearer than placing one manifest schema in the core directory while calling it a profile in prose.

## 6. Version and release recommendation

### 6.1 Version identity

Recommended labels:

- **Document title:** `Open Continuity Protocol 0.4 — Consolidated Editor’s Working Draft`
- **Project status:** `Current project-authoritative draft until superseded`
- **Standards status:** `Not an adopted standard; no production, legal, security, or interoperability claim`
- **Wire version:** `0.4` only if core shape/meaning changes (for example narrowing `context_item.kind`, reorganizing transfer classification with schema URI changes, or changing identifier domains)
- **Profile versions:** independent `0.1-draft` or date/version identifiers
- **Registry and assertion versions:** explicit and independently pinned

If the next document changes only prose, directory placement, and non-wire classifications, publish **document version `0.2.1-editor-draft` with wire `0.2`** instead. Do not increment the wire version for editorial consolidation alone.

Do not use `0.9` yet. The current release has no executed Remote Security or offline-protection profile and no demonstrated independent interoperability. A `0.9` label normally signals near-release-candidate stability that the evidence does not support.

### 6.2 Normative-source model

Replace the current total-order “prose, then schemas, then fixtures, then OpenAPI” wording with scoped authority:

- prose owns semantic invariants and actor obligations;
- schemas own representation shape;
- registries own identifiers/enumerations/transitions;
- bindings own transport syntax;
- fixtures/assertions own executable examples and expected behavior;
- a release manifest pins every normative component by URI and digest.

Any cross-component conflict invalidates the affected conformance claim until corrected. No component silently broadens authorization or disclosure.

### 6.3 Suite layout

Recommended source layout:

```text
/spec/core
/bindings/http
/bindings/oauth-rar
/bindings/local-broker
/bindings/offline
/bindings/transfer
/profiles/conversation
/profiles/artifact-lineage
/profiles/erasure-status
/profiles/work-context
/profiles/credential-evidence
/profiles/organization
/profiles/multi-party
/profiles/delegation-experimental
/security/remote-package
/security/offline-package
/mappings/pam
/mappings/prov
/mappings/mcp-a2a
/mappings/c2pa-vc-solid
/schemas/core
/registries
/conformance
/examples
```

A single polished Word/PDF “reader edition” may consolidate these sources, but the modular sources should be authoritative to avoid one 45-section document becoming the only maintainable representation.

### 6.4 Release gates for 0.4

Before calling 0.4 the project-authoritative consolidated draft:

1. Resolve core/binding/profile classification, especially transfer/offline/adapter artifacts.
2. Decide whether `context_item.kind` is generic core or Work Context Profile semantics.
3. Publish the exact PAM v1.0 field/lifecycle/loss map.
4. Define the store/export/runtime identifier-domain rules and pairwise rewrite algorithm.
5. Reconcile spec, schema locations, README inventory, conformance assertions, examples, and OpenAPI under one release manifest.
6. Either publish executable remote/offline security profiles or keep the affected claims unavailable.
7. Preserve current negative-fixture coverage for accepted-state linkage, context/action separation, aliases, archive safety, erasure overclaim, and undeclared offline use.
8. Add architecture-decision records for every rejected reviewer expansion so the debate does not recur silently.

Before any 1.0 or near-RC version:

- at least two genuinely independent providers and one independent client;
- published request/receipt/package/proposal/review interop results;
- A → B → A round-trip with deterministic loss report;
- hostile import and context-to-action containment tests at deployed boundaries;
- concrete security-profile vectors and independent review;
- accessible consent/review human testing;
- neutral governance, stable namespaces, IPR terms, security response, and registry durability.

## 7. Final disposition

The current `0.2-review-draft` already embodies most of the strongest reviewer proposals and is materially more coherent than either reconstructed reviewer specification. The next version should not replace it with either reviewer’s schema family. It should consolidate the current architecture, fix classification inconsistencies, narrow any remaining ontology leakage, formalize the suite taxonomy, add the PAM and security-profile work needed for credible differentiation, and preserve the observe-only/no-action/no-silent-write philosophy.

The recommended target is therefore evolutionary but intentionally breaking where classification and semantics require it: **OCP 0.4 as a modular core plus bindings, profiles, mappings, security profiles, and evidence-scoped conformance—not a larger monolithic “universal memory protocol.”**
