# OCP 0.4 executive review summary

Open Continuity Protocol 0.4 is the current project-authoritative working draft. It is not an adopted standard, production recommendation, security certification, legal conclusion, or evidence of interoperability between independent products.

## Independent assessment

**One sentence.** OCP lets a person or authorized steward carry selected, reviewed context between systems as a purpose-bound, provenance-aware package while preventing silent write-back and never treating context as authority to act.

**One paragraph.** OCP addresses the gap between raw provider exports and the narrowly useful, reviewed context another AI system needs. A client declares who will receive plaintext, asks for specific views for a stated purpose, and receives only what a real authorization decision permits. The provider records a non-secret receipt, builds an immutable minimized package for one delivery client instance, and keeps evidence, provider interpretation, and scoped acceptance distinct. A client may propose changes, but an immutable review decision is required before accepted context changes. Import, transfer, revocation, and deletion use loss-aware and evidence-bounded language.

**Primary user problem.** People either repeat themselves across AI products or disclose broad archives that lack purpose, review state, provenance, minimization, and safe write-back semantics.

**Actual protocol boundary.** OCP is a small semantic record and lifecycle protocol with versioned bindings, profiles, mappings, and conformance evidence. It is not authentication, identity proof, access-token issuance, external-action authorization, agent execution, a universal memory ontology, artifact storage, or proof of recipient behavior.

**Sixty-second example.** Avery authorizes a travel assistant to receive one accepted lodging preference for one trip, with no raw messages, training, advertising, delegation, or offline use. The provider creates a receipt linked to the actual authorization and sends a short-lived package for that assistant's exact client instance, disclosing the model processor and using package-local aliases. The preference can improve suggestions but cannot authorize a booking. A newly learned preference returns as a proposal; Avery decides whether it becomes accepted context.

## Verdict

OCP solves a real combined protocol/data-model problem. Portable AI memory formats can move records, OAuth can authorize operations, and agent protocols can carry messages, but those layers do not jointly define scoped acceptance, minimized purpose-bound presentation, proposal/review write-back, evidence separation, loss-aware transfer, and a strict context-versus-action boundary. OCP's genuine whitespace is therefore narrower than “portable AI memory” and credible only if it continues to reuse adjacent standards.

The 0.4 design is suitable for bounded public technical review and implementation experiments. The prose, schemas, OpenAPI description, exact PAM mapping, and local reference evidence have been synchronized and revalidated; publication derivatives still require final-byte rendering and independent release QA before distribution. It is materially implementable at the representation and reference-vector level, but it is not ready for a stable release or broad interoperability claim. The core scope is appropriate; cryptographic profiles, complex authority, delegation, live sync, and domain ontologies remain correctly deferred.

## Scorecard

| Dimension | Score | Explanation |
|---|---:|---|
| Conceptual clarity | 8/10 | The governed-context center, one-sentence explanation, and non-goals are now explicit; the word “continuity” still needs public testing. |
| Problem importance | 9/10 | Repeated context setup and unsafe archive disclosure are durable multi-provider problems. |
| Novelty | 6/10 | Most primitives exist elsewhere; novelty lies in their acceptance/presentation/write-back composition. |
| Differentiation | 7/10 | PAM and other memory work occupy broad interchange; OCP retains defensible narrower whitespace. |
| Protocol coherence | 8/10 | Nine records, clear bindings/profiles, exact references, and lifecycle separation form one coherent system. |
| Schema maturity | 7/10 | The core schemas, fixtures, HTTP binding, and exact informative PAM mapping are synchronized. The canonical `https://opencontinuity.org` working-draft namespace is selected; profile artifacts, archival/redirect governance, public deployment readback, and independent implementations remain incomplete. |
| Implementability | 7/10 | The core is buildable, but remote authorization, parser, and cryptographic profiles still require prototypes. |
| Security | 7/10 | Strong boundaries and conservative defaults exist; executable remote/offline cryptography and deployed adversarial evidence do not. |
| Privacy | 8/10 | Purpose, views, processor disclosure, package-local aliases, minimization, and qualified deletion semantics are strong on paper. |
| Interoperability | 6/10 | Representation and mappings are defined, but no independent exchange has occurred. |
| Developer experience | 8/10 | Standalone prose, schemas, OpenAPI, examples, registries, migration rules, and reproducible checks reduce guesswork. |
| User comprehensibility | 7/10 | Consent dimensions are expressible; comprehension, accessibility, coercion, and mobile review are untested. |
| Governance credibility | 4/10 | Vendor neutrality is designed in, but license, namespace, contribution, and governance policies are not adopted. |
| Public-review readiness | 8/10 | Suitable as an explicitly provisional editor's working draft, not as a standard or release candidate. |

## Strongest elements

1. Accepted context remains scoped governance state, never universal truth.
2. Requests and receipts are inert; authorization remains external and operation-time.
3. Context/evidence/artifact permissions and data/control channels remain separate.
4. Proposal plus immutable review decision prevents silent accepted-state writes.
5. Runtime presentation, transfer, revocation, deletion, and assurance use bounded claims rather than marketing language.

## Most serious remaining weaknesses

1. No independent implementations or round-trip interoperability evidence.
2. No executable Remote Package Security or Offline Package Protection profile.
3. Durable public schema, registry, and discovery namespaces are not adopted.
4. Governance, license, patent, contribution, and conformance-mark rules are unresolved.
5. Authorization bindings are specified at the architectural level but not exercised against real OAuth/RAR and local brokers.
6. Parser sandbox, archive, media, SSRF, decompression, and model/tool-channel controls lack deployed evidence.
7. Multi-party authority, minors, guardians, households, organizations, coercion, and inheritance are safely deferred but still necessary for broad claims.
8. Consent comprehension and accessibility are untested with people.
9. The exact informative OCP 0.4 ↔ PAM v1.0 mapping still lacks machine-readable loss/sidecar fixtures and two independent adapters.
10. Forty-four normative assertions have no local reference-vector result (37 not executed, four manual-required, and three unavailable), and all fixture evidence remains partial by design.

## Highest-risk unresolved decisions

1. The exact remote/offline protection and key-lifecycle profiles.
2. Durable neutral governance, namespace control, licensing, and contribution policy.
3. The scope and authority model for multi-party, organizational, vulnerable-person, and delegated-agent contexts.

**Strongest argument for OCP.** Existing layers can move data or authorize calls, but none supplies a portable, scoped, reviewable continuity contract that safely separates evidence, interpretation, acceptance, presentation, and action authority.

**Strongest argument against OCP.** The valuable semantics could remain too policy-heavy and difficult for providers to implement consistently, while simpler memory formats plus product-specific consent may win adoption first.

**Recommended next step.** Publish the synchronized 0.4 package for bounded technical review and run the three prototypes in `REMAINING-DECISIONS.md`. Do not advance maturity until two independent implementations exchange the core, all release-gate assertion facets are accounted for, and real security/usability evidence exists.

## What changed in 0.4

- Consolidated the validated 0.2 governed-context design, later synthesis work, and the 0.9 observe-only proposal into one architecture.
- Retained nine core records; classified HTTP/offline/transfer as bindings and continuity observation/HIB as optional `0.1-draft` profiles.
- Added exact immutable snapshot references and separate live-status references.
- Bound each runtime chain to one delivery client instance and a separately approved plaintext-processor set.
- Replaced arbitrary package JSON with typed, closed, package-local entry forms.
- Added evidence-backed source verification, bounded proposal rights, exact decision-result commitments, package integrity, non-circular offline construction, and strict JCS/I-JSON semantics.
- Rejected bearer grants, universal RAR/DPoP, destructive content stripping, self-invented AES rules, universal CloudEvents, and a competing continuity core/package.
- Added an exact experimental OCP 0.4 ↔ PAM v1.0 mapping, a 30-source registry including CRP, 107 assertion rows, and explicit evidence statuses; the PAM mapping still requires machine-readable loss/sidecar fixtures and two independent adapters.

## Local evidence and its limits

The synchronized reports record 27 / 27 JSON Schemas compiled, 23 / 23 positive examples valid, 45 / 45 negative examples rejected at their declared rule, 243 / 243 semantic reference vectors, 29 / 29 registry/OpenAPI/evidence-accounting gates, and 107 / 107 assertion rows. No identified implementation was tested, so zero assertions are implementation passes or implementation failures; the split is 63 partial-reference results, three unavailable, four manual-required, and 37 not executed.

Those results do not establish deployed authorization, parser containment, cryptographic execution, recipient behavior, legal compliance, independent interoperability, or live human acceptance.
